HTML 的 preconnect

在「Preconnect」這邊看到 Preconnect 這個功能,目前在 Mozilla FirefoxGoogle Chrome 以及 Opera 都有支援,用法也很簡單:

<link rel="preconnect" href="//example.com">
<link rel="preconnect" href="//cdn.example.com" crossorigin>

感覺如果要用的話,可以先送出 head 的部分,打 flush 讓瀏覽器先收到後再送出其他部分?不過對 MVC 架構來說好像變複雜了,不知道有什麼設計比較好...

另外一個是 Prerender,目前是 IE11+、Google Chrome 以及 Opera 有支援,看起來也頗有趣的...

CloudFlare 對 Brotli 的測試

之前有提過這件事情,由於 Firefox 已經支援 Brotli 了 (Google 推出 Brotli 無損壓縮法),所以 CloudFlare 的人整理了目前的效能比較:「Results of experimenting with Brotli for dynamic web content」。

主要還是 Brotli 拿了不少資源來換壓縮率,對於 static content 由於可以事先算好而大勝不少 (大約可以再榨出 15% 的壓縮率,從 zlib 9 的 27.7% 降到 brotli 10 的 23.3%):

The current state of Brotli gives us some mixed impressions. There is no yes/no answer to the question "Is Brotli better than gzip?". It definitely looks like a big win for static content compression, but on the web where the content is dynamic we also need to consider on-the-fly compression.

另外對於大檔案、網路速度不快的連線來說也頗有幫助,但對於 on-the-fly 的壓縮反而會比較慢。

把 Google Chrome 的套件移植到 Firefox 上

在「Porting Chrome Extensions to Firefox with WebExtensions」這邊提到了 WebExtensions 計畫:

The technology is designed for cross-browser compatibility: to a large extent the API is compatible with the extension API supported by Google Chrome and Opera. Extensions written for these browsers will in most cases run in Firefox with just a few changes. The API is also fully compatible with multiprocess Firefox.

提供另外一種方式開發,吸引 Google Chrome 現有的 extension 開發者,也就是利用現有的 ecosystem 來幫助自己,把本來需要整個重寫的工作降低...

Let's Encrypt 的新進展

Let's Encrypt 宣佈有新的進度了,已經可以從 Root Certificate 簽其他的 SSL Certificate 了:「Our First Certificate Is Now Live」。

測試的網站在 https://helloworld.letsencrypt.org/ 這邊,目前應該還是屬於不信任狀態。一旦 cross sign 或是被加到瀏覽器內,這個網站應該就會馬上生效了。

接下來會同時做幾件事情:

總算又聽到新的進度了...

CNNIC 申請成為 CA/Browser Forum 成員

面對面的會議記錄,在第一天的會議記錄「2015-06-24 Face-to-Face Meeting 35 Minutes」的一開頭就看到 CNNIC 申請成為 CA/Browser Forum 的成員。

目前有兩個疑慮,第一個是執照的問題:

1. They don’t appear to be licensed in China (BRs requires that a CA be licensed in the country they do business if a licensing scheme is in place) and

第二個則是同時具有 CA 以及 ccTLD 註冊者的身份:

2. they appear to be a registrar for a TLD as well as a CA.

再來是第二天開頭就看到在討論 EV Wildcard 的問題 (目前是不被允許的),以及 Domain Validation 的問題。結尾則可以看到中華電信將會主辦 2017 的部份?不是很確定...

Host 2017

Chunghwa Telecom February or October (Taiwan)

Mozilla Developer Network (MDN) 上的 JavaScript 教學

Mozilla Developer Network (MDN) 寫了一篇關於 JavaScript 的介紹文章,算是以現在的角度來教 JavaScript:「A re-introduction to JavaScript (JS tutorial)」。

不是給完全不懂的人入門看的,而是對程式語言有了解的人看的。

文章裡面不單純只是教學,還引用了許多重要的文獻,尤其是 ECMAScript 規格書。有想要考據確認規格書怎麼定義會很方便。

而最後面還提到了 browser 上 DOM 實作時的 memory leak 問題以及解法,這對於現在 single page application 的應用也愈來愈重要了。

在瀏覽器上面用 JavaScript 進行 Side-channel attack

用 JavaScript 就可以攻擊 L3 cache,進而取得資料:「JavaScript CPU cache snooper tells crooks EVERYTHING you do online」。

論文出自「The Spy in the Sandbox – Practical Cache Attacks in Javascript」(PDF) 這篇。

不需要任何外掛或 exploit,就純粹是利用 cache 反應時間的 side-channel attack。另外由於 AMD 的 cache 架構不同,這次的攻擊實作僅對 Intel 有效:

The Intel cache micro-architecture isinclusive– all elements in the L1 cache must also exist in the L2 and L3 caches. Conversely, if a memory element is evicted fromthe L3 cache, it is also immediately evicted from the L2 and L1 cache. It should be noted that the AMD cachemicro-architecture is exclusive, and thus the attacks described in this report are not immediately applicable tothat platform.

這次的攻擊方法真變態...

CA/Browser Forum 討論網域認證與 CNNIC 的事情

兩個禮拜前 CA/Browser Forum 的會議記錄,討論了網域認證以及 CNNIC 的事情:「Minutes of CA-Browser Forum Meeting – 2 April 2015」。

由於 US-CERT 的關切,看起來「認證」這件事情 CA/Browser Forum 暫時不會有改善了:

The consensus was that US-CERT was incorrect in saying the email method of domain confirmation presents a vulnerability, that no changes were required, and that the Forum did not need to make any formal response to the US-CERT advisory.

另外是 CNNIC 的事情,也表達「甘我屁事」:

CNNIC sub-CA issue: The members discussed the recent CNNIC sub-CA issue, and noted that Google had recently published its response. Gerv stated that Mozilla was about to publish its response, which would be similar to the Google response. There was consensus that the Forum did not need to take any action.

很官僚的會議結論...

uBlock 的改版:交接後再 fork 成 uBlock Origin (uBlock₀)

原先的 µBlock 改名成 uBlock₀,並且把 uBlock 的名字交出去給了 Colorado SpringsuBlock

原因可以在「Please clarify uBlock₀ vs. uBlock」這邊看到,由於這不是 full time job (他也不想要成為 full time job),所以他決定 freeze 目前的功能,僅維持 bugfix (因為對他來說夠用了,他自己平常也在用)。

依照這個原因,我的感覺是 uBlock 會成圍下一個肥大的 ABP,就乖乖留守 uBlock Origin (uBlock₀) 吧。

關於 .onion SSL Certificate 的表決 (Tor Network)

關於 .onion 的 SSL Certificate,在 CAB Forum 這邊提出來表決了:「Ballot 144 – Validation rules for .onion names」。

有些時間限制與一般的 SSL Certificate 不太一樣:

CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD.

然後:

On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F.

等投票結束後再來看...