Fabrice Bellard 的 QuickJS

Fabrice Bellard 跑去寫了一套 JavaScript engine 出來:「QuickJS」。

以 ES2019 當底實做的 JS engine:

Almost complete ES2019 support including modules, asynchronous generators and full Annex B support (legacy web compatibility).

測試的部份也過了:

Passes 100% of the ECMAScript Test Suite.

在大小的部份,比起其他的 engine (與 package) 來說的確是小很多,不過 190KB 這個大小對於 embedded system 來說還是有點微妙 (但對於想要包 JS engine 進去用的人應該是頗開心的):

Small and easily embeddable: just a few C files, no external dependency, 190 KiB of x86 code for a simple hello world program.

不愧是 Fabrice Bellard,搞出了 LZEXEFFmpegQEMU 後跑來搞 JS...

移除 Blog 上的 Google Analytics,改用 Matomo

跑了快一個月了,大概整理一下...

一直都有在規劃降低對 Google 服務的依賴性,最主要的是使用 DuckDuckGo 替代 Google Search (但搜尋的品質還是差一截,所以寫了一些工具幫助我在不滿意的時候可以快速切到 Google 搜尋:「在 DuckDuckGo 搜尋頁快速切換到 Google 的套件」)。

而最近在研究的另外一個服務是 Google Analytics,我只用很基本的功能 (像是熱門文章,作業系統與瀏覽器的比率這些很基本的資料),不需要對於觀看客群有了解 (這個需要像 Google Analytics 跨站蒐集資料),所以替代方案應該不難找...

憑著印象與一些關鍵字,找到了 Matomo,這是一套 open source 的 web analytics 服務,以前叫做 Piwik (參考「Piwik is now Matomo - Announcement」),整個系統用 PHP + MySQL 就可以打發 (反正量不大的東西不需要拿什麼神兵利器出來,MySQL 硬塞硬算就可以了),接著把本來 Google Analytics 的 js 換掉就行了...

跑了快一個月後感覺還 ok,基本的資訊都有...

補上 WordPress 編輯器的 accesskey

WordPress 編輯文章時我還是習慣用傳統編輯界面自己修改主要的 html tag,像是這樣:

上面那些按鈕在很久以前的版本透過 accesskey 用鍵盤快速輸入各種連結與效果,但後來就被拿掉了... 不過可以在「Adding WordPress Custom QuickTags」這邊看到一些文章有提到過。

研究了一下 WordPress 的 minimal plugin 有哪些東西,看起來也不難寫,就花了些時間用 js 操作,這樣編輯起來方便多了... 程式包起來放到 gslin/wp-editor-accesskey 上,有需要的也可以拿去用,不過我猜現在還這樣寫文章的人不多了...

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.

Salesforce 弄了一個新的玩意出來...

然後在 Hacker News 上被酸爆了:「Open-sourcing the Lightning Web Components framework (salesforce.com)」。引用的原文在「Introducing Lightning Web Components Open Source」這邊。

主要還是大家已經厭倦前端一直丟東西出來,但是速度一直都沒什麼改善... 用傳統的 server rendering 反而省了不少 client 端的 CPU resource。

話說回來,前幾天的伺服器爆炸好像沒看到什麼後續新聞... (參考「Salesforce enables modify all in all user profiles」、「Salesforce系統更新意外造成權限擴張,用戶服務被迫中斷」)。

Firefox 引入 BigInt,Safari 也在實作...

Firefox 實作了 BigInt (進度可以在「Implementation of BigInt values for SpiderMonkey」這邊看到):「bigint shipping in firefox!」,現在可以在 68 beta 版裡使用:

I am delighted to share with folks the results of a project I have been helping out on for the last few months: implementation of "BigInt" in Firefox, which is finally shipping in Firefox 68 (beta).

另外文中也提到了其他瀏覽器的情況 (再 Can I Use 也可以看到「BigInt」目前的支援情況),用 V8 engine 的都已經支援 (包括 Chrome 與新版的 Edge),而 Safari 也在實作中:

BigInt is also shipping already in V8 and Chrome, and my colleague Caio Lima has an project in progress to implement it in JavaScriptCore / WebKit / Safari. Depending on your target audience, BigInt might be deployable already!

另外一個有趣的事情是 license,其中馬上可以想到的是 GMP,裡面牽扯到 LGPLv3GPLv2 的授權問題:

Since version 6, GMP is distributed under the dual licenses, GNU LGPL v3 and GNU GPL v2. These licenses make the library free to use, share, and improve, and allow you to pass on the result. The GNU licenses give freedoms, but also set firm restrictions on the use with non-free programs.

從說明有提到一些目標,短期可能會用 GMP 以儘快時做出合理的效能版本,長期則是希望用自己的版本:

An important design question is whether to implement the arithmetic operators as native or self-hosted intrinsics, probably using an external library such as GMP in the former case. Using an existing library has the advantage of providing good performance for less initial effort, but a self-hosted library also has advantages, such as greater flexibility in representation, better compiler integration, and simpler integration with the rest of the JS runtime (GC, etc.).

2018 年一月的討論有提到有一包 patch 是使用 GMP 的版本,這樣看起來應該是有解決 license 上的問題...

The current version of the patch uses libgmp for BigInt arithmetic, supports most features from the current proposal, and passes all up-to-date test262 tests for BigInt. Direct compiler support for BigInt has been removed; instead, compilation should fail if a possible BigInt value is encountered.

後續的描述裡面也都有提到 GMP 相關的事情,應該是沒錯...

利用 Sensor 校正資訊產生 Device Fingerprint 的隱私攻擊

看到「Fingerprinting iPhones」這篇提出的攻擊,標題雖然是提到 iPhone,但實際上攻擊包括了 Android 的手機:

You are affected by this fingerprinting attack if you are using any iOS devices with the iOS version below 12.2, including the latest iPhone XS, iPhone XS Max, and iPhone XR. You are also likely to be affected if you are using a Pixel 2/3 device, although we hypothesise the generated fingerprint has less entropy and is unlikely to be globally unique. A SensorID can be generated by both apps and mobile websites and requires no user interaction.

目前 iPhone 升級到 12.2 之後可以緩解這個問題,Android 看起來還不清楚...

攻擊的方式是透過手機在出場前會使用外部的校正工具,找出手機內 sensor 所偵測到的值與實際值的差異,然後把這些資訊燒到韌體裡,當呼叫 API 時就可以修正給出比較正確的值。

而因為這些校正資訊幾乎每一隻手機都不一樣,而且不會因為重裝而變更 (即使 factory reset),加上還可以跨 app 與 web 追蹤,就成為這次攻擊的目標:

In the context of mobile devices, the main benefit of per-device calibration is that it allows more accurate attitude estimation.

資訊量其實相當大,透過 app 分析可以得到 67 bits entropy,透過網頁也有 42 bits entropy,而且不怎麼會變:

In general, it is difficult to create a unique fingerprint for iOS devices due to strict sandboxing and device homogeneity. However, we demonstrated that our approach can produce globally unique fingerprints for iOS devices from an installed app -- around 67 bits of entropy for the iPhone 6S. Calibration fingerprints generated by a website are less unique (~42 bits of entropy for the iPhone 6S), but they are orthogonal to existing fingerprinting techniques and together they are likely to form a globally unique fingerprint for iOS devices.

We have not observed any change in the SensorID of our test devices in the past half year. Our dataset includes devices running iOS 9/10/11/12. We have tested compass calibration, factory reset, and updating iOS (up until iOS 12.1); the SensorID always stays the same. We have also tried measuring the sensor data at different locations and under different temperatures; we confirm that these factors do not change the SensorID either.

目前提出來的解法是加入隨機值的噪音 (iOS 的作法),不過作者有建議預設應該要關閉 js 存取 sensor 的權限:

To mitigate this calibration fingerprint attack, vendors can add uniformly distributed random noise to ADC outputs before calibration is applied. Alternatively, vendors could round the sensor outputs to the nearest multiple of the nominal gain. Please refer to our paper for more details. In addition, we recommend privacy-focused mobile browsers add an option to disable the access to motion sensors via JavaScript. This could help protect Android devices and iOS devices that no longer receive updates from Apple.

不過當初這群人怎麼會注意到的...

GitHub 推出 Package Registry

GitHub 推出了「GitHub Package Registry」,可以代管自己開發的軟體。

目前支援 npm (Node.js)、DockerMaven (Java)、NuGet (.NET)、RubyGems (Ruby) 五個平台,

隔壁 GitLab 說我們早就有了而氣噗噗中:「Packaging now standard, dependency proxy next?」。

Anyway,省下一些事情,以前會透過 CI/CD 丟到像是 packagecloud.io 這樣的服務上讓內部使用,現在看起來 GitHub 上面可以解決一些簡單的情境...

Googlebot 會用新版的 Chrome 跑 JavaScript 了

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

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

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

針對 JavaScript 時代調整網頁的效能評估指標

早期網頁的效能評估指標都沒有考慮 JavaScript 的情況,大多都是 TTFB (Time to First Byte) 或是網頁大小以及 DOMContentLoaded 或是 load 這類 DOM event 為主,但因為 Goodhart's law,現代的網頁設計會故意將許多 JavaScript 要做的事情搬到 load 以後開始做,以降低 load 被延遲的問題,讓前端的「KPI」比較好看:

When a measure becomes a target, it ceases to be a good measure.

但在 load 之後整個網站還是不能用,使用者的體驗其實很差,這個評估方式的價值變低不少。所以「Measuring Jank and UX」這篇就再找出一些新的指標,來評估 JavaScript 造成的問題。

可以看到文章裡面評估了很多關於 CPU loading 與操作時間的指標,也許這一兩年還會有用,不過我覺得還是會遇到 Goodhart's law 描述的問題... XD