Google Authenticator 的備份功能不是 E2EE (end-to-end encryption)

前幾天提到了 Google Authenticator 總算是支援備份功能了:「Google Authenticator 支援備份到 Google Account 的功能」,當初操作的時候沒看到自訂密碼之類的功能,就有在猜應該不是 E2EE,直接攔傳輸內容也被證實沒有 E2EE 了,TOTP 的 secret token 都是直接傳輸的:「PSA: Google Authenticator's Cloud-Synced 2FA Codes Aren't End-to-End Encrypted」。

Google 的發言人回應 CNET 的詢問時只說會有計畫做,但沒有給更細的資料:

To ensure that we're offering a full set of options for users, we have also begun rolling out optional E2EE in some of our products, and we plan to offer E2EE for Google Authenticator in the future.

在意的人就還是先不要開...

目前可商用的 LLM

Ask Hacker News Weekly 上看到的討論,有人問了目前可商用的 LLM 有哪些:「Ask HN: Open source LLM for commercial use?」。

有人提到 GoogleFlan 應該是目前最能打的?在 Hugging Face 上可以下載到:

I've seen this question asked repeatedly in many LLaMa threads, currently the best models that are truly open are the released models from the Flan family by Google, which includes Flan-T5[0] and Flan-UL2[1]. According to its paper, Flan-UL2 performs slightly better than Flan-T5-XXL.

然後差不多是 GPT-3 的等級,離 GPT-3.5 或是演伸出來的 ChatGPT 都還有段距離。但如果針對特定情境下 tune 的話應該還是能用的:

These models perform slightly better than GPT-3 under some tasks[2], but they're still far from achieving the results from GPT-3.5 and GPT-4. This becomes evident when you try to use them in the real world; they're not "good enough" for general use cases, unlike ChatGPT models. However, if you can restrict your use case to one particular domain, you can achieve pretty good results by further fine-tuning these models.

另外一則回覆有提到一些其他的 model:

The ones I saw mentioned so far were Flan, Cerebras, GPT-J, and RWKV.

Not yet mentioned:

* Pythia https://github.com/EleutherAI/pythia

* GLM-130B https://github.com/THUDM/GLM-130B - see also ChatGLM-6B https://github.com/THUDM/ChatGLM-6B

* GPT-NeoX-20B https://huggingface.co/EleutherAI/gpt-neox-20b

* GeoV-9B https://github.com/geov-ai/geov

* BLOOM https://huggingface.co/bigscience/bloom and BLOOMZ https://huggingface.co/bigscience/bloomz

看起來如果有需要用的話是可以從這裡面挖看看...

Google One 的使用者都有 VPN 服務可以用了...?

MacRumors 上面看到 Google 提供 VPN 服務給所有付費的 Google One 使用者使用:「All Paid Google One Subscribers Now Get VPN Access」。而 Google 的公告在這裡:「New security features for all Google One plans」。

主打隱私性,避免被追蹤 IP 位置之類的:

VPN by Google One adds more protection to your internet activity no matter what apps or browsers you use, shielding it from hackers or network operators by masking your IP address. Without a VPN, the sites and apps you visit could use your IP address to track your activity or determine your location.

看到這則留言,很貼切 XDDD

Google running a VPN is like McDonalds running an exercise gym.

不了謝謝 XDDD

新版 WordPress 預設的佈景主體將不會使用 Google Fonts

新版 WordPress 的預設佈景主體 (Theme) 出於隱私考量,將不會使用 Google Fonts:「Google Fonts are included locally in bundled themes」。

這邊講的是年份系列的 Theme,從 Twenty Twelve (2012) 到 Twenty Seventeen (2017):

再更後新的版本,首先是沒有 Twelve Eighteen (2018) (可以從「Themes by WordPress.org | WordPress.org」這邊翻),而從 Twelve Nineteen (2019) 後都沒有使用 Google Fonts 了,在 GitHub 上的 WordPress/twentynineteen 這邊可以 clone 下來確認:

$ git grep google    
classes/class-twentynineteen-svg-icons.php:         'google-plus' => array(
classes/class-twentynineteen-svg-icons.php:                 'plus.google.com',
classes/class-twentynineteen-svg-icons.php:         'google-plus' => '
classes/class-twentynineteen-svg-icons.php:         'google'      => '

官方還是有給繼續使用 Google Fonts 的方法,在「Continuing to use Google Fonts」這段有提到設定的方式。

Content Defined Chunking (CDC)

前幾個禮拜在 Hacker News Daily 上看到「CDC File Transfer (github.com/google)」這則,連結是指到 GoogleGitHub 專案上,裡面實做了 FastCDC 演算法,另外說明他們為什麼要解這個問題以及對應的成果:「google/cdc-file-transfer」。

Google 的人看起來像是是在 CI/CD 階段遇到頻寬上的問題 (從「The builds are 40-45 GB large.」這邊猜),用 scprsync 看起來都不能解,所以他們自己刻了 FastCDC 演算法來解。

但我對 Content Defined Chunking (CDC) 不熟,所以先查一下 CDC 是什麼東西,就查到 restic 這篇講得很清楚:「Foundation - Introducing Content Defined Chunking (CDC)」。

要計算 delta 很直覺的作法就是要切 chunk,而接著的直覺就是固定大小的 chunk 切開,像是這樣每 16 bytes 切一個 chunk:

0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef

如果其中一個地方有變化,但其他沒變化的話就可以透過 cryptographic hash function (像是 SHA-256) 確認 chunk 內容一樣,進而省下很多傳輸的頻寬:

0123456789abcdef 0123456789ABCDEF 0123456789abcdef 0123456789abcdef

但可以馬上看出來這個方法的大缺點是只能處理 replacement,很難處理 insert & delete 的部份,舉例來說,如果變更是在開頭的地方加上 ABC,就會造成 chunk 會完全不一樣,而導致全部都要再傳一次:

ABC0123456789abc def0123456789abc def0123456789abc def0123456789abc def

這邊其實是個經典的演算法問題:想要找出兩個 string 的差異 (把舊的內容當作一個 string,新的內容也當作一個 string)。

這個問題算是 Edit distance 類型的題目,但你會發現解 Edit distance 的演算法會需要先傳輸完整個 string 才能開始跑演算法,這就本末倒置了。

而另外一個想法是,放棄固定的 chunk 大小,改用其他方式決定 chunk 的邊界要切在哪裡。而 CDC 就是利用一段 sliding window + hash 來找出切割的點。

文章裡面提到的 sliding window 是 64 bytes,這邊就可以算出對應的 HASH(b0, b1, ..., b63),然後往右滑動變成 HASH(b1, b2, ..., b64),再來是 HASH(b2, b3, ..., b65),一直往右滑動計算。

接下來 restic 會看 hash 值,如果最低的 21 bits 都是 0 就切開,所以 chunk 大小的期望值應該是 2MB?(這邊不確定,好像不能直接用 2^21 算,應該用積分之類的方法...)

For each fingerprint, restic then tests if the lowest 21 bits are zero. If this is the case, restic found a new chunk boundary.

而這個演算法可以適應新增與刪除的操作,不會造成從新增或刪除後的資料都要重傳,只有自己這個 chunk 需要重傳 (可能前或後的 chunk 也會要)。

然後挑一下 hash function 的特性,就可以讓計算的速度也很快。這邊提到了 hash function 可以用 Rolling hash,可以很快的從 HASH(b0, b1, ..., b63) 算出 HASH(b1, b2, ..., b64),而不需要全部重算。

有了 chunk 後,再用 cryptographic hash function 比較 chunk 的內容是否一樣,這樣就可以大幅降低傳輸所需要的頻寬了。

讓使用者可以自己選擇 Push notification service 的 UnifiedPush

前幾天 Hacker News Daily 上看到的,F-Droid 寫了一篇文章介紹可以讓使用者自己選擇 Push notification service 的 UnifiedPush:「UnifiedPush: A decentralized, open-source push notification protocol (f-droid.org)」。

一般在 Android 平台上是透過 Google 自家提供的 FCM 傳遞 push notification 訊息:

A modern Android smartphone relies on a lot of services, from app stores and calendars to messaging and push notifications. Most of them have open alternatives, but until now, the only option for push notifications was Google’s proprietary service, Firebase Cloud Messaging (FCM).

但這樣很明顯會遇到隱私問題 (i.e. Google 可以知道所有的 push notification),所以一直都有要怎麼解決的討論。

而看起來 UnifiedPush 給了一個方案:使用者在 Android 手機上安裝一隻程式 (ntfy),這隻程式可以連到使用者指定的伺服器接收 push notification (可以是自架或是用現有的服務),另外一方面,當然也會跟 app 說要把 push notification 送到哪邊。

另外也考慮到使用者如果極度在意電池的問題,還是可以 fallback 回去使用 Google 的 FCM,也就是不影響現有使用者的體驗。

這樣就可以做到還是單一連線 (降低電力使用),但是是分散式的架構,而且使用者有一定的控制權。

目前支援的 app 看起來不多,但可以以預期後續 F-Droid 上面的 app 應該會有不少 app 會支援:「Apps using UnifiedPush」。

因應 Manifest V3 而推出的 uBlock Minus (MV3)

前幾天在 Hacker News 上看到「“UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3 (github.com/gorhill)」這個,裡面是 uBlock Origin 的作者 Raymond Hill 針對 Manifest V3 的半殘版,取名為 uBO Minus (MV3):「Add experimental mv3 version」。

在這個版本裡會有不少的功能失效,尤其是用的很多的 cosmetic filtering:

- No cosmetic filtering (##)
- No scriptlet injection (##+js)
- No redirect= filters
- No csp= filters
- No removeparam= filters

這個版本應該是打算要提供給 Manifest V2 被 Google 廢掉後還在用 Google 控制的瀏覽器的人,依照「Manifest V2 support timeline」這邊看起來是明年一月:

Google Cloud 宣佈明年關閉 IoT Core Services

Hacker News 上的「Google IoT Core will be discontinued on Aug. 16, 2023」這篇,大家在討論 Google Cloud 宣佈明年關閉 IoT Core Services 的事情,基本上討論的內容大概都想的到...

AWS 這邊的話,最近比較有印象的就是要淘汰 EC2 Classic (EC2-Classic 的狀態),但到現在還是在跑。

另外一個是把 Xen 架構 porting 到 Nitro 上 (AWS 將新的 Nitro 架構回過投來支援以前 Xen 的機種),讓原有的 Xen 應用可以繼續用。

久一點以前的 SimpleDB 到現在也還是活著,官方現在應該是主力在推 DynamoDB

兩種完全不同的作法...