uBlock Origin 的開發版 (Dev) 被 Chrome Web Store 拒絕的事件...

uBlock Origin 是一個在瀏覽器上擋廣告的軟體,以前在推廣的時候都只提到可以過濾掉網站上的廣告,大家興趣其實都不太高 (還會有「留口飯讓別人吃」之類的 XDDD),但最近跟同事推廣的時候改用「可以擋 YouTube 的影音廣告喔」,大家接受度意外的爆高,不過這有點扯遠了,回到原來的主題上...

先介紹一下 uBlock Origin 的開發模式,除了一般的 stable 版本外 (「uBlock Origin」這組),另外會有另外一個 dev 版本上傳到 Chrome Web Store (CWS) 上 (「uBlock Origin development build」這組),這樣讓使用者比較容易安裝與測試,這個方式也可以在 Tampermonkey 上看到。

這次主要維護者 Raymond Hill (gorhill) 在 1.22.5rc1 版上傳到 CWS 上後收到被拒絕上架的通知:「Dev build 1.22.5rc1 "REJECTED" from Chrome Web Store」。

拒絕的原因是 CWS 要求要有套件必須符合「目的單一性」,也就是不能把目的不同的東西強迫使用者綁在一起使用:

Your item did not comply with the following section of our policy: An extension should have a single purpose that is clear to users. Do not create an extension that requires users to accept bundles of unrelated functionality, such as an email notifier and a news headline aggregator. If two pieces of functionality are clearly separate, they should be put into two different extensions, and users should have the ability to install and uninstall them separately. For example, an extension that provides a broad array of functionalities on the New Tab Page/ Start-up Page but also changes the default search are better delivered as separate extensions, so that users can select the services they want. For more information on the new Chrome extensions quality policy, please refer to the FAQ: https://developer.chrome.com/extensions/single_purpose

後續的 1.22.5rc2 也被拒絕,然後他回信詢問了 CWS 官方,得到的仍然是罐頭回應,然後他就決定丟著 (而這個作法還蠻聰明的),接著這件事情就被丟著變成 PR 事件上了一些媒體,然後昨天就突然解了...

Google 最近的動作愈來愈多了,一方面在嘗試避免觸動反托拉斯法的情況,儘可能打壓這些擋廣告的套件...

Safari 上 uBlock Origin 的情況

uBlock Origin 在 2016 的時候 porting 到 Safari 上,但在 2018 後就沒有再更新了,維護者在「Explanation of the state of uBlock Origin (and other blockers) for Safari #158」這邊說明了目前的情況。

主要就是蘋果要廢掉本來的 Extension API,而替代的框架裡沒有對應的 content filtering 能力,所以在新的框架內無法實做 uBlock Origin 的功能...

維護者的建議是換瀏覽器,但其實可以選擇的瀏覽器愈來愈少了 (因為 Google Chrome 這邊也在搞),所以維護者的建議就是換成 Firefox

另外我自己會建議用看看 Brave,因為 Brave 已經決定,如果 Google Chrome 修改 webRequest 的阻擋能力 (也就是這次的 Manifest V3),他們會繼續維持本來的相容性,所以可以預期 uBlock Origin 應該還是會動 (參考之前寫的「Brave 試用」這篇)。

回來用 uBlock Origin 擋 Facebook 廣告...

基本上現在是哪個有用就用哪個... @_@

先前提到的「擋 Facebook 廣告的 Userscript」這個又不會動啦... 所以又到處找方法,目前看起來在 uBlock Origin 的「Facebook · Issue #3367 · uBlockOrigin/uAssets」這邊有一直在討論新的擋法,之後如果又看到廣告就過來這邊看一下...

目前用這組:

www.facebook.com##div[id^=hyperfeed_story_id_]:has(span[data-ft="{\"tn\":\"j\"}"])
www.facebook.com##.pagelet-group .pagelet:has(a:has-text(Sponsored))
www.facebook.com##.pagelet-group .pagelet:has(a:has-text(Create ad))

不知道可以活多久...

CloudFront 十週年、在東京的第十個 PoP,以及支援 WebSocket 與 Origin Failover

CloudFront 宣佈十年了,另外這次在東京又加節點了,變成 10 個:「Celebrating the 10 year anniversary of Amazon CloudFront by launching six new Edge locations」。

另外宣佈支援 WebSocket:「Amazon CloudFront announces support for the WebSocket protocol」,以及支援 Origin Failover:「Amazon CloudFront announces support for Origin Failover」。

WebSocket 算是大家等蠻久的功能,大家主要是希望利用 CloudFront 擋 DDoS,正常流量才往後丟。而 Origin Failover 則是可以設定兩個 Origin,當主要的掛掉時可以切到備用的,對於支援多節點的架構算是第一步 (目前看起來只能設兩個):

With CloudFront’s Origin Failover capability, you can setup two origins for your distributions - primary and secondary, such that your content is served from your secondary origin if CloudFront detects that your primary origin is unavailable.

都是隔壁棚 Cloudflare 支援許久的功能... 算是補產品線與進度?

擋 mobile.twitter.com 上的廣告

在桌機上面用 mobile.twitter.com 速度比 twitter.com 快很多,所以平常用桌機時都是用 mobile 這個版本在逛,但因為 mobile 版本對 css name 有處理過,使得 uBlock Origin 這類軟體不好處理廣告的部份...

前陣子在日本的時候發現頁面上多了一堆廣告,本來以為是在日本用日本 IP address 才會有所以就沒有太在意,結果回台灣後發現也出現了... 看起來是 css name 又因為改版被改掉而使得原本的規則失效了...

網路上找其他方法看看有沒有方向,結果找到「Block "Promoted Tweets" on mobile.twitter.com · Issue #351 · uBlockOrigin/uAssets」這篇,雖然最後的 commit 還是用 css name 的方式,但在留言處 Jud 提到可以用 Procedural cosmetic filters 中的 XPath 解決:

mobile.twitter.com##:xpath(/html/body//div[@role="article"][.//text()[starts-with(., "Promoted")]])

這條規則不算難懂,先找出 <div role="article"> 的元素,然後判斷下面的節點有沒有文字化開頭後是 Promoted 的字串。

在還沒有更新規則之前,這個拿來擋一擋應該還行... 不過條件寫的有點簡單,可能會有誤判,也許改抓 div 的「Promoted by 」應該會比較好?也就是這樣:

mobile.twitter.com##:xpath(/html/body//div[@role="article"][.//div[text()[starts-with(., "Promoted by ")]]])

就先這樣搞吧...

將找 Origin Server IP 位置自動化的 CloudFlair

Twitter 上看到 CloudFlair 這個工具,可以找被 Cloudflare 保護的網站,將尋找後面 Origin Server 的 IP address 的過程自動化:

這隻程式配合 Censys 的資料去找,而不是自己獨立掃整個 IPv4 address。

另外這隻程式也不保證掃的出來,像是透過 Cloudflare 去年十一月推出的新服務 Wrap,就不需要將 Port 80/443 對 Internet 公開 (參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」)。

不過還是蠻好玩的工具啦 XDDD

Web Cache Deception Attack

在「How (Not) to Control Your CDN」這邊看到了「Web Cache Deception Attack」這個攻擊方式。

攻擊的手法是利用網站會把 /user/personal-info/foo.css/user/personal-info 視為一樣的內容時,配合 CDN 或是 reverse proxy server 會把 .css 設定無差異 cache 時,就可以在 cache server (cache edge) 取得使用者的敏感資料。

這主要是 url routing 的條件放太寬造成的。

另外 Mark Nottingham 還建議 cache 應該在 origin server 上控制,而非在 CDN 上設定。也就是說,在 origin server 上送出 Cache-Control,讓 CDN 或是 reverse proxy server 使用這個值來判斷 cache。

阻擋廣告的攻性防壁 AdNauseam

看到「AdNauseam: Fight back against advertising surveillance」這個專案瞬間想到攻殼裡面「攻性防壁」這個詞 XDDD

改自 uBlock Origin,除了本來的隱藏廣告功能外,還會狂點廣告來亂 XDDD:

AdNauseam is a lightweight browser extension that blends software tool and artware intervention to fight back against tracking by advertising networks. AdNauseam works like an ad-blocker (it is built atop uBlock-Origin) to silently simulate clicks on each blocked ad, confusing trackers as to one's real interests. At the same time, AdNauseam serves as a means of amplifying users' discontent with advertising networks that disregard privacy and facilitate bulk surveillance agendas.

CloudFront 的 Regional Edge Caches

Amazon CloudFront 前陣子宣佈了 two-tier 架構:「Announcing Regional Edge Caches for Amazon CloudFront」。

一般的 CDN 是 edge 收到後就打到 origin,這會使得 origin 的量比較大。而 two-tier 架構則是在中間疊一層降低對 origin 的量。這種架構對於直播時的 pattern 幫助很大:由於量很大,會需要用大量的 edge server 支撐,而 edge server 一多就對 origin 產生巨大的壓力。

一般直播 95% 的 hitrate 表示外面 20Gbps 的流量就會造成 origin 1Gbps 的流量,通常用 two-tier 可以拉到 98%+ (CDN vendor 有調整過可以到 99%+)。

這種技術在 Akamai 叫 Tiered Distribution,在 EdgeCast 叫 SuperPoP,而現在 CloudFront 也推出了,叫做 Regional Edge Cache:

The nine new Regional Edge Cache locations are in Northern Virginia, Oregon, São Paulo, Frankfurt, Singapore, Seoul, Tokyo, Mumbai, and Sydney.

edge 會先到這幾個 regional edge 再到 origin:

These locations sit between your origin webserver and the 68 global edge locations that serve traffic directly to your viewers.

然後預設都開啟了,沒有額外費用:

Regional Edge Caches are turned on by default for your CloudFront distributions; you do not need to make any changes to your distributions to take advantage of this feature. There are also no additional charges to use this feature.

不過這個架構對於 latency 應該不會太好,沒得關閉有點奇怪...