Home » Computer » Software » Archive by category "Browser" (Page 3)

Googlebot 的 Web rendering service 的細節

在「Polymer 2 and Googlebot」這邊文章裡面才看到 Google 官方在今年八月就有公開 Googlebot 所使用的 Web rendering service (WRS) 的細節:「Rendering on Google Search」。可以想像到是基於 Google Chrome 的修改:

Googlebot uses a web rendering service (WRS) that is based on Chrome 41 (M41). Generally, WRS supports the same web platform features and capabilities that the Chrome version it uses — for a full list refer to chromestatus.com, or use the compare function on caniuse.com.

裡面提到一些值得注意的事情,像是不支援 WebSocket,所以對於考慮 Google 搜尋結果的頁面來說,就要注意錯誤處理了...

Yahoo! 與 Mozilla 針對預設搜尋引擎的事情戰起來了...

Mozilla 先前終止與 Yahoo! 的合作後 (在 Firefox 內預設使用 Yahoo! 的搜尋引擎),Yahoo! 提告以及 Mozilla 還手的消息在最近被 Mozilla 揭露:「Mozilla Files Cross-Complaint Against Yahoo Holdings and Oath」。

Yahoo! 提告的檔案 (PDF) 在「2017-12-01-Yahoo-Redacted-Complaint.pdf」,Mozilla 還手的檔案 (PDF) 則是在「2017-12-05-Mozilla-Redacted-X-Complaint-with-Exhibits-and-POS.pdf」這邊。

Firefox 57 釋出時,Mozilla 就把預設的搜尋引擎改回 Google (參考「Mozilla terminates its deal with Yahoo and makes Google the default in Firefox again」),不過當時 Firefox 57 更大的消息是推出了 Quantum,讓瀏覽器的速度拉到可以跟目前的霸主 Google Chrome 競爭的程度,所以就沒有太多人注意到這件事情...

過了幾個禮拜消息比較退燒後,被告以及反過來告的消息出來後,才注意到原來換了搜尋引擎... XD

旁邊搖旗吶喊沒什麼用,就拉板凳出來看吧...

Happy Eyeballs (RFC 6555)

在「PChome 24h 連線會慢的原因...」這篇的 comment 有讀者提到了 Happy Eyeballs 應該可以解決這個問題:

除了可以在維基百科上面看到外,比較正式的說明可以參考 RFC 6555:「Happy Eyeballs: Success with Dual-Stack Hosts」,其中在「6. Example Algorithm」就有提到 Google ChromeMozilla Firefox 怎麼實做 Happy Eyeballs:

What follows is the algorithm implemented in Google Chrome and Mozilla Firefox.

  1. Call getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy.
  2. Initiate a connection attempt with the first address in that list (e.g., IPv6).
  3. If that connection does not complete within a short period of time (Firefox and Chrome use 300 ms), initiate a connection attempt with the first address belonging to the other address family (e.g., IPv4).
  4. The first connection that is established is used. The other connection is discarded.

If an algorithm were to cache connection success/failure, the caching would occur after step 4 determined which connection was successful.

Other example algorithms include [Perreault] and [Andrews].

可以看到 Happy Eyeballs 的演算法是要避免 IPv6 network 不通的情況卡住很慢 (如果在 300ms 內連線沒有建起來,就會儘快往另外一個 address family 嘗試),而不是在 DNS 層避免問題 (也就是 getaddinfo() 觸發的 DNS query)。

這次的情況是 DNS query 很慢,就會導致還是一開始就很慢,Happy Eyeballs 沒辦法解決這個問題。

不過話說回來,我是有印象知道有這個演算法,但不知道有「Happy Eyeballs」這個這麼逗趣的名字... (掩面)

所有主流瀏覽器的最新版都支援 WebAssembly 了

Mozilla 的「WebAssembly support now shipping in all major browsers」提到了最近幾個禮拜,新版的 SafariEdge 都相繼支援 WebAssembly 了:

In the past weeks, both Apple and Microsoft have shipped new versions of Safari and Edge, respectively, that include support for WebAssembly.

由於 ChromeFirefox 都已經支援了,這宣告 WebAssembly 的障礙都已經排除了,接下來只是時間的問題... 對於需要效能的應用程式來說多了一個方式加速。

把 Ptt 網頁版 Imgur 的圖片換回來...

Ptt 網頁版不知道什麼時候開始把 Imgur 的圖片變成 embed 版本了,圖很小又有留白一堆東西,看起來不太舒服...

剛剛寫了個 Greasemonkey script 換回來:「gslin/ptt-imgur-cleaner-gm」。已經有安裝 Userscript 管理軟體的,可以在 OpenUserJS 上安裝:「Ptt Imgur Cleaner」。

程式做幾件事情,一件是加上 meta tag 不要送 Referrer,然後用圖片換掉 Imgur 產生出來的 iframe,另外一個是把 .richcontentmax-width 設為 100%。

這樣看 Ptt 的文章應該會方便一些...

Update:結果有朋友說當初是因為被 Imgur 擋掉所以才換成 embed 的... (大概是量太大的關係)

強制 Facebook 的「時間軸」依照時間排序

TechCrunch 的「How I cured my tech fatigue by ditching feeds」這篇提到了 Social Network 成隱的問題:

Many people have deleted the Facebook app from their phone to avoid this mindless habit. “What’s going on in my feed?” they think. Then they scroll, scroll, scroll, get bored and close the app. Repeat this process every 30 minutes. Deleting the app is the best way to take a stance and say that Facebook is a waste of time.

砍掉 Facebook 是一個還不錯的方法,但如果還是有使用 Facebook 需求,就只好想辦法降低 Facebook 帶來的影響。其中我找的方法是強制切到 Most Recent 版本,降低 Facebook 演算法的介入。

昨天剛好在重新處理機器,發現之前用的那個 Google Chrome 套件不見了,只好找看看有沒有替代方案,後來翻到這個:「Facebook Most Recent News Feed」。

如果看裡面程式碼,其實做的事情很簡單,就是硬切過去:

chrome.webRequest.onBeforeRequest.addListener(
    function(info) {
        if (info.url === 'https://www.facebook.com/') {
            return {
                redirectUrl: 'https://www.facebook.com/?sk=h_chr'
            }
        }
    }, {
        urls: [
            "https://www.facebook.com/*"
        ],
        types: ["main_frame"]
    }, ["blocking"]
);

當然,如果能考慮整個移除的話也是不錯啦...

Firefox 計劃性的將 Tor Browser 提供的隱私保護移植回 Firefox 瀏覽器上

Tor Browser 是個基於 Firefox 改出來的瀏覽器,將 Tor 包進去,讓使用者可以很方便的直接透過 Tor 上網,不需要另外再安裝其他程式。

Twitter 上看到 The Tor Project 的這則 tweet,提到 Tor Browser 阻擋 Canvas Fingerprinting 的功能將被移植回 Firefox:

將會在 Firefox 58 (現在是 56) 可以用到這個功能:「Prompt (w/ Site Permission) before allowing content to extract canvas data (Tor 6253)」。借用 Tor Browser 阻擋的範例,之後可能會長這樣:

另外也提到了這其實是 Tor Uplift 計畫中的一個項目:

Firefox 直接支援後,Tor Browser 也可以少維護一段程式碼...

Let's Encrypt 的 Embed SCT 支援

翻到 Let's EncryptUpcoming Features 時看到:

Embed SCT receipts in certificates
ETA: February, 2018

對 Embed SCT 不熟,所以查了查這個功能。

這指的是在簽發 SSL certficiate 後,把資料丟給 Certificate Transparency (CT) 伺服器後,伺服器會提供 signed certificate timestamp (SCT);而這個資料放到 SSL certificate 內叫做 Embed SCT:(出自 CT 的 FAQ)

What is an SCT?
An SCT is a signed certificate timestamp. When a certificate authority or a server operator submits a certificate to a log, the log responds with an SCT. An SCT is essentially a promise that the log server will add the certificate to the log in a specific time. The time, known as the maximum merge delay (MMD), helps ensure that certificates are added to logs in a reasonable time. The SCT accompanies the certificate until the certificate is revoked. A TLS server must present the SCT to a TLS client (along with the SSL certificate) during the TLS handshake.

當使用 ECC 時會小於 100 bytes:

How big is an SCT?
SCTs are less than 100 bytes, assuming elliptic curve signatures are used.

這樣才能試著解釋前幾天提到要拔掉 HPKP 的事情:「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」,也就是為什麼他們是提 CT 解,而不是 DNS CAA 解...

不過我記得 CT server 可以自己架自己 submit 不是嗎?後來有另外規定一定要用第三方的嗎?這樣又很怪...

Chromium 內提案移除 HPKP (HTTP Public Key Pinning)

Twitter 上看到這則 tweet,提到要移除 HPKP (HTTP Public Key Pinning):

blink-dev 上的討論可以參考「Intent To Deprecate And Remove: Public Key Pinning」(就是上面那個連結,只是拉出來)。

這個提案大概可以推敲出理由... 目前的作法必須寫進瀏覽器內,這樣明顯會有 scale 問題,而且這個作法本身就很 workaround,只能保護所謂「高價值」的 domain,而且因為是綁在 Public Key 上,如果 CA 換了 Intermediate Certificate 就有可能會導致檢查過不了。

另外一方面,scale 而且合理的替代方案已經發展出來了。如果瀏覽器會檢查 DNS CAA 資訊 (這個規格可以在 DNS 裡設定有哪些 CA 可以簽這個 domain),就能解這個問題 (加上 DNSSEC 會更加確保驗證過程)。像是這樣:

example.com.    IN      CAA     0 issue "letsencrypt.org"
example.com.    IN      CAA     0 issuewild ";"

不過這個提案本身提到 CT (Certificate Transparency) 怪怪的,因為 CT 無法避免惡意的簽發 (發了以後故意不送 CT):

Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)

但在瀏覽器支援 DNS CAA 可以避免,結果在討論時都沒到 DNS CAA...

另外在 Hacker News 上也有討論:「Public Key Pinning Being Removed from Chrome (groups.google.com)」可以看一下,有個人有提到用 DNS CAA 的方法...

不過印象中這群人對 DNS-based 的方案都不太喜歡,所以也有可能是這樣不考慮在瀏覽器端實作 DNS CAA 吧...

Archives