Home » Posts tagged "chrome"

Stylish 的隱私問題

找了一下應該是舊聞了 (參考 2017 年年初,在 Ptt 上的「[-GC-] 新版 Stylish 開始蒐集使用者資訊」這篇),最近因為「"Stylish" browser extension steals all your internet history」這篇又被拿出來講。

目前的替代方案主要應該是 Stylus,在 ChromeFirefox 都有套件可以裝:Stylus (Chrome)、Stylus (Firefox)。

剛剛看了一下,Firefox 與 Chrome 的 extension 都已經被下架了,而且 Firefox 這邊直接設為黑名單:「Blocklist Stylish add-on - sends full page urls to remote server」。

第一次拿 Headless Chrome (Chromium) 出來玩...

前陣子發現 PChome 24h 的輕小說 Atom feed 掛掉了 (在 gslin/pchome24h-feed 這邊),看了一下頁面發現換 url 了,而且從 BIG5 變成 UTF-8 (賀!!!),但變成大量的 js call 產生資料產生頁面 (還不是 ajax 的 JSON),而且有一堆奇怪的 magic number 在裡面 (感覺會因為改版就產生變化 XD),就懶得再自己組出來了,決定玩看看 Headless Chrome 練個功...

Chrome 從 2017 年七月的 59 版就推出了 Headless 功能 (stable channel 的時間),也因此在去年四月的時候 PhantomJS 就決定停止維護下去:「Google Chrome 的 Headless 模式與 PhantomJS 的歷史」。

官方的文件「Getting Started with Headless Chrome」寫的很完整,而且也可以看到 Headless Chrome 把常見的功能都先實做完了。在不另外裝軟體的情況下就可以做很多事情。像是直接把生成好的 DOM 轉成 HTML 丟出來:

chrome --headless --disable-gpu --dump-dom https://www.chromestatus.com/

或是把頁面輸出成 PDF,或是輸出成圖片 (screenshot.png):

chrome --headless --disable-gpu --print-to-pdf https://www.chromestatus.com/
chrome --headless --disable-gpu --screenshot https://www.chromestatus.com/

也可以直接開 js console 出來互動:

$ chrome --headless --disable-gpu --repl --crash-dumps-dir=./tmp https://www.chromestatus.com/
[0608/112805.245285:INFO:headless_shell.cc(278)] Type a Javascript expression to evaluate or "quit" to exit.
>>> location.href
{"result":{"type":"string","value":"https://www.chromestatus.com/features"}}
>>> quit
$

在文件後面也提供了大量範例,教你怎麼用 Selenium + WebDriver + ChromeDriver 操作,順著用裡面的範例找一下 Python 會怎麼寫就寫好了... 之後也機會來測試 Firefox 好了 :o

讓 Chrome 開新 Tab 時不要出現搜尋頁

Google Chrome 的新 tab 現在預設都會出現 search engine 頁面 (即使你設為 about:blank),但我從來就沒有在這頁搜尋過東西 (都是直接在 location bar 輸入),所以想要拿掉這個「功能」。

找到由 thakis@chromium.org 提供的 extension,而且是在 2013 年就發佈了:「Empty New Tab Page」,他給的截圖意思就很清楚了:

看了一下 source code 也的確是乾乾淨淨的,先裝這個...

關閉 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 資訊:

現在要看這個資訊比較麻煩,之後可以在瀏覽器裡直接讀就會簡單一些了...

話說回來,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 而無法連線的網站」中提到的關鍵字 badideaGoogle 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 ChromeVisual 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++ 在商業支援與文件兩方面比較好的優勢,在這個情況下就顯得不是那麼重要了...

Archives