Home » Posts tagged "chrome"

把自動播放影片的功能關掉...

一堆國外新聞網站超愛這套,這不是 Flash 時代的搞法嗎,怎麼現在還這樣搞啊... 在 Google Chrome 內建的設定就可以關掉了,先進入 chrome://flags,然後選擇「Document activation is required.」:

中文版的 Chrome 不知道是翻成什麼,就自己翻譯猜一下吧...

在 Google Chrome 上關閉 AMP (Accelerated Mobile Pages)

裝了 Amplifier AMP/Canonical switcher,在 Google Chrome 上可以關閉 AMP 頁面 (Accelerated Mobile Pages)。專案的 GitHub 頁面在 jpettitt/amplifier

This extension is designed for developers working with the AMP (Accelerated Mobile Pages) standard. It detects AMP links in the page header and allows quick switching between the AMP and Canonical version of a page. Optionally AMP pages can be loaded with the AMP validation enabled (#development=1).

每一家的 AMP 連結結構都不一樣,所以就只好裝個套件快速切了...

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 搜尋結果的頁面來說,就要注意錯誤處理了...

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 的障礙都已經排除了,接下來只是時間的問題... 對於需要效能的應用程式來說多了一個方式加速。

CloudFlare 也要提供 Certificate Transparency 的 Log 伺服器了...

看到 CloudFlare 請求加入 Chromium (Google Chrome) 的伺服器列表:「Certificate Transparency - Cloudflare "nimbus2017" Log Server Inclusion Request」。

對照之前的「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」以及「Let's Encrypt 的 Embed SCT 支援」,這樣看起來是瀏覽器內會有一份白名單,只有在這白名單上的 Embed SCT 才會被信任...

但弄到這樣的話,log server 是不是也要有稽核機制?

好像哪邊搞錯了方向啊...

強制 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"]
);

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

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 吧...

Google Chrome 支援 APNG 了...

翻資料的時候才發現 Google Chrome 從 59 版 (今年六月進 stable channel) 就支援 APNG 了,這樣所有主流瀏覽器只剩下微軟家的 IE 與 Edge 還沒支援了:

找了一下當時的新聞:「Chrome 59 will fully support animated PNGs」,以及對應的 ticket:「Request for enhancement: APNG (animated PNG)」。

APNG 相較於 GIF 多了透明的設計 (GIF 需要拿一個顏色來當作透明),以及更多的色彩,但對於瀏覽器的支援一直都不完整:

The GIF file format has better application and browser support than APNG, but it is limited to 256 colors per frame and supports only index transparency, by mapping one of the palette colors to transparent.

現在這樣讓 GIF 退休的日子又前進了一大步...

Cloudflare 也能在各端點跑 JavaScript 了

類似於 AWS 先前推出的 Using CloudFront with Lambda@Edge (參考「在 CloudFront 的 edge 上跑 Lambda」以及「Lambda@Edge 的 GA」),Cloudflare 也推出了類似的功能:「Introducing Cloudflare Workers: Run Javascript Service Workers at the Edge」、「Code Everywhere: Why We Built Cloudflare Workers」。

整個系統是架構在 Chrome V8 上,尤其是安全性的部分是 Cloudflare 的人頗讚賞的重點:

Security: The V8 JavaScript engine is arguably the most scrutinized code sandbox in the history of computing, and the Chrome security team is one of the best in the world. Moreover, Google pays massive bug bounties to anyone who can find a vulnerability. (That said, we have added additional layers of our own sandboxing on top of V8.)

比較不一樣的地方在於 Cloudflare 拿 Service Worker API 來設計他們的架構,AWS 則是自己幹了一套出來...

然後現在還沒給出價錢,也還沒完全開放使用... 想要玩的人需要申請 beta。

Archives