Google Chrome 上有大量 Extension 在追蹤個人行為

在「Chrome Extensions – AKA Total Absence of Privacy」這邊討論了 Google Chrome 官方的 Web Store 上有很多應用程式為了賺錢在追蹤個人行為:

We’ve seen some indications on Chrome Extension-forums that it’s around $0.04 per user/month.

而且因為是 extension,可以直接穿越 Ghostery 之類的防護網,於是就變得無法 opt-out。你可以利用「In order to continuously improve and maintain this software we work with」這樣的字串去找,會以發現有不少 extension 用了 Fairshare 的方案來賺錢。

文章作者呼籲 Google 要提出方案來制止這類行為,不過我覺得 Google 應該是不會做...

用 jQuery Audit 在 Google Chrome 的 Developer Tools 看到 jQuery 的資料

在「jQuery Audit lets you analyze jQuery from Chrome Developer Tools」這邊看到 jQuery Audit 這個 Google Chrome 的套件。這個套件讓你在 Developer Tools 裡看到 jQuery 的資料:

在大家都用 jQuery 操作的情境下,這個套件超好用...

Google Chrome 上面的畫面截圖套件

記得之前有提到最多人裝的那幾個 extension 都有嵌入各種 malware 或 spyware,所以試著找有哪個是正常的... 後來想到用 GoogleGitHub 上的 open source 專案,找到這個:「One-click full page screen captures in Google Chrome」,官方說明頁面在「Full Page Screen Capture Chrome Extension」:

It’s open source (on github) and malware free.

看起來這個應該是可以用的... 看起來很久沒更新了,不過實際測試還是會動的 :p

把 Google Chrome 的套件移植到 Firefox 上

在「Porting Chrome Extensions to Firefox with WebExtensions」這邊提到了 WebExtensions 計畫:

The technology is designed for cross-browser compatibility: to a large extent the API is compatible with the extension API supported by Google Chrome and Opera. Extensions written for these browsers will in most cases run in Firefox with just a few changes. The API is also fully compatible with multiprocess Firefox.

提供另外一種方式開發,吸引 Google Chrome 現有的 extension 開發者,也就是利用現有的 ecosystem 來幫助自己,把本來需要整個重寫的工作降低...

為了解決 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

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 的部份都有順利擋下來。

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

RFC7469:Public Key Pinning Extension for HTTP

前幾天的 Standards Track:「Public Key Pinning Extension for HTTP」。

HPKP (HTTP Public Key Pinning) 機制是讓 server 端在第一次連線時告訴 client (像是瀏覽器) Public Key 資訊,也就是建構在 TOFU (Trust-on-first-use):

Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)

機制上很像 HSTS (HTTP Strict Transport Security,RFC6797)。依據 Mozilla 的「Public Key Pinning」資料,目前新版的 Google ChromeFirefox 都有支援了。

用鍵盤翻頁 (Navigation Shortcuts)

Google Chrome 上裝了「Navigation Shortcuts」:

快速鍵包含這些:

  • Space Bar - navigates to the next page when scrolled to the bottom
  • Shift + Space Bar - navigates to the previous page when scrolled to the top
  • Ctrl + Right - navigates to the next page
  • Ctrl + Left - navigates to the previous page
  • Ctrl + Up - navigates to section's index page
  • Ctrl + Shift + Up - navigates to the top page

其實讀的就是 HTML header 裡面的 rel tag。拿來讀 AWS 的文件還蠻方便的...

用 Require-Recipient-Valid-Since (RRVS) 解決帳號失效的問題

在「Facebook Yahoo Require-Recipient-Valid-Since SMTP Extension」這篇看到 Require-Recipient-Valid-Since (RRVS) 變成 Proposed Standard 了:「The Require-Recipient-Valid-Since Header Field and SMTP Service Extension」(RFC 7293)。

起因是從 2013 年的「yourname@yahoo.com Can Be Yours!」這篇開始的:Yahoo! 宣佈會釋出太久沒有使用的 @yahoo.com 帳號讓其他人可以註冊。

而這導致了帳號綁定問題:如果使用者先前在 Facebook 上 (或是其他服務) 有綁定 Yahoo! 帳號,而他的 Yahoo! 帳號被釋出被其他人拿走後,其他人就可以利用重設密碼的功能取得 Facebook 帳號權限。

Yahoo! 對這個問題的解法是透過 Require-Recipient-Valid-Since 處理,服務方 (像是 Facebook) 在發出重要信件時帶入 Require-Recipient-Valid-Since,要求這封信必須在某個時間點後有效,才能讓收信者看到這封信的內容。

Facebook 的人在「Protecting Facebook Accounts With New Email Standard」也提到了這個新標準。

Firefox 也要支援 Public Key Pinning Extension for HTTP

在「Mozilla to Support Key Pinning in Firefox 32」看到的新聞,目前的標準還是 draft:「Public Key Pinning Extension for HTTP」。

被簡稱 PKP 與 HPKP:(一般比較常用前者)

We call this "public key pinning" (PKP); in particular, this document describes HTTP-based public key pinning (HPKP).

可以看到 Google Chrome 程式碼裡面是怎麼使用 PKP 技術預載的:「/trunk/src/net/http/transport_security_state_static.json」。

目前 Google Chrome 使用的方式是限制 Google 的網域只能由某些特定的 CA 才能簽,這樣可以降低其他 CA 簽出高經濟價值的 SSL certificate 的效益。

Mozilla 的 wiki 上面可以看到對應的條目:「SecurityEngineering/Public Key Pinning」,目前 Firefox 的版本是 31,也就是從下一個版本就支援了。

第一波的 32 版會支援 Mozilla 自己的某些站台,以及一些 Twitter 的網域。

第二波的 33 版會把 Twitter 的部份擴充到 *.twitter.com,另外還會支援 Google 所擁有的網域。

第三波的 34 版會支援 Firefox account (*.accounts.firefox.com)、Tor 以及 Dropbox