擋 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 ")]]])

就先這樣搞吧...

為什麼我還繼續用 RSS (Feed)

最近在一些地方冒出兩篇文章 (應該是 NuzzelHacker News,放在 tab 上好幾天,不是那麼確定來源...),一篇是最近發的「The Case for RSS」,另外一篇是五月的文章「RSS: there's nothing better」。這邊講的 RSS 比較廣義,不侷限於 RSS {0.91,1.0,2.0},而是包括了各式的 feed,像是後來標準化的 Atom

消息的來源大致分成兩種:

  • 已知的來源:這些人只要有新的文章你就會想看。
  • 未知的來源:你可能也會有興趣的文章。

前者你不會想要漏掉 (你就是想看才會訂啊)。而後者在早期有 Zite 這類用演算法推薦的產品,後來在 Zite 併入 Flipboard 整個爛掉後我就跳去用 Nuzzel (透過好友機制推薦,演算法相對單純)。

Facebook 將這兩者混在一起,讓「已知的來源」未必會出現,而是用演算法包起來並且用 PR 手段混淆:美其名稱為「個人化推薦」,實際上是想辦法讓內容提供者掏錢出來。這點在 Instagram 上也可以看到一樣的作法:把 timeline 打散,用演算法包裝起來,再美其名為「個人化推薦」。

而 RSS reader 可以避免「已知的來源」這塊漏掉。

另外也因為 RSS reader 因為設計的目標就是「有效率的閱讀」而不是「賺錢」,所以大多數都會有「已讀」與「未讀」的功能,這讓你同樣的資訊你不需要讀很多次。

而 RSS reader 容易分群閱讀 (有些 RSS reader 會提供 folder 或是 tag 的功能) 也讓你可以帶著不同的 mindset 看不同群的文章,像是科技類的文章與心靈雞湯文就可以分開。

AWS 裡 Security Group 的條件可以寫註解了...

AWS 裡 Security Group 的條件可以寫註解了:「New – Descriptions for Security Group Rules」。

這讓其他人比較好理解 (尤其不是常見的 port,或是有些特別的 IP address),另外也讓容易失憶的自己知道當初在幹什麼 XDDD

在 Git/Mercurial/Subversion 上 "-" 發生的問題

在「[ANNOUNCE] Git v2.14.1, v2.13.5, and others」這邊看到 - 開頭產生的問題:

These contain a security fix for CVE-2017-1000117, and are released in coordination with Subversion and Mercurial that share a similar issue. CVE-2017-9800 and CVE-2017-1000116 are assigned to these systems, respectively, for issues similar to it that are now addressed in their part of this coordinated release.

這算是老問題了,Git 對應的修正主要是朝 filter input 的方向修正,包括了禁用 - 開頭的 hostname,以及禁止 GIT_PROXY_COMMAND- 開頭,另外是禁止開頭是 - 的 repository name:

  • A "ssh://..." URL can result in a "ssh" command line with a hostname that begins with a dash "-", which would cause the "ssh" command to instead (mis)treat it as an option. This is now prevented by forbidding such a hostname (which should not impact any real-world usage).
  • Similarly, when GIT_PROXY_COMMAND is configured, the command is run with host and port that are parsed out from "ssh://..." URL; a poorly written GIT_PROXY_COMMAND could be tricked into treating a string that begins with a dash "-" as an option. This is now prevented by forbidding such a hostname and port number (again, which should not impact any real-world usage).
  • In the same spirit, a repository name that begins with a dash "-" is also forbidden now.

然後中華電信的 DNS server (168.95.1.1 & 168.95.192.1) 都查不到 marc.info,改用 Google 的 8.8.8.8 才查得到... =_=

Quotient filter

之前有提過「Cuckoo Filter:比 Bloom Filter 多了 Delete」,最近在「A general purpose counting filter: making every bit count」這邊看到 Quotient filter,也是類似 Bloom filter 的資料結構,但想要解決更多問題。

一般的 Bloom filter (BF) 會有這些問題:

  • The inability to delete items
  • Poor scaling out of RAM
  • The inability to resize dynamically
  • The inability to count the number of occurrences of each item, especially with skewed input distributions.

而文章裡提到的 Quotient filter (QF) 就是要解這些問題。另外還提到了 Rank-and-Select-based Quotient filter (RSQF) 以及 Counting Quotient filter (CQF)。雖然多了一些空間需求,但看起來解掉不少問題... (尤其是刪除的能力)

效能上也還不錯,尤其是讀取速度的部份... 不過不知道相對於 Cuckoo filter 差多少。

Cuckoo Filter:比 Bloom Filter 多了 Delete

在「Cuckoo Filter implementation in Go, better than Bloom Filters」這邊看到這個資料結構,有興趣的人也可以看「Cuckoo Filter:设计与实现」這篇介紹,下面是我抓重點整理。

Bloom Filter 支援的操作:

  • Add(element)
  • Query(element)

1970 年提出來的資料結構。優點是空間複雜度是 O(1),Query(element) 會有可接受的 false positive,缺點是不支援 Delete(element)、以及數量變多時誤判率的增加。

Cuckoo Filter 多了一組操作:

  • Delete(element)

2014 年提出來的資料結構。空間複雜度一樣是 O(1),但相同的空間用量下 false positive 變低,然後支援 Delete(element) 了。也因此論文直接寫「Cuckoo Filter: Practically Better Than Bloom」,表示可以直接替代。

Google Chrome Developer Tools 裡的 Network Filter

在「Chrome Network Panel Filter: Domain」這篇看到有趣的用法:

輸入完 domain: 後會列出許多選擇讓你選,還包括了 wildcard... 這功能真不錯 @_@

WhatsApp 過濾關於出現「Telegram」的連結

WhatsApp (2014 年被 Facebook 買下) 過濾 Telegram 連結的消息在國外引發討論了:「As of today, WhatsApp is blocking Telegram links」。這讓維基百科裡「WhatsApp」這段說明看起來特別的奇特:

WhatsApp宗旨是給予人們一個不被竊聽的溝通橋樑,並從不存取用戶個人資料,像是姓名、性別、年齡或者聊天紀錄,這和烏克蘭裔的創辦人庫姆在有秘密警察的共產國家成長有關,他孩童時期的經歷讓他懂得通訊沒有被監聽的珍貴。

作者在 app 上測了幾個連結:

Whatsapp-blocks-Telegram-copy-yes

這張圖可以看出來 telegram.org 的連結無法點擊。弄了老半天後,發現程式直接針對 Telegram 相關的網域擋掉了:

nexus2cee_Screen-Shot-2015-12-01-at-10.11.09-2

拉張板凳來看看後續會變成什麼樣子...

PHP 5.5 的 Generators

在「Save memory by switching to generators」這邊提到了 PHP 5.5 開始提供的 Generators...

由於其他的程式語言有 Generators 的觀念,其實不會太難了解...

不過比較大的問題是,資料庫的查詢操作用 Generators 會把效能壓力壓回資料庫:因為資料庫需要把結果 buffering 在資料庫端,如果不趕快吐出去就是要找記憶體放... 也因此,比較常見到的解法是不要用 Generators。(因為 web 與 application 端相較於資料庫端,比較容易 scale)

後來用 Generators 比較多的印象中還是 filter 類的應用吧,Python 這邊的東西有陣子沒看了 :o