用瀏覽器看 Netflix 加速播放

前陣子開始用 Netflix 看流言終結者,但以往看動畫已經習慣至少兩倍速了,舊址好找看看電腦上有沒有方案可以加速。

還頗幸運的是,早就有人把方法找出來了:「Netflix streaming playback speed and hidden menus」。

Netflix 在 Google Chrome 上面用 HTML5 player,而就有 extension 可以對 HTML5 player 加速:「Video Speed Controller」。

這樣消化影片的速度就快多了 :p

關閉 Google Chrome 49 的平滑捲動

在這次 Google Chrome 的「Stable Channel Update」裡引入了平滑捲動,在 comment 的地方有人提出解法,可以在 chrome://flags 裡找 disable-smooth-scrolling 關掉後重開 Google Chrome:

You can disable it here: chrome://flags/#disable-smooth-scrolling

另外一個 bug 是跑出一堆 extension icon 要重新蔵:

Hiding extensions needs to be made available again.

另外這次的安全更新有很多是透過「AddressSanitizer, ThreadSanitizer, MemorySanitizer」與「Control Flow Integrity」這兩個專案所找出來的。

Decentraleyes:避免從 Public CDN 取得檔案

先前看到的,一個 Firefox 的 Extension,在本地端存了一份常用的 library,當瀏覽器想要去 CDN 取得的時候改從本地端的資料提供:「Decentraleyes」。

Protects you against tracking through "free", centralized, content delivery. It prevents a lot of requests from reaching networks like Google Hosted Libraries, and serves local files to keep sites from breaking. Complements regular content blockers.

另外一個說明是:

A Firefox add-on that emulates Content Delivery Networks locally by intercepting requests, finding the required resource and injecting it into the environment. This all happens instantaneously, automatically, and no prior configuration is required.

原始程式碼在 GitHub 上:「Decentraleyes - Local emulation of Content Delivery Networks.」。

Google Chrome 上看連線是使用 IPv4 或是 IPv6

想說應該會有 extension 可以看連線是 IPv4 或是 IPv6,找了一下果然有:「IPvFoo」。

右上角會出現目前連線的屬性。透過 Google Chrome 提供的 webRequest 取得資訊後更新上去的。

目前比較常見的站台應該是 Facebook (包括 Instagram)、GoogleYahoo,也剛剛好都是 HTTPS Policy 的先驅... 不過可以看出來不是所有的資源都走 IPv6,還是有不少走 IPv4 的 domain。

Twitter 的主網站沒有 IPv6,但幾個自己的子網域有?看起來還在逐步測試開通...

HiNet 的 IPv6 服務已經可以透過網路櫃台直接線上申請 (需要幾個工作天開通),我用 Ubuntu 可以 PPPoE 取得...

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

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