JavaScript 的 sort 變成 stable

看到「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 外,還可以保證最差的情境下的時間複雜度是 O(n*log(n))

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 採用這個演算法以外,其他常見的包括了 PythonAndroid 上的 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 要對 ad blocker 全面宣戰了...

一月的時候 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 跑 JavaScript 了

Googlebot 先前一直都是用 Chrome 41 版的引擎在跑,如果要考慮 SEO (for JavaScript),就得確認網站在 Chrome 41 上面可以執行 (於是 ES6 就...)。

今天從 John ResigTwitter 上看到 Googlebot 更新了引擎:「The new evergreen Googlebot」。

這樣針對 JS 的 SEO 省了不少事情...

Chrome 對各種 JavaScript 的優先順序

前陣子看到「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,實際在設計時應該要先考慮一般性的定義,再考慮對各瀏覽器的最佳化... (雖然以現在市占率來說沒什麼人想管其他瀏覽器...)

Chrome 72+ (目前在 Beta 的版本) 對延伸套件的影響

我的桌機平常都是跑 beta channel 的 Chrome,所以前陣子已經升級到 72,然後發現兩個問題:

從 dev console 可以看到問題都是 Referer 沒被送出,導致有檢查 Referer 的網站拒絕存取,後來在「chrome.webRequest」這邊發現是 Chrome 72+ 改了規則,裡面提到了:

Starting from Chrome 72, the following request headers are not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

Accept-Language
Accept-Encoding
Referer
Cookie

Starting from Chrome 72, the Set-Cookie response header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec.

不確定這個設計的目的是什麼,但反正已經中獎了,總是得回報給各 extension 的維護者讓他們修正 (用 beta channel 的重要任務之一?)。

所以就先去 Tampermonkey 開 ticket,也很迅速的在 beta 版修正了 (所以只能先改裝 beta 版):「GM_xmlhttpRequest unable to set referer in Chrome 72+ #629」。

另外跟 Referer Control 的開發者回報這個問題,也修正出新版上架了,更新就生效了:「refererControlDisqus.html」。

目前看起來還有「Spoofs Lang」得修,不過這個軟體好久沒更新了,不知道有沒有機會...

所以要開始開發 CECPQ2 了...

CECPQ1Google 在研究對抗量子電腦的演算法,作為測試用的演算法,曾經在 Google Chrome 的 54 beta 版 (2016 年) 存活過一段時間,最近又開始在開發新一代的演算法 CECPQ2 了,這次會是基於 TLS 1.3 上測試:「CECPQ2」。

CECPQ2 will be moving slowly: It depends on TLS 1.3 and, as mentioned, 1.3 is taking a while. The larger messages may take some time to deploy if we hit middlebox- or server-compatibility issues. Also the messages are currently too large to include in QUIC. But working though these problems now is a lot of the reason for doing CECPQ2—to ensure that post-quantum TLS remains feasible.

目前對抗量子電腦的演算法好像都跟 Lattice 有關,找時間來補一下基礎理論... @_@

批評 Medium 不適合當作 Blogging Platform...

這篇文章批評了 Medium 不適合當作 Blogging Platform:「Medium is a poor choice for blogging」。

文章裡提到的情況我之前也常遇到 (然後默默的點 X 關掉...),我是還蠻建議把 [*.]medium.com 放到 Google Chrome 的 javascript 禁止清單裡面,這樣畫面會乾淨很多,而且也省很多 CPU 資源...

不過自訂網域的部分就沒辦法用這個方式擋了,有點可惜...

Mozilla 跟 Google 都宣佈了 TLS 1.0 與 TLS 1.1 的退役計畫

UpdateApple 也宣佈了,時間點跟大家都差不多:「Deprecation of Legacy TLS 1.0 and 1.1 Versions」。

Mozilla 宣佈了「Removing Old Versions of TLS」,而 Google 也宣佈了「Modernizing Transport Security」,兩篇都是講自家瀏覽器 TLS 1.0 與 TLS 1.1 的退役時程。

Mozilla 這邊的計畫是 2020 年三月移除:

In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.

Google 這邊的計畫則是 Chrome 81 移除,換算成時間會從 2020 年一月開始影響到 canary channel,到 release channel 應該跟 Firefox 差不多時間:

In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.

差不多試從現在開始的一年半。

雖然這是講瀏覽器端的支援,但如果伺服器想要只支援 TLS 1.2+ 的話,就得考慮一下舊 client 支援的情況了。

桌機影響會比較小 (升級比較方便,替代方案也比較多),而行動平台看起來需要 Android 4.4+、iOS 7+,就要看各網站或是服務的族群了...

Cloudflare 決定支援 QUIC

Cloudflare 決定支援 QUIC 了:「Get a head start with QUIC」、「The QUICening」。

QUIC 目前被使用的範圍比較小 (相較於 HTTP/2):

  • 主流瀏覽器內只有 Google Chrome 有支援 QUIC,其他主流瀏覽器都沒有支援。不過 Google Chrome 也夠大了...
  • 因為是走 UDP,所以防火牆要另外開。

而 Google Chrome 上面可以安裝「HTTP/2 and SPDY indicator」看到連線的狀態。雖然套件名稱沒有 QUIC,但實際上是可以看出 QUIC 的,基本上 Google 的服務應該都是走 QUIC。