Google Chrome 的新 tab 現在預設都會出現 search engine 頁面 (即使你設為 about:blank)，但我從來就沒有在這頁搜尋過東西 (都是直接在 location bar 輸入)，所以想要拿掉這個「功能」。
找到由 thakis@chromium.org 提供的 extension，而且是在 2013 年就發佈了：「Empty New Tab Page」，他給的截圖意思就很清楚了：
看了一下 source code 也的確是乾乾淨淨的，先裝這個...
Tag: chrome
Home » Posts tagged "chrome"
關閉 Google Search 的 JavaScript
關閉 Google Search 的 JavaScript 速度快好多，而且左方會有「中文」與「繁體中文」的選項，以及時間的選項可以選，另外也沒有奇怪的界面效果...
我在 Google Chrome 裡是在這邊設定阻擋 www.google.com，如果你搜尋是用 .com.tw 網域的話則是設 www.google.com.tw：
然後搜尋選項加上 gbv=1，這樣不會有重導：
不過這樣做的缺點是沒辦法使用 Google Maps，這個部份可以安裝「Simple JavaScript Toggle」，套件可以臨時打開 tab 這個網域的 JavaScript。
以 Google Chrome 的情況分析各種 script 的利弊與使用時機
在「Script Scheduling in Chrome」這邊看到關於各種 <script> 的時機，主要是以 Google Chrome 環境為主。作者在文章裡面有提到「Scheduling Scripts Intuitively and Performantly」這份文件，並且將最上面的表格取出來，光是這張表就給了不少想法：
文件裡面有更多細節可以看，而且有些討論其實是在思考要怎麼修改 spec 讓網站更容易設 script priority...
Google Chrome 67 將可以在 DevTools 裡看到 SCT 的內容
在 Twitter 上看到 Google Chrome 67 (下一個版本) 的 DevTools 將會顯示憑證上的 Certificate Transparency 資訊：
In Chrome 67 the Security panel now provides certificate transparency info.https://t.co/JfV4IOrsmW pic.twitter.com/EbArEUv4MI
— Chrome DevTools (@ChromeDevTools) April 18, 2018
現在要看這個資訊比較麻煩，之後可以在瀏覽器裡直接讀就會簡單一些了...
話說回來，Let's Encrypt 上個月也支援 SCT 了：「Engineering deep dive: Encoding of SCTs in certificates」，不過目前只能先用 command line 工具看... 我拉了 Let's Encrypt 官方網站的 certificate 可以看到 (Let's Encrypt 那篇文章裡的範例)，但我自己 blog 的 certificate (序號 04ef0022ed7d5417f1ccbc011acf7fea9830) 看起來是在 Let's Encrypt 支援 SCT 之前申請的，沒看到 SCT 資訊... 要等下一次的 renew 了。
Cloudflare 的 CT Dashboard
Cloudflare 發表了他們的 CT (Certificate Transparency) Dashboard：「Introducing Certificate Transparency and Nimbus」。前面的篇幅解釋 CT 是什麼，以及為什麼要存在，另外也大略解釋了一下 Google 要求要帶有 SCT (signed certificate timestamp) 的新規定 (基於 Browser 方，也就是 Google Chrome 的立場)。
再來就是講 Cloudflare 推出的 Dashboard，也就是 Merkle Town。這個網站提供了網頁操作界面，讓大家可以了解現在 certificate 的情況。
點了 Current 後，可以看到 Let's Encrypt 的比率相當高，但 Comodo 的量不算差 (以收費的情況來說)，再來是 DigiCert。
話說回來，當所有的 SSL certificate 都需要 SCT 後，相當於一般人就能夠很精確的統計市占率了，商業的憑證公司應該不是很開心... (當初 EV 也有類似的問題，不過現在 DV 已經被 Let's Encrypt 打趴了...)
本來 Google Chrome 要繞過 HSTS 的 badidea 被換掉了...
先前在「在 Google Chrome 連上因 HSTS 而無法連線的網站」中提到的關鍵字 badidea 在 Google Chrome 65 發現沒用了，找了一下發現是被換掉了：「Chrome 65 replaces the "badidea" bypass keyword with "thisisunsafe"」，這 Reddit 的標題就說明了換成什麼了 XDDD
而且從 source code 裡面可以看到，本來是明碼的 badidea，改用 window.atob 來存了：「Diff - d8fc089b62cd4f8d907acff6fb3f5ff58f168697^! - chromium/src - Git at Google」。
anyway，要記其他的字串了 XDDD
Windows 上的 Chrome 改用 Clang 編譯
這應該是上個禮拜蠻熱鬧的一件事情 (i.e. 很多人看熱鬧 XD)，就是 Google Chrome 從 Visual C++ 改成用 Clang 編譯：「Clang is now used to build Chrome for Windows」。
文章裡推敲效能應該不是主要的因素，因為在不同項目測試下各有千秋，而且差距都不大：
We conducted extensive A/B testing of performance. Performance telemetry numbers are about the same for MSVC-built and clang-built Chrome – some metrics get better, some get worse, but all of them are within 5% of each other.
後面有猜測換過去的原因，可以看出因為 open source 加上 Google Chrome 團隊有強大的技術能力下，用 open source 軟體可以對 compiler 大量客製化各種功能，另外也是因為一個 compiler 就可以吃多個平台，可以省下一些跨平台的力氣 (像是相容性語法)。
而 Visual C++ 在商業支援與文件兩方面比較好的優勢，在這個情況下就顯得不是那麼重要了...
Google Chrome 68 將會把 HTTP 網站無條件標為不安全
預定今年七月推出的 Google Chrome 68 將會無條件將 HTTP 網站標為不安全：「A secure web is here to stay」。
不過 Google 自己好像還沒把 googleblog.com 強制轉到 HTTPS 並且上 HSTS...
Firefox 對 HTTPS 網站中 "Referer" 的保護
Firefox 從 59 之後，在開啟 Private Browsing 的情況下，不會送出完整的 Referer：「Preventing data leaks by stripping path information in HTTP Referrers」。
這篇吸引到我的是 EFF 的研究員發現的事情：
EFF researchers discovered this leak of personal health data from healthcare.gov to DoubleClick.
其中 EFF 研究員的文章是「HealthCare.gov Sends Personal Data to Dozens of Tracking Websites」這篇。
更好的作法應該是平常就完全阻擋，像是 Firefox 可以用 Referrer Control 設定，或是 Chrome 裡用 Referer Control 設定。
V8 version 6.5 (Chrome 65) 的改變
V8 version 6.5 將會有不少改變：「V8 release v6.5」。
其中因為 Spectre 的關係，新的 V8 設計了 Untrusted code mode，拿來跑不信任的程式，裡面會設計反制措施。而且這在新版的 Chrome 將會預設開啟：
In response to the latest speculative side-channel attack called Spectre, V8 introduced an untrusted code mode. If you embed V8, consider leveraging this mode in case your application processes user-generated, not-trustworthy code. Please note that the mode is enabled by default, including in Chrome.
另外是針對 WebAssembly 提供邊下載邊 compile 的能力，這讓速度大幅提昇。在原文是拿一個比較大包的 WebAssembly 來測試：
For the graph below we measure the time it takes to download and compile a WebAssembly module with 67 MB and about 190,000 functions. We do the measurements with 25 Mbit/sec, 50 Mbit/sec, and 100 Mbit/sec download speed.
可以看到網路不夠快的使用者就會直接被 compile 速度跟上，讓瀏覽器在下載時就做一些事情。
另外在某些情況下對 Array 的操作會有大幅改善：
這些新功能與改善都會在 Chrome 65 推出。依照「Chrome Platform Status」這邊的資料，stable 版預定在三月初，beta 版應該是要出了... (雖然上面寫著 2/1，但目前好像還沒更新)