WebKit 要支援 nested CSS 了

從龍哥這邊看到的消息,WebKit 要支援 nested CSS 了:

原文在「Try out CSS Nesting today」這邊,就是這樣的寫法:

.foo {
  color: green;
 .bar {
    font-size: 1.4rem;


比較特別的是在 nested CSS 中不支援 element 的指定:

main {
 article { ... }


That code will fail, because article begins with a letter, and not a symbol. How will it fail? The same way it would fail if you’d misspelled article as atirlce. The nested CSS which depends on that particular selector is simply ignored.


main {
 & article { ... }


iOS 12.5.6

早上發現 iPhone 6 Plus 被自動更新到 iOS 12.5.6,查了一下發現是八月底的時候 Apple 推了一版 WebKitACECVE-2022-32893:「About the security content of iOS 12.5.6」。

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.

Description: An out-of-bounds write issue was addressed with improved bounds checking.

上個更新的版本 12.5.5 是 2021/09/23 出的,本來大家都以為已經沒有任何更新了,沒想到居然回過頭來發了一包,照蘋果的敘述看起來是因為這個洞被廣泛使用的關係?

iPhone 5S (目前 iOS 12 支援列表裡最早出的手機) 是 2013 下半年出的,到現在也九年了...

WebKit 專案將從 Subversion 搬到 GitHub 上

Hacker News 首頁上看到 WebKit 專案宣佈從本來的 Subversion 搬到 GitHub 上:「WebKit on GitHub!」,新的專案位置在 WebKit/WebKit 這邊。對應的討論在「WebKit Migrates from Subversion to GitHub (webkit.org)」這邊。

但 issue tracking system 的部份目前看起來還是繼續用 WebKit Bugzilla,沒有開 GitHub 的 issue 功能,但至少是從 Subversion 換成 Git 了。

在 Hacker News 上的討論意外看到已經是歷史的 SVK (試著在 Subversion 上面堆一些功能),而且還聊到了一些 tricky 的技巧:

Funny story: my first task when I joined the original iPhone team was to merge our forked WebKit with master. It was a sort of hazing ritual slash "when else would we do it but when someone new joins?". Anyways, we used a tool called SVK[1] in order to get very primitive "git-like" abilities. It was basically a bunch of scripts that used SVN under the hood. For example, in order to get the "local everything"-style behaviors of git, the very first thing it did was checkout every single version of the repository in question. For WebKit, this meant that the first day was spent leaving the computer alone and letting it download for hours. I made the mistake of having a space somewhere in the path of the target folder, which broke something or other, so I ended up having to do it all over again.

Anyways, I distinctly remember one of the instructions for merging WebKit in our internal wiki being something like "now type `svk merge`, but hit ctrl-c immediately after! You don't want to use the built-in merge, it'll break everything, but this is the only way to get a magic number that you can find stored in [some file] after the merge has started. If it's not there, try `svk merge` again and let it go a little longer than last time." A few hires later (I think possibly a year after) someone set up a git mirror internally to avoid having to do this craziness, which if I remember correctly, was treated with some skepticism. This was 2007, so why would we try some new-fangled git thing when we had svk?

1. https://wiki.c2.com/?SvkVersionControl

我記得那個時間點 VCS 的選擇的確是個有趣的決策過程... 除了 Git 以外還有 Mercurial,另外還有幾個當時就已經算小眾的 open source solution。

而到了 2010 後就比較明朗了,現在幾乎是 Git 一統天下了,Mercurial 目前最大的使用者應該是 Meta (Facebook)?

Webkit 的「反追蹤反追蹤」功能...

第一次看到標題的時候的確是 WTF 的感覺,愈來愈感覺到大戰的開始:「Preventing Tracking Prevention Tracking」。

在蘋果的平台上有 Intelligent Tracking Prevention (ITP) 功能,但先前這個功能比較簡單,所以還是有很多地方可以被當作 browser fingerprint 的一部份分析,所以蘋果決定改善,然後在新版的軟體裡引入:

This blog post covers enhancements to Intelligent Tracking Prevention (ITP) included in Safari on iOS and iPadOS 13.3, Safari 13.0.4 on macOS Catalina, Mojave, and High Sierra.

包括了跨站台時 Referer 的省略:

ITP now downgrades all cross-site request referrer headers to just the page’s origin. Previously, this was only done for cross-site requests to classified domains.

然後後面三個改善都跟 3rd-party cookie 有關,其中預設擋掉帶 cookie 的 3rd-party requests 應該會讓一些網站掛掉:

ITP will now block all third-party requests from seeing their cookies, regardless of the classification status of the third-party domain, unless the first-party website has already received user interaction.

早期自己做自家 SSO 的奇技淫巧中,會設計出透過 ajax 打多個不同的網域自動登入,看起來應該會需要檢查了...

Apple 對 Tracking 機制的宣言 (宣戰)

Apple 透過 WebKit 的 blog 公佈了對 tracking 技術的宣言 (或者說「宣戰」):「Announcing the WebKit Tracking Prevention Policy」,完整的文件在「WebKit Tracking Prevention Policy」可以看到。

相關的報導可以參考「Apple will soon treat online web tracking the same as a security vulnerability」。這篇會這樣下標題主要是這點:

We treat circumvention of shipping anti-tracking measures with the same seriousness as exploitation of security vulnerabilities.



WebKit 對 HSTS Super Cookie 提出的改法

Twitter 上看到 WebKitHSTS 所產生的 Super Cookie 提出的改善方案:

拿原文的例子來說明,先指定一個隨機數給 user,像是 8396804 (二進位是 100000000010000000000100),所以就存取下面的網址:


在存取這些 HTTPS 網址時都會指定 HSTS,所以之後連到這三個網址的 HTTP request 就不會觸發到 HTTP 版本,會因為 HSTS 被轉到 HTTPS 版本。於是就可以用 32 個 HTTP request 測試 32bits 而判斷出身份。(當然你可以用更多)

WebKit 提出的改善方案大概有幾種,主要是就觀察到的現象來限制。

第一種解法「Mitigation 1: Limit HSTS State to the Hostname, or the Top Level Domain + 1」是因為會看到這樣的設計:


所以提出的方案是只有目前網站的 domain 以及 top domain + 1 (像是 example.com) 可以被設定 HSTS:

Telemetry showed that attackers would set HSTS across a wide range of sub-domains at once. Because using HSTS in this way does not benefit legitimate use cases, but does facilitate tracking, we revised our network stack to only permit HSTS state to be set for the loaded hostname (e.g., “https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com”), or the Top Level Domain + 1 (TLD+1) (e.g., “https://example.com”).

但其實廣告主只需要註冊 32 domains (或是 64) 就可以避開這個問題。

第二種是「Mitigation 2: Ignore HSTS State for Subresource Requests to Blocked Domains」,如果在 HTTPS 頁面上,某個 domain 的 cookie 已經因為某些原因被阻擋 (像是手動設定),那麼就忽略掉 HSTS 的設計:

We modified WebKit so that when an insecure third-party subresource load from a domain for which we block cookies (such as an invisible tracking pixel) had been upgraded to an authenticated connection because of dynamic HSTS, we ignore the HSTS upgrade request and just use the original URL. This causes HSTS super cookies to become a bit string consisting only of zeroes.

後面這點在現在因為 SEO 設計而使得各大網站都往 HTTPS 方向走,應該會有些幫助吧...

Safari 也有測試版本了

如標題所說的,現在 Apple 的團隊決定提供測試版本的 binary 了:「Introducing Safari Technology Preview」。可以在「Safari Technology Preview」下載到,版號從 1 開始跳 XD

類似於 Google ChromeFirefox 的 channel 機制,開另外一條線讓大家玩新東西。

Webkit 推出 B3 JIT Compiler (Bare Bones Backend)

Webkit 推出了 B3 加快 optimization 的速度,取代原來 LLVM 的工作:「Introducing the B3 JIT Compiler」。

在文章後方 Performance Results 的部份可以看到最主要的差異在啟動時間:

另外也可以看到其他各種 performance benchmark 也幾乎都是小勝 LLVM。

接下來會有 ARM64 與其他平台的計畫:

B3 is not yet complete. We still need to finish porting B3 to ARM64. B3 passes all tests, but we haven’t finished optimizing performance on ARM. Once all platforms that used the FTL switch to B3, we plan to remove LLVM support from the FTL JIT.

jQuery 1.11.2 與 2.1.3 修正 iOS 8 上 Safari 7.1/8 的嚴重 bug

看到 jQuery 官方放出一個特別更新,專門為了 iOS 8 + Safari 7.1/8 的修正:「jQuery 1.11.2 and 2.1.3 Released – Safari Fail-Safe Edition」。

依據「Test failure on iOS 8: child and adjacent -> p#firstp + p」的說明,死在 document.querySelectorAll("p#firstp + p") 這邊,另外以下的 selector 也都掛掉:

p#a + p
p#a ~ p
.b#a ~ [id]
[style]#a ~ p

由於這個用法太基本,讓 jQuery 官方決定在 library 放 workaround 修正這個問題...

HTTP Header 裡與安全相關的 Header 的分析...

還是在 Zite 上看到的,對最大的一百萬個網站分析與安全有關的 HTTP Header:「Security Headers on the Top 1,000,000 Websites: November 2013 Report」。

數字大致上都有增加,不過對我來說的重點在於有列出所有與安全有關的 HTTP Header...


  • Access-Control
  • Content-Security-Policy
  • Strict-Transport-Security
  • X-Content-Security-Policy
  • X-Frame-Options
  • X-Webkit-CSP

剛好可以拿來 review 設定...