LSAs 與 application password 不同...

前天在「使用 application password 的 Google 服務將在 2024/09/30 停止支援」這邊寫完後,yan12125 在文章留言的地方提到:

看起來這次只有停止支援 Less Secure Apps, application password 還是可以用的。公告中提到:

> If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth or create an app password to access these apps.

回頭去翻了一下 LSA 是什麼 (出自「Limiting access to less secure apps to protect G Suite accounts」這篇):

A less secure app (LSA) is an app that connects to Google accounts using only username and password verification for access and not OAuth. Generally, you should only allow your users to use external apps that connect to Google accounts via OAuth, as LSAs make user accounts more vulnerable to hijacking.

看起來這邊指的是用原始的 Google 帳號與密碼登入,我一直以為這個方式早就被拔掉了,所以這次的公告以為是拔掉 application password,但看起來不是這樣。

各家瀏覽器與工具對於 blur 效果的實際呈現比較

Hacker News 上看到「Blur Radius Comparison (bjango.com)」,原文在「Blur radius comparison」。

重點在這張:

前面九個分成三種效果在三個不同的瀏覽器呈現的結果,然後是 FigmaIllustratorPhotoshopSketch 的效果。

可以看出來在瀏覽器上的部分,大家的 rendering 沒有差太多。

而 Figma 所有 blur 類的效果,在瀏覽器上比較接近的只有 box-shadow,其他三套則是有不同的變化...

Firefox 與 Chrome 處理 Intermediate CA 的不同方式

Fediverse 上看到「The recording of my "Browsers biggest TLS Mistake" lightning talk at #37C3」這個,這是出自 37C3 的 lightning talk,影片不長,只有五分鐘,可以在「Browsers biggest TLS mistake」這邊看到。

正常的 HTTPS server 會送出 Intermediate CA certificate 與自己的 TLS certificate:

當伺服器端沒有設定好,通常是只送出自己的 TLS certificate:

這種情況在 Firefox 裡有處理,軟體本身會預載所有的 Intermediate CA 避免這種問題 (當然會需要跟著軟體更新),這點在三年前有提到過:「Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率?」,也就是這張投影片提到的情況:

Chrome 則是去看目前的 cache 資料,找看看是不是在其他地方有看到適合的 Intermediate CA 可以接起來:

這好像可以解釋為什麼之前遇到類似的問題的時候,在 Chrome 上面會需要進 chrome:// 裡面清東西才能重製...

Google Groups 將在 2024/02/22 斷開與 Usenet 的連接

在 news.admin.peering 上看到的消息:「Effective February 15, 2024, Google Groups will no longer support new Usenet content」,在 Google Groups 上面也可以看到:

Effective February 15, 2024, Google Groups will no longer support new Usenet content. Posting and subscribing will be disallowed, and new content from Usenet peers will not appear. Viewing and searching of historical data will still be supported as it is done today.

而在 Hacker News 上也有討論「Google Groups ending support for Usenet (support.google.com)」。

話說先前寫的「Google Groups 的 spam 的量又下降了不少...」這篇,後來又有發現不是 Google Groups 的 spam 減少,而是 Cleanfeed 裡面用 SpamAssassin 會造成跑久以後會 100% CPU,反而接收的速度慢下來...

在上了 workaround 後 (每個小時自動重跑一次 innd),可以看到其實完全沒有變少,反而愈來愈多:

倒是後來一直丟 corpus 進去練 SpamAssassin 後看起來效果好很多了,還是會看到一些 spam,但就沒那麼多了...

用 GPT-4 重現 Google Deepmind 的 Gemini Demo 影片

Google Deepmind 前幾天發表了 Gemini:「Introducing Gemini: our largest and most capable AI model」,同時也釋出了 Demo 影片:

但後來大家發現 Demo 影片中人並不是直接透過語音與 Gemini 互動,而是把輸入進去的指令讓人讀出來,而且省略掉中間的各種 delay,是個被後製不少的影片:「Google’s best Gemini demo was faked」。

然後就有人用 GPT-4 實作出一個可以互動的版本了,雖然是 PoC 等級的,但反而更真實:「Show HN: I Remade the Fake Google Gemini Demo, Except Using GPT-4 and It's Real (greg.technology)」。

記得 Google 年初的 Bart Demo 也出包,可以來看看後面第三次的情況?

Spotify 在 Google Play 上面不需要付 15% 的過路費

Google 的大頭在與 Epic 的訴訟案中被要求揭露了實際的數據:「A secret Google deal let Spotify completely bypass Android’s app store fees」。

如果是透過 Spotify 自家的金流平台,就完全不用付錢給 Google,如果是透過 Google 的平台則是 4%,遠低於一般上架商家的 15% (超過 $1M/y 的部分則會到 30%):

On the stand, Google head of global partnerships Don Harrison confirmed Spotify paid a 0 percent commission when users chose to buy subscriptions through Spotify’s own system. If the users picked Google as their payment processor, Spotify handed over 4 percent — dramatically less than Google’s more common 15 percent fee.

來看後續法院以及歐盟會怎麼出手?這應該會是蠻重要的證據資料...

Google Groups 的 spam 的量又下降了不少...

延續「從 Google Groups 送出來的 spam 數量稍微下降...」這邊的觀察,從 10/22 到 10/29 降了 2/3 左右,再往後拉七天到了 11/5 可以看到又少了 3/4 左右。

另外整個 article volume 看起來也有降很多,從三個不同的 peering 來的量都有降,看起來是從源頭就有做一些事情。

這是 10/22 的量:

這是 10/29 的量:

這是 11/5 的量:

從 Google Groups 送出來的 spam 數量稍微下降...

先前在「Google Groups 的巨量 spam」這邊提到從 Google Groups 倒進 usenet 大量的 spam,最近看起來稍微緩解了一些。

這是 10/22 的量:

這是 10/29 的量:

可以看出來整體被 Perl filter 擋下來的量大幅降低了,在 comp.lang.c 也可以看出來 10/28 後似乎暫時停了...?

只能繼續觀察看看了...

Google SRE 團隊整理出過去二十年的十一條心得

Google 的 SRE 團隊整理出過去二十年的心得,當看故事的心態在看的:「Lessons Learned from Twenty Years of Site Reliability Engineering」,在 Hacker News 上也有討論:「Lessons Learned from Twenty Years of Site Reliability Engineering (sre.google)」。

裡面的項目大多都會在公司成長時不斷的導入,都是夠大就會遇到的。

比較有趣的是第六條,這是唯一一條全部都用大寫字母列出來的:

COMMUNICATION CHANNELS! AND BACKUP CHANNELS!! AND BACKUPS FOR THOSE BACKUP CHANNELS!!!

到 Google 這個規模的架構,這邊就會規劃找完全獨立於 Google 架構的方案來用;我猜應該是傳統的 colocation 機房 (像是 AT&T 之類的),上面跑 IRC server 之類的?

在 Hacker News 上面也有其他人提到 Netflix 也有類似的規劃,需要有一個備援的管道是完全獨立於 AWS 的;另外同一則 comment 裡也有提到 Reddit 的作法是在辦公室裡面放 IRC server 備援:

Yes! At Netflix, when we picked vendors for systems that we used during an outage, we always had to make sure they were not on AWS. At reddit we had a server in the office with a backup IRC server in case the main one we used was unavailable.

IRC 還是很好用的 XD