Google Chrome 會 bypass Adblock 的問題

新版的 Google Chrome 使得 YouTube 可以繞過 Adblock 類軟體的阻擋限制 (像是 uBlock Origin),導致這些使用者會需要「看完完整的廣告影片 (無法 skip)」才能看本篇:「Google Chrome reportedly bypassing Adblock, forces users to watch full-length video ads」。

目前確認這是在修正 CVE-2015-1297 時產生的 bug:

Update: We have been contacted by Rob Wu, a developer on the Chromium project - the open-source foundation for the Chrome browser - who has informed us that this change was not intentional but, rather, an unintended result of fixing a previous security issue (CVE-2015-1297). He confirmed that the issue will only be seen if the YouTube app is installed and that, at the moment, apart from disabling AdBlock or whitelisting YouTube, the only solution, as described above, is to uninstall the app. The problem is expected to be patched in the upcoming weeks or, at least, when Chrome 46 is released.

目前的暫時解法是移除掉 YouTube 這隻 app,或是將 YouTube 放到白名單網站。

為了解決 HiNet 到 CloudFlare 機房品質不好而做的掙扎...

前幾天在「TVBS 的 CloudFlare 客製化...」這邊提到這件事情,當天就先隨手測了一些東西。

首先是 CloudFlare 的服務 IP 是互通的,也就是說,我就算拿其他人的 CNAME mapping 來用,只要有送出對應的 Host: 或是 SNI (for HTTPS) 就會通,而 TVBS 當時的 IP address (以及網段) 對於台灣 HiNet 使用者剛好會導到美國機房,還算可以用。

另外 CloudFlare 有提供列表 (文字格式,一行一個網段),分別是 IPv4 的 https://www.cloudflare.com/ips-v4 以及 IPv6 的 https://www.cloudflare.com/ips-v6

所以就有幾種組合了,一種是寫 Google Chrome 的 extension 直接改 IP address,不過看了看 JavaScript APIs - Google Chrome 想不出來怎麼寫。

另外一個是先用 iptables 把這些網段的流量導去美國的 CloudFlare 機房。結果這時候發現 HiNet 到 TVBS 已經改回到香港機房了 orz

實際抓了一下發現 188.114.97.100 在巴西機房 (GRU 是 IATA 代碼),就變成只是測試看看這有沒有用了:

$ curl -x http://188.114.97.100:80/ http://s.plurk.com/cdn-cgi/trace
fl=42f16
h=s.plurk.com
ip=114.32.152.63
ts=1441004146.723
visit_scheme=http
uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
colo=GRU
spdy=off

由於是自己機器出去的封包,不能用 PREROUTING 做,要用 OUTPUT 做:

iptables -t nat -A OUTPUT -d 190.93.240.0/20 -j DNAT --to-destination 188.114.97.100

然後再直接連到 s.plurk.com 就可以看到:

$ curl http://s.plurk.com/cdn-cgi/trace
fl=42f16
h=s.plurk.com
ip=114.32.152.63
ts=1441004011.195
visit_scheme=http
uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
colo=GRU
spdy=off

不過巴西也太遠了點,而且不知道哪天這段 IP 又會被 anycast 進去... orz

Google Chrome 與 Firefox 上擋廣告軟體的效能比較

在「10 Ad Blocking Extensions Tested for Best Performance」這篇看到各個 Ad Blocker 軟體的比較。

對各網站測試了載入速度、記憶體使用量、CPU 使用率,重點應該是最後的圖:

其中最知名的 AdBlock Plus (ABP) 會最慢的原因也很簡單,因為他預設值會放行廣告,這導致了效能掉很多:

If you’re wondering why the popular AdBlock Plus got low scores in some Chrome tests, the answer is simple and it’s purely down to the acceptable ads check box. Disable “Allow some non-intrusive advertising” and AdBlock Plus will performance wise, sit in the middle of the pack.

在 ABP 把 acceptable ads 擋掉後速度就比較接近了。不過,如果你願意接受 acceptable ads,也不應該選擇 ABP,因為其他也有支援 acceptable ads 的軟體效能比較好:

Whatever your opinion on acceptable ads, using the option in ABP is not recommended and if you wish to support showing specific ads while browsing, use something else. AdBlock, Adguard, AdRemover and SuperBlock all have an acceptable ads option of some sort, but none suffer a performance drop like ABP.

最後的結論,不論是 Google Chrome 或是 Firefox,贏家都是 uBlock Origin

The overall winner in Firefox is simply the quickest, and that was µBlock origin. µ AdBlock is a fair choice if you want an easy to use but fast blocker, the rest are almost identical so it’s down to personal preference and the options available as to which one you use.

The winner in Chrome is a closer call when you consider the results from all three tests. But as it got a couple of firsts and a second, we would say µBlock Origin is the definite winner, it truly is fast and efficient as the author claims. Both Ghostery and Adguard are still excellent choices and are viable alternatives to µBlock Origin providing good performance in all 3 categories.

Ghostery 雖然也會因為少讀很多東西進來而加快速度,不過拿來一起比好像怪怪的...

網路廣告愈來愈誇張,阻擋的功能變成趨勢了,在桌機上支援的軟體愈來愈完善,而在行動裝置上,iOS 9 也開始支援了:「Content blocking in iOS 9 is going to screw up way more than just ads」。

uBlock₀ 提供阻擋 WebRTC 取得 Local IP address 的功能

Google Chrome 上之前是透過 WebRTC Block 之類的軟體阻擋網站透過 WebRTC 取得 Local IP address 的功能,現在則內建在 uBlock₀ 內了。

在「You can block WebRTC from leaking your IP now in uBlock Origin」這邊看起來是這個月月初 (2015 年 7 月) 開發出來的功能。

WebRTC Leaktest 交叉測試可以發現 Public IP address 的部份,目前測過的套件都擋不下來,但 Private IP address 的部份都有順利擋下來。

又可以少裝一個套件了...

更新 Twitter Expand Preview Image 樣式...

在「預設展開 Twitter 圖片的 Userstyle」這邊利用 CSS 效果展開圖片,這次更新把多張圖片的縮圖也展開了:「Twitter Expand Preview Image」。

連帶的,本來有裝「Photo Zoom for Twitter」就順便移除了...

這次學到 unset 這個屬性:「unset - CSS | MDN」,現在 Google Chrome 也才 43,也就是在 Google Chrome 上是兩個版本前的 41 才支援的...

預設展開 Twitter 圖片的 Userstyle

Twitter 上遇到比較大張的圖片要自己展開,之前在 Google Chrome 上面是用 Previeweet 解決,但這個套件已經年久失修...

研究了 Twitter 的 CSS 結構,看起來可以用 Stylish 處理掉,就寫了一個 style 上傳上去:「Twitter Expand Preview Image」。

這樣看圖片方便多了...

Yuren Ju 的 ptt redirect:從轉載網站自動轉回 Ptt 原文

Twitter 上看到的 Google Chrome Extension 專案,針對轉載自 Ptt 的網站自動轉回 Ptt 原文:

程式在「ptt redirect」這邊,而原始程式碼在 GitHub 的「yurenju/ptt-redirect」這邊。

目前只支援 disp.cc,應該還有好幾個站可以支援...

在 PC 的 Google Chrome 裡跑 Android 應用程式

OSNews 上看到可以在桌機上用 Google ChromeAndroid 應用程式:「Run Android apps on a PC with Google Chrome」,引用的報導是「You can now run Android apps on a Mac or PC with Google Chrome」這篇。

參考「Getting Started with ARC」這篇文章,裝「ARC Welder」這個...

看起來 Linux 也能跑,有空來測試看看... O_O

Google 的 QUIC 擴大實驗

QUIC (Quick UDP Internet Connections) 是 Google 發明的協定,主要是希望改善 TCP + TLS 的反應速度,目前是用來加速 Google Chrome 與 Google server 之間的連線。

與 SPDY 或 HTTP/2 不同的地方在於使用了 UDP,這降低了 TCP packet loss 造成的壅塞現象,以及 TCP 3-way handshake 的成本,而這兩點在行動平台上都特別明顯。

依照最新的說法,目前 Google Chrome 連到 Google server 大約有一半的連線會走 QUIC:「A QUIC update on Google’s experimental transport」。

Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic, eventually making it the default transport from Google clients — both Chrome and mobile apps — to Google servers.

而在 YouTube 的改善也很大:

These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC. This means less time spent staring at the spinner and more time watching videos.

由於效果不錯,他們打算要換更多...

uBlock 的改版:交接後再 fork 成 uBlock Origin (uBlock₀)

原先的 µBlock 改名成 uBlock₀,並且把 uBlock 的名字交出去給了 Colorado SpringsuBlock

原因可以在「Please clarify uBlock₀ vs. uBlock」這邊看到,由於這不是 full time job (他也不想要成為 full time job),所以他決定 freeze 目前的功能,僅維持 bugfix (因為對他來說夠用了,他自己平常也在用)。

依照這個原因,我的感覺是 uBlock 會成圍下一個肥大的 ABP,就乖乖留守 uBlock Origin (uBlock₀) 吧。