幹壞事是進步最大的原動力
六月底的時候就有一些消息，然後這幾天熱起來了，先是 Hacker News 上這兩篇，在講 Firefox 128 (現在的 stable 版) 預設開啟了廣告蒐集行為：「Firefox 128 enables "privacy-preserving" ad measurements by default (mstdn.social)」、「"Firefox added [ad tracking] and has already turned it on without asking you" (mastodon.social)」。
這個消息剛好可以跟六月底的時候「併購」了 Anonym 這家廣告公司一起看：「Mozilla acquires ad analytics company, for some reason」。
愈來愈像廣告公司了...
繼續清 tab，在「YouTube embeds are heavy and it’s fixable (frontendmasters.com)」這邊看到的是提出改善 YouTube 的外嵌功能 (embed)，因為 loading 太肥了。原文在「YouTube Embeds are Bananas Heavy and it’s Fixable」，裡面提到一個只有 YouTube 的 embed (iframe) 頁面就抓了 1.3MB 的資料：
On a page with literally nothing at all on it other than a YouTube Embed, we’re looking at:
32 requests
1.3 MB of data transfer
2.76s to load the page on my current WiFi connection
而「One YouTube Embed weighs almost 1.2 MB」這邊更提到了這邊的 resource 會線性疊加不會共用的：
The weight also grows linearly with every embed—resources are not shared: two embeds weigh 2.4 MB; three embeds weigh 3.6 MB (you get the idea).
測了一下 https://home.gslin.org/tmp/ytembed.html 這個，是 1.2MB transferred：
如果放兩個一樣的影片，也就是 https://home.gslin.org/tmp/ytembed2.html 的話，變成 2.4MB transferred：
所以不共用的部分的確超大，懷疑 iframe 之間不共用資源是不是跟 cache partition 的實作有關：「Google Chrome 要藉由拆開 HTTP Cache 提昇隱私」。
Anyway，所以作者提案用 lite-youtube-embed 這個套件改善：
Provide videos with a supercharged focus on visual performance. This custom element renders just like the real thing but approximately 224× faster.
不過這種事情你想得到，Google 也一定想得到，全篇只講 lite-youtube-embed 的好處一定哪邊有問題。
所以翻一下 Hacker News 上，在 id=40897582 這邊就有人提到缺點了，很明顯 lite-youtube-embed 的載入速度比較慢：
The author says they don't believe that a lighter version has been shown to reduce engagement.
I, on the other hand, fully believe that.
The recommended lite-youtube-embed project page has a demo of both lite and regular players [0], and the lite version takes noticeably longer to start playing the video.
Every additional millisecond of load time will reduce engagement, and here the difference is more on the order of hundreds of milliseconds or more.
yeah，這樣就合理了。
即使 embed 吃超多資源，但因為 YouTube 是影音網站，主要的流量還是影音的部分，利用這個方法增加載入速度，在成本結構上面可以接受，而且還可以拿到更多瀏覽資料？
但對於網站端以及使用者端就不是什麼愉快的事情，所以網站端要不要用這個套件就是看各自的取捨了。
在「Reddit's Robots.txt Changed (reddit.com)」這邊看到的，可以看到現在 https://www.reddit.com/robots.txt 的內容變成 (刪掉註解的部分)：
User-agent: * Disallow: /
這個改變倒是沒預料到的... 來觀察看看 HN 上後續的討論？
在「Welcome to Ladybird, a truly independent web browser (ladybird.org)」這邊看到的，指到官網 Ladybird 上。
最主要的資訊應該是這個日期，目前計畫是 2026 夏天在 Linux 與 macOS 上推出 alpha 版：
We are targeting Summer 2026 for a first Alpha version on Linux and macOS. This will be aimed at developers and early adopters.
也就是大約再兩年，看起來得花不少時間開發... 畢竟是要完全獨立開發不使用現有瀏覽器的 code。
台灣的圈子蠻多人是從「請儘速遠離 cdn.polyfill.io 之惡意程式碼淺析」這邊看到的，一些 code 相關的分析部分可以移駕過去看。裡面提到的 GitHub 上面 alitonium 所寫的 comment 蠻值得讀一下 (第一次點的時候會出現 GitHub 的警告，再點一次應該就會跳到正確的 comment 上)。
polyfill.js 算是老專案了，從 https://github.com/polyfillpolyfill/polyfill-service/graphs/contributors 這邊可以看到是 2013 年開始有記錄，主要是針對舊的瀏覽器 (像是 IE11)，透過 javascript 的方式補上對應的功能。
現在的瀏覽器都是一直在更新，大多數的情況不太需要 polyfill 了，但畢竟很多舊的案子還在用，在這次 domain 被中國公司拿走後，Cloudflare 在今年 2024/2/29 就有先寫一篇算是預警的文章了：「polyfill.io now available on cdnjs: reduce your supply chain risk」，不過這種事情都是還沒發生前大家不會有太多重視，接下來就是 GitHub 上面的討論，然後是真的被動手加 malicious code 進去後，有人發現的討論。
後續大家都被迫要開始處理這件事情，GitHub 的作法看起來沒什麼問題：先標注 malicious repository 但是還是讓人可以進去翻歷史資料與討論。
不過 Cloudflare 這邊動作有點大，直接主動幫 CDN 客戶過濾了：「Automatically replacing polyfill.io links with Cloudflare’s mirror for a safer Internet」，這篇在 Hacker News 上也有討論：「Cloudflare automatically fixes Polyfill.io for free sites (cloudflare.com)」。
這個「越界」有點多，這應該也是直接讓 CEO Matthew Prince 出來掛文章作者的原因。這次 Cloudflare 主動做的事情包括了將免費的客戶預設開啟過濾，而付費的客戶則不會主動開啟，但提供一鍵開關：
Any website on the free plan has this feature automatically activated now. Websites on any paid plan can turn on this feature with a single click.
另外也允許所有客戶關掉這個保護：
All customers can turn off the feature at any time.
所以後續就會有另外一條大支線討論：在使用者沒有事前同意的情況下，以「安全」為名主動更改使用者頁面上的東西，這件事情是不是可以接受？如果以「安全」為名可以接受，為什麼是免費的先動，付費的卻不動？雖然我猜 Cloudflare 會裝死到底就是了...
在「Fastly launches free developer accounts (fastly.com)」這邊看到 Fastly 推出 free tier 的消息：「It’s free, instant, and yours! Fastly’s free developer accounts are here」。
財報上面看起來不太好看：「Fastly EPS - Earnings per Share 2018-2024 | FSLY」，拿著隔壁棚 Cloudflare 的數字對比也差不多：「Cloudflare EPS - Earnings per Share 2017-2024 | NET」，反倒是老牌的 Akamai 可以看出來還持續有賺錢：「Akamai Technologies EPS - Earnings per Share 2010-2024 | AKAM」。
試著登入發現有帳號，重設密碼後發現 2016 年的時候有測試過... 登進去發現整個介面不好用？除了 loading 速度不快以外，有不少是介面邏輯的問題，用起來頗不順。
這次推 free tier 可以推敲出來心態大概是想衝量，但看起來沒有比較優秀？講 network coverage 沒有 Cloudflare 多，講產品功能也沒有 Cloudflare 好...
維基百科上面有時候會想要看其他語言的頁面，以 Kalafina 這頁來說，想要點開跨國語系的 menu 點日文版頁面的時候，會出現這樣的情況：
游標移上去要點的時候，因為 lazy loading 跑完；DOM 被插入新的 node，造成本來想要的日文版連結跑到下面，然後按快一點的人就點到其他連結... 目前的解法是直接用 uBlock Origin 擋掉那個 node，讓他不要出現：
wikipedia.org##.cx-uls-relevant-languages-banner
這種類型的 UX flaw 在現代愈來愈多了，而且還是各 framework 都推薦的寫法... (各種 useEffect() 類的功能，頁面的結構先出來，再後續讀到內容時再更新頁面)
看到「Creating Perfect Font Fallbacks in CSS」這邊這段時想到的：
With font-display: swap, the browser will first render your text using the fallback typeface you specified in the font-family property[.]
font swapping 也是個讓人吐血的 UX flaw...
但文件寫的很糟：「The tiniest PaaS you've ever seen. Piku allows you to do git push deployments to your own servers.」。
名字來自於 Dokku，另外應該是用到了 pico 這個數量級詞：
piku, inspired by dokku, allows you do git push deployments to your own servers, no matter how small they are.
這個工具是在「Piku: Allows git push deployments to your own servers (github.com/piku)」這邊看到的，就如同說明提到的，希望透過 git push 就可以發佈軟體。
不過在討論裡面也有人抱怨文件的問題，像是在 id=40625339 這邊就有人提到。
實際到 AWS 上開了一台 EC2 instance 測，看起來就是提供一包 script 把伺服器端設定好，包括了 Let's Encrypt + nginx 以及 SSH 與 Git 相關的設定，接著你可以直接將這台 server 設為 git remote，然後就可以用 git push 推軟體上去了。
對於只是想要跑軟體，而且容易接 CI/CD 的方案來說還算 OK，但如果想要自己客製化 nginx 或是一些工具的情境就不是那麼適用了。
在「L(O*62).ONG: Make your URL longer (looooooooooooooooooooooooooooooooooooooo...)」這邊看到的有趣東西，網站是「L(o*62).ong - Make your URL longer」，網站的主人還在搞事就被貼到 Hacker News 上，所以他就上來說明一下發生了什麼事情...
在 id=40543697 這邊提到網域名稱過長導致撞到 TLS certificate 中 commonName (CN) 欄位長度限制的問題：
The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.
This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.
Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.
不過後面有人提到 commonName 在網頁用的 TLS certificate 已經 deprecated 很久了，而 Let's Encrypt 在 2023 年的時候已經支援 commonName 留空，改用 Subject Alternative Name，可以到 255 chars。
留言裡面所連結的 Let's Encrypt 公告上面也提到了類似的事情：「Simplifying Issuance for Very Long Domain Names」。
Additionally, the CN is limited to at most 64 characters, while SANs can be significantly longer. This means that the CN is not only redundant, but actively restrictive: a certificate which has a Common Name cannot contain only very long domain names, because none of them would fit in the CN. For these reasons, the BRs state that for Domain Validated certificates, the Common Name field is "not recommended".
所以看起來是各家系統還沒有跟著改 (因為 Let's Encrypt 先前需要 CN 有值)，但如果是自己申請的應該是可以自己避開了 (生 csr 的時候就改用 SAN)？
在「The Internet Archive is under a DDoS attack (archive.org)」這邊看到 Internet Archive 被 DDoS 貓，原始連結在 https://mastodon.archive.org/@internetarchive/112513905401989149 這邊：
現在是有感覺到 loading 的速度不快 (不過以前就不快了)，然後 traceroute 看起來有輕微的 packet loss...
記得 Internet Archive 的頻寬一直都是滿的 (翻到 2020 年時有提到的「Internet Archive 的頻寬...」)，對於以灌流量的 DDoS 攻擊是沒什麼抵抗力的。
以他們家的情況來看，大概只能請上游幫忙擋？