幹壞事是進步最大的原動力
uBlock Origin 在 2016 的時候 porting 到 Safari 上，但在 2018 後就沒有再更新了，維護者在「Explanation of the state of uBlock Origin (and other blockers) for Safari #158」這邊說明了目前的情況。
主要就是蘋果要廢掉本來的 Extension API，而替代的框架裡沒有對應的 content filtering 能力，所以在新的框架內無法實做 uBlock Origin 的功能...
維護者的建議是換瀏覽器，但其實可以選擇的瀏覽器愈來愈少了 (因為 Google Chrome 這邊也在搞)，所以維護者的建議就是換成 Firefox。
另外我自己會建議用看看 Brave，因為 Brave 已經決定，如果 Google Chrome 修改 webRequest 的阻擋能力 (也就是這次的 Manifest V3)，他們會繼續維持本來的相容性，所以可以預期 uBlock Origin 應該還是會動 (參考之前寫的「Brave 試用」這篇)。
Google Chrome 也要支援 DNS over HTTPS (DoH) 了，不過 Google 的作法比 Firefox 軟 (大概這種東西都有經過反壟斷法的評估？)，會先判斷系統的 DNS 是否在支援 DoH 的清單內，在不改變 DNS 服務商的情況下，從本來的 UDP 查詢變成 DoH 查詢：「Experimenting with same-provider DNS-over-HTTPS upgrade」。
清單可以從「DNS over HTTPS (aka DoH)」這邊看到，除了 Google 自己外，也有 Cloudflare 與其他支援 DoH 的 DNS 服務商。
這個功能會從 Chrome 78 生效 (現在 stable 與 beta 都還是 77)：
We are aiming for an experiment in Chrome 78 (branch cut: Sept 5th; estimated Stable: Oct 22nd) followed by a launch if everything goes well.
目前主力的瀏覽器還是 Google Chrome，會試著用其他的瀏覽器基本上就是「所以 Google 要對 ad blocker 全面宣戰了...」這篇文章提到的事情，然後找看看有什麼方案可以用...
先前測過 Firefox，但目前光是只開著三個 Slack 就會當掉 (三個 tab 都吃滿 100% CPU，所以可以在 top 上看到 300% 的使用率)，另外整理的順暢度還是差了很大一截，實在是找不到什麼好理由換過去...
而這次測的 Brave 是從 Chromium 改出來的，看起來沒有改動太多東西，連 extension 站台都直接吃 Google Chrome 的，基本上都會動。
測了兩天有一些問題：
目前來看轉換成本不算太高，之後 Google Chrome 真的動手搞 ad blocker 時可以考慮換過來...
從「Google plans to deprecate FTP URL support in Chrome」這邊看到的，狀態資訊可以在「Deprecate FTP support」這邊看到。
以目前的 timeline 資訊，看起來是 M82 版本會完全拔掉：
M78 (2019Q4)
Finch controlled flag and enterprise policy for controlling overall FTP support.Support disabled on pre-release channels.
M80 (2020Q1)
Gradual turndown of FTP support on stable.M82 (2020Q2)
Removal of FTP related code and resources.
不過這樣就沒有方便的 FTP downloader 了 (雖然不常見)，得另外再找軟體下載...
是收到信件通知 (因為之前有開發一些 extension)，裡面提到的重點主要是出自「Developer Program Policies」裡的兩項。
第一項是要求權限最小化：
Request access to the narrowest permissions necessary to implement your Product’s features or services. If more than one permission could be used to implement a feature, you must request those with the least access to data or functionality.
第二個是你現在沒有實做的功能就不能要權限：
Don't attempt to "future proof" your Product by requesting a permission that might benefit services or features that have not yet been implemented.
這些新條文將會在 2019/10/15 生效：
Your extensions must be compliant with this policy by October 15th, 2019. You can learn more about these changes and how they may apply to you in our User Data FAQ.
Google Chrome 74 版修掉了一般模式與私密瀏覽模式下 FileSystem API 明顯的不同處後，自然就會有人研究其他的偵測方式：「Bypassing anti-incognito detection in Google Chrome」。
作者提出來的方式是透過 Quota Management API，一般模式與私密瀏覽模式下會得到不同的值，尤其是硬碟夠大的時候上限是不一樣的：
不過這個看起來應該比較好修？
看到「Stable Array.prototype.sort」這篇在講 JavaScript 規格書裡的 sort...
本來 JavaScript 的規格書裡，各種 sort 都沒有保證 stable，而在「[Normative] Make Array.prototype.sort stable #1340」與「[Normative] Make %TypedArray%.prototype.sort stable #1433」這兩個地方則有了變化，提案在規格裡加入 stable 的要求，可以減少開發者因為不知道 unstable 而造成的問題...
Firefox 則是很久前就決定使用 Merge sort 了 (看了一下，當時還在從 Firebird 轉換名稱到 Firefox 的時期)：「Array.sort isn't a stable sort (switch to MergeSort)」。
另外這篇也剛好提到了 V8 使用 Timsort 當作 stable sorting algorithm，之前就有看到但發現沒在 blog 上提過...
Timsort 是 1993 年發明出來的演算法，與 Merge sort 的情況類似，除了 stable 外，還可以保證最差的情境下的時間複雜度是 
Timsort is a hybrid stable sorting algorithm, derived from merge sort and insertion sort, designed to perform well on many kinds of real-world data.
這個演算法的重點是善用已經排好的子序列，藉此降低記憶體操作次數而提昇效能，符合真實環境裡常見到的資料：
The algorithm finds subsequences of the data that are already ordered, and uses that knowledge to sort the remainder more efficiently.
除了 V8 採用這個演算法以外，其他常見的包括了 Python 與 Android 上的 Java SE：
Timsort has been Python's standard sorting algorithm since version 2.3. It is also used to sort arrays of non-primitive type in Java SE 7, on the Android platform, in GNU Octave, and Google Chrome.
一月的時候 Google 就提出了「Manifest V3」，打算閹掉 extension 透過 webRequest 攔截連線的能力，而這個功能就是 uBlock Origin 這類 ad blocker 的基礎。
當時 Google 宣稱 webRequest 嚴重影響瀏覽器效能，但 Ghostery 的團隊則做了實驗證明影響極小：「Ad blocker performance study in response to Manifest V3 finds that Ghostery's ad blocker beats the competition」、「Google遭證據打臉，廣告封鎖程式幾乎不影響Chrome效能」。
All content-blockers except DuckDuckGo have sub-millisecond median decision time per request.
另外在 Alphabet (Google 母公司) 遞交給美國證管會的資料 (FORM 10-K) 可以看到他們把 ad blocker 視為威脅：「goog10-kq42018.htm」。
New and existing technologies could affect our ability to customize ads and/or could block ads online, which would harm our business.
Technologies have been developed to make customizable ads more difficult or to block the display of ads altogether and some providers of online services have integrated technologies that could potentially impair the core functionality of third-party digital advertising. Most of our Google revenues are derived from fees paid to us in connection with the display of ads online. As a result, such technologies and tools could adversely affect our operating results.
所以後續的行為就很清楚了，他們決定 Manifest V3 還是會閹掉 webRequest (以有效抑制 ad blocker 的能力，反正繼續堅持效能問題，當作沒聽到)，只開放企業版本使用：「Google to restrict modern ad blocking Chrome extensions to enterprise users」。
在 Mozilla 愈來愈不成氣候的情況下，現在要看的戲應該是 Google 是否會因此受到 anti-trust 的挑戰呢...
Googlebot 先前一直都是用 Chrome 41 版的引擎在跑，如果要考慮 SEO (for JavaScript)，就得確認網站在 Chrome 41 上面可以執行 (於是 ES6 就...)。
今天從 John Resig 的 Twitter 上看到 Googlebot 更新了引擎：「The new evergreen Googlebot」。
The day has finally arrived - Googlebot is now evergreen!!! https://t.co/pByE8WWjYT Time to drop so many polyfills, this is really exciting!
— John Resig (@jeresig) May 7, 2019
這樣針對 JS 的 SEO 省了不少事情...
前陣子看到「JavaScript Loading Priorities in Chrome」這篇，在分析 Google Chrome 對各種 JavaScript 的優先順序。
優先順序分成讀取的「Loading priority (network/Blink)」與執行的「Execution priority」，另外文章裡也有整理建議「Where should this be used?」。
看起來 <script defer> at the end of <body> 是全部裡面最低的，建議是給 Load "Related articles" 或是 "Give feedback" 這類功能，不過應該沒什麼人真的這樣用...
然後要注意的是，這邊分析的對象是 Google Chrome，實際在設計時應該要先考慮一般性的定義，再考慮對各瀏覽器的最佳化... (雖然以現在市占率來說沒什麼人想管其他瀏覽器...)