密碼輸入上的 UX

Hacker News 上看到「Gmail password first character is case insensitive on mobile device (support.google.com)」這篇,在講密碼輸入上的 UX。

在 Hacker News 上的討論看到這則:

This is a well-understood feature. Facebook does the same thing[0].

Quote:

Facebook actually accepts three forms of your password:

* Your original password.

* Your original password with the first letter capitalized. This is only for mobile devices, which sometimes capitalize the first character of a word.

* Your original password with the case reversed, for those with a caps lock key on.

[0]: https://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

接受三種密碼,第一種是完全正確的密碼,第二種是第一個字如果是大寫時的密碼 (在行動裝置上可能的行為),第三種是大小寫全部相反的密碼,這在沒注意到 caps lock 時會發生。

強度不會削弱太多,但對於 user experience 好很多的設計。

弄個 whoogle.hasname.com 給大家玩

先前提到的 Whoogle:「自架的 Google Search Proxy 伺服器專案:Whoogle Search」與「改寫「Press "g" to Google (DuckDuckGo)」讓他支援 Whoogle」,後來想一想還是讓沒打算自己架的人可以用好了,指到國外的 latency 還是比較高...

如果你是 Chromium 類的瀏覽器,可以把搜尋引擎改成:

https://whoogle.hasname.com/search?q=%s

如果是我寫的 userscript (「Press "g" to Google (DuckDuckGo)」這個),可以改成:

https://whoogle.hasname.com/search?q=

然後 nginx 這邊先 access_log off; 了,理論上這樣應該是差不多了?

目前機器是放在客廳 (加 UPS),之後可能會丟到台灣的 VPS 上?

改寫「Press "g" to Google (DuckDuckGo)」讓他支援 Whoogle

前幾天提到了 Whoogle 這個專案 (參考「自架的 Google Search Proxy 伺服器專案:Whoogle Search」),用 Docker 跑起來後就改寫「Press "g" to Google (DuckDuckGo)」這個專案,讓他可以支援設定 Whoogle,大概像是這樣:

使用者可以自己設定對應的 Whoogle 伺服器,這樣應該會方便一些...

自架的 Google Search Proxy 伺服器專案:Whoogle Search

忘記在哪邊看到的連結,自架的 Google Search Proxy 伺服器專案:「Whoogle Search」,對應的 Hacker News 討論串也可以參考:「Whoogle Search: A self-hosted, ad-free, privacy-respecting metasearch engine (github.com/benbusby)」。

GitHub 上的分析可以看出來主要是 PythonFlask 寫的,然後說明就有提到是從 Google Search 撈資料,去掉所有可能可以被追蹤的項目:

Get Google search results, but without any ads, javascript, AMP links, cookies, or IP address tracking. Easily deployable in one click as a Docker app, and customizable with a single config file. Quick and simple to implement as a primary search engine replacement on both desktop and mobile.

目前最新版是 0.5.4,從他列出來的 Public Instances 找了一個是最新版的測試,看起來沒什麼大問題:「gslin - Whoogle Search」。

應該可以自己在台灣架一個起來玩看看?安裝方式看起來很多,因為是 Python-based 的套件,可以用 pipx 或是 Docker 裝起來跑,然後可以改寫「Press "g" to Google (DuckDuckGo)」(press-g-to-google-duckduckgo) 讓他可以設定要轉到哪個 Google Search Proxy...

Google Analytics 會愈來愈不準的問題

Hacker News Daily 上看到在討論 Google Analytics 會愈來愈不準的問題:「58% of Hacker News, Reddit and tech-savvy audiences block Google Analytics」,先大概知道 Plausible 也是一個分析工具,宣稱重視隱私以及相關法規 (...),所以網站裡面提到的推論可以看看就好,這次我主要是看數字而已。另外當然,Hacker News 上對這篇文章的討論「Tech-savvy audiences block Google Analytics (plausible.io)」也可以翻翻。

作者先前注意到愈一般性的網站,阻擋率就愈低,但科技相關的網站就會高到失真:

In a previous study, I’ve found that less than 10% of visitors block Google Analytics on foodie and lifestyle sites but more than 25% block it on tech-focused sites.

其實不算太意外,除了 Google 自家的瀏覽器,其他的瀏覽器愈來愈多預設就會擋掉各種 tracker,而科技相關網站的受眾常常會「保護自己」。

首先的段落提到的全站的比率,有大量的使用者會擋掉 Google Analytics (要注意這邊是拿科技類網站的數字,不是一般性的網站),:

58% of visitors block Google Analytics

然後是桌機與筆電的使用者阻擋率比較高 (還是科技類網站的數字):

68% of laptop and desktop users block Google Analytics

另外提到 Firefox 使用者的阻擋率超高,應該是幾乎都會裝套件擋,另外記得新版的 Firefox 預設會擋,可能也有關係 (再提醒一下,這是科技類網站):

88% of Firefox users block Google Analytics

另外一個不算意外的是 Linux 使用者也是擋的很兇 (科技類網站):

82% of Linux users block Google Analytics

這有兩個重點蠻重要的,第一個是,就算你不是科技類網站,你也應該試著用其他工具「校正」Google Analytics 的數字,你要知道 Google Analytics 偏差了多少。

第二個是 Firefox 使用者的數量可能都被低估了,以 Firefox 阻擋率這麼高的情況下,有可能 Firefox 使用者會裝各種阻擋工具,把各種分析平台都擋一輪。不要直接用這些工具的數字決定忽略掉 Firefox 的使用者,最好要多方面驗證:

I expected these numbers to be higher. However, an even more interesting metric is the 88% block in Firefox.

Firefox may not have a great market share, but based on these numbers it's market share may very well be eight times higher than your analytics report. This can change the argument of "it's only 3% of our users so we don't need to test on FF" to "it's a quarter of our user base, we should at least test it", depending on your target audience. I've seen tons of people claim general Firefox usage is negligible based on public data from websites such as statcounter, but these metrics prove that those statistics are unreliable and should not be used.

The best you can do is use server side UA inspection, though you can't really distinguish bots from real users that way.

另外順便提,我在辦公室裡面推銷 uBlock Origin 的方式是跟他們說 YouTube 影片就沒有 Google 的廣告了 (業配那種不算),基本上用過就回不去了...

南韓對 Apple 與 Google 的 In-App 付款機制的提案

WSJ 上看到南韓對 AppleGoogle 的 in-app 付款機制提案,強制 Apple 與 Google 讓 app 的開發者 (或是開發商) 使用第三方支付平台:「Google, Apple Hit by First Law Threatening Dominance Over App-Store Payments」。

看不到 WSJ 內文的可以看「Apple and Google must allow developers to use other payment systems, new Korean law declares」這篇,裡面有引用韓國的媒體報導 (英文版):「S. Korea looks set for legislation to curb Google, Apple's in-app billing system」。

要注意這還沒有通過,目前過委員會而已 (parliamentary committee),接下來要表決才會成為正式法律。

先前美國亞利桑那州的法案被擋下來,然後參議院提的法案也還在進行中,看起來還有很硬的仗要打:「由美國參議院提出的 Open App Markets Act」。

先繼續等後續發展,可以想見 Apple 與 Google 一定會想辦法抵制...

由美國參議院提出的 Open App Markets Act

以為之前有寫過亞利桑那州的法律,結果沒找到... (有可能寫一寫就刪掉了)

三月初的時候亞利桑那州推動修正法案,強制夠大的 OS 必須開放其他的 App Store 以及 Payment 系統 (以當時,或是現在來看,應該只有 AppleiOSGoogleAndroid 這兩個系統):「Arizona advances bill forcing Apple and Google to allow Fortnite-style alternative payment options」,不過這個法案在同月月底的時候就被沒收了:「It’s game over for Arizona’s controversial App Store bill」。

這次則是由美國參議院 (上議院) 跨黨派的三位參議員提出來的 Open App Markets Act 也是類似的事情,只是拉到全國的層級:「Blumenthal, Blackburn & Klobuchar Introduce Bipartisan Antitrust Legislation to Promote App Store Competition」。在 Hacker News 上有討論:「Senators introduce bipartisan antitrust bill to promote app store competition (senate.gov)」。

第一關應該是要先讓參議院通過,在這個階段 Apple 與 Google 兩家應該就會有各種檯面上的遊說與檯面下的動作,另外像是 EpicSpotify 這些公司應該也會進去推一把...

Chromium 系列瀏覽器對 Google Search Engine 的不公平最佳化

在 tab 上放了一陣子的連結,忘記是哪邊看到的,在講 Chromium 系列瀏覽器會針對 Google Search Engine 最佳化:「Google’s unfair performance advantage in Chrome」。

作者發現 Chromium 瀏覽器會預先開 HTTPS 連線連到搜尋引擎,這樣可以大幅降低建立 HTTPS 連線時所需要的時間,包括了 DNS 查詢、TCP handshake 與 TLS handshake:

I was looking for something else when I stumbled upon a feature called PreconnectToSearch. When enabled, the feature preemptively opens and maintains a connection to the default search engine.

問題在於這個功能只開給 Google Search 使用:

There’s just one small catch: Chromium checks the default search engine setting, and only enables the feature when it’s set to Google Search.

search_engine_preconnector.cc (HEAD 版本) 這邊可以看到這段程式碼:

// Feature to limit experimentation to Google search only.
const base::Feature kPreconnectToSearchNonGoogle{
    "PreconnectToSearchNonGoogle", base::FEATURE_DISABLED_BY_DEFAULT};
}  // namespace features

作者有提到,的確這個功能會對 search engine 有不小的衝擊,但可以透過擴充 OpenSearch Descriptions 或是 Well-Known URI 的方式提供,現在這樣寫死在程式碼裡面完全就是不公平競爭。

Google Meet 可以走 443/tcp 了

Work from home 期間開會基本上就是幾個視訊軟體換來換去,Zoom 的話公司有買,自己開免費版的時候是 40mins 限制,另外 Slack 的畫面品質不怎麼樣,而 Google Meet 在疫情期間不限制時間,拿來聊天還蠻好用的。

看到「TLS support for Google Meet」這篇,文章裡面提到先前 Google Meet 是用 443/udp 跑 SRTP,這對很多公司的 firewall 需要另外開 (看到這個 UDP port 想到 QUIC 好像也是走這個 UDP port),在家裡的話應該還好,對於公司的電腦就會麻煩一些。

文章裡提到,這次支援了 TLS (over 443/tcp):

Some network setups do not work with SRTP over 443 which was preventing Meet calls from connecting. Meet now encapsulates SRTP in TLS which increases overall compatibility. This change will initially be available on the web, and will be available for mobile soon. We’ll announce it on the Google Workspace Updates blog when it’s available.

可以 fallback 回 443/tcp 走 TLS 的話穿透力應該就更好了,不過不知道免費版的有沒有也一起上,這邊只題到了 G Suite 系列會上:

Available to all Google Workspace customers, as well as G Suite Basic and Business customers

上次用 Google Meet 是在雲端聚餐聊天...

Google Web Store 裡的黑暗交易

標題只寫了 Google Web Store,主要是因為瀏覽器市占率的問題,其實是包含 Firefox 的 Add-Ons。

這是在 Hacker News 首頁上看到的:「Many temptations of an open-source chrome extension developer」,講一直會有人來接觸,可以付費給開發者,想要在這些專案裡面放一些「東西」,可能是蒐集資料,可能是強制導到特定的 search engine,也有可能更邪惡...

另外是老規矩,在 Hacker News 上的討論也可以翻一翻,還蠻有趣的:「Many temptations of an open-source Chrome extension developer (github.com/extesy)」。

先大概看一下 Hover Zoom+ 這個套件在 Google Web Store 的安裝數量,大約 30 萬人:「Hover Zoom+」,作者公佈的信件內容裡面有一些包括價錢與目的...

話說回來,Brave 上的 CRX Viewer 還是沒修好啊:「Stopped working with Brave」,要裝新的套件都得另外再拉 crx 檔下來看,麻煩不少...