Home » Posts tagged "chromium"

實做 Twitter 同步到 Facebook 的程式

幾個月前 Facebook 把 API 拿掉了,大家都不能用 API 發文,本來想說就放掉這個平台,結果被老人家問怎麼都沒更新,因為老人家都是靠兒子的 Facebook 確認生存,看到沒更新就很擔心... XD

由於 API 沒得用了,所以得自己 hack。這邊先列重點:

  • chromium + VNC 登入後,用 chromium headless + selenium 發文。
  • 對於「網頁的穩定性」來說 (i.e. 常不常改版造成我的程式發文失敗),mbasic(.facebook.com) > m > www。

比較重要的方向就是這些,其他的其實就是磨時間、踩地雷,然後把程式刻出來:「gslin/twitter2facebook」。

把 Google 服務拔乾淨的 Chromium

有人試著把 Chromium 裡的 Google 相關服務都拔乾淨,叫做 ungoogled-chromium

Modifications to Google Chromium for removing Google integration and enhancing privacy, control, and transparency

有提供志願者包好的 pre-built binary,但看了一下版本有點舊,而且不能確定裡面有沒有什麼加料... 要用的人可能還是要考慮自己編一包出來。

在「Add a PPA or APT repo」這邊有人在討論要怎麼包 PPA 出來,不過看起來卡關了...

Android 打算針對 Data Saver + 2G 網路的使用者關閉 JavaScript 功能

在「Chrome for Android may start disabling JavaScript on 2G connections」這邊看到的,引用的文章是 XDA 的「Google Chrome on Android to disable JavaScript automatically on 2G connections」。

在「Disable scripts for Data Saver users on slow connections」這邊可以看到 Android 的計畫,在打開 Data Saver 的情況下,Chrome 會停用 JavaScript,並且提示使用者:

If a Data Saver user is on a 2G-speed or slower network according to the NetInfo API, Chrome disables scripts and sends an intervention header on every resource request. Users are shown a UI at the bottom of the screen indicating the page has been modified to save data. Users can enable scripts on the page by tapping “Show original” in the UI.

在「Enabled NoScript Preview feature by default on Android」這邊可以看到對應的程式修改。

這樣反而可以少收到很多廣告耶,反倒希望是全域打開 XDDD

第一次拿 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

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 是不是也要有稽核機制?

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

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

GitHub 引入 Code Owner 的概念

GitHub 推出了 Code Owner 的概念:「Introducing code owners」。也很直接說這個能是向 Chromium「致敬」出來的:

The code owners feature was inspired by Chromium's use of OWNERS files.

檔案名稱是 CODEOWNERS,可以放在根目錄或是 .github/ 下,可以針對不同的目錄設不同的人:

To specify code owners, create a file named CODEOWNERS in the repository's root directory (or in .github/ if you prefer) with the following format[.]

這樣一來,在 pull request 的時候就會跳出來:

另外也可以設定需要 code owner 同意才能 merge:

利用 Unicode Domain 釣魚,以及 Chrome 與 Firefox 的解法

一個多禮拜前引起蠻多討論的一篇文章,利用 Unicode Domain 釣魚的方法:「Phishing with Unicode Domains」。

由於這是幾乎完美的攻擊,所以被提出來後 (Security: Whole-script confusable domain label spoofing) 有不少討論:

This bug was reported to Chrome and Firefox on January 20, 2017 and was fixed in the Chrome trunk on March 24. The fix is included in Chrome 58 which is currently rolling out to users.

comment 8 提到:

We do have a whitelist. Essentially you're suggesting that we remove Cyrillic and Greek characters from the list. I'm not sure we want to go down that path.

在新版的 Chrome 58 已經「修正」了這個問題:

Firefox 的討論在「IDN Phishing using whole-script confusables on Windows and Linux」這邊,一開始就直接把票給關了 XDDD:

Indeed. Our IDN threat model specifically excludes whole-script homographs, because they can't be detected programmatically and our "TLD whitelist" approach didn't scale in the face of a large number of new TLDs. If you are buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the responsibility of domain owners to check for whole-script homographs and register them.

We can't go blacklisting standard Cyrillic letters.

If you think there is a problem here, complain to the .com registry who let you register https://www.xn--80ak6aa92e.com/ .

Gerv

Status: NEW → RESOLVED
Last Resolved: 3 months ago
Flags: needinfo?(gerv)
Resolution: --- → WONTFIX

然後一個月前被提出來看看 Chrome 怎麼做:

Gerv/Valentin, is this something we can/should align with Chromium on?

目前唯一的解法是改 flag,把所有的 Unicode Domain 直接當作一般的 domain 來處理,列出像是 www.xn--80ak6aa92e.com 的網址。

Google Chrome 的 Headless 模式與 PhantomJS 的歷史

瀏覽器的 headless 模式讓開發者可以透過 command line 或是 API 界面操作,對於自動化開發測試很有用。而 Google Chrome 將在 59 版 (目前 57 版) 引入 headless 模式:「Headless mode」。

Headless mode allows running Chromium in a headless/server environment. Expected use cases include loading web pages, extracting metadata (e.g., the DOM) and generating bitmaps from page contents -- using all the modern web platform features provided by Chromium and Blink.

To use headless, start Chrome with a command line flag:

$ chrome --headless --remote-debugging-port=9222 https://chromium.org

PhantomJS 則是因為 Google Chrome 決定要支援 headless 模式,主要的貢獻者 Vitaly Slobodin (參考 Contributors to ariya/phantomjs 這邊) 決定退出維護:「[Announcement] Stepping down as maintainer」。

是個功成身退的感覺...

Google Chrome 停用平滑捲動

因為把 JavaScript 開回來了,所以有這個困擾... :(

Google Chrome 的平滑捲動可以透過 chrome://flags 裡面的設定關閉 (OS X 上則是透過系統設定關閉),但就是有不少網站會很雞婆,用 JavaScript 模擬平滑捲動,所以就花了時間把 extension 寫出來:「Stop Smooth Scrolling」。

由於大多數平滑捲動的作法都是透過對 document 或是 window 上掛上與平滑捲動相關事件做到的,所以我是透過 addEventListener()useCapture flags,然後再用 preventDefault() 擋下後續的處理。

這樣做會有一些問題,其中比較明顯的是地圖類功能的滾輪會失效,這個部分我先放進預設的白名單了,如果有其他的問題,除了可以自己加以外,也可以開 ticket 讓我加進預設清單 :o

實際運作起來大概是這樣:

Anyway,寫這個還蠻有趣的,玩了不少新東西:

Archives