Google Chrome 停用平滑捲動

因為把 JavaScript 開回來了,所以有這個困擾... :(

Google Chrome 的平滑捲動可以透過 chrome://flags 裡面的設定關閉 (OS X 上則是透過系統設定關閉),但就是有不少網站會很雞婆,用 JavaScript 模擬平滑捲動,所以就花了時間把 extension 寫出來:「Stop Smooth Scrolling」。

由於大多數平滑捲動的作法都是透過對 document 或是 window 上掛上與平滑捲動相關事件做到的,所以我是透過 addEventListener()useCapture flags,然後再用 preventDefault() 擋下後續的處理。

這樣做會有一些問題,其中比較明顯的是地圖類功能的滾輪會失效,這個部分我先放進預設的白名單了,如果有其他的問題,除了可以自己加以外,也可以開 ticket 讓我加進預設清單 :o

實際運作起來大概是這樣:

Anyway,寫這個還蠻有趣的,玩了不少新東西:

Go 上面的白箱安全性檢查

HP 的 open source 專案「Go AST Scanner」,分析 Go 的原始程式碼拉出 AST 進行分析 (Static program analysis),再找出可能的安全性問題。

雖然是 alpha 階段,但看起來是個好東西啊... 至少寫的太誇張的 SQL injection 可以掃出來。

AWS 的 Developer Support Plan 漲價

AWS Support 中的 Developer Support Plan 漲價了:「AWS Support announces update to Developer Support plan」。

本來是固定 $49/month,現在變成 $29/month 或是 3% (取高的,也就是超過 USD$966.66/month 後要以 3% 計算):

A new pricing model for our Developer Support plan has been launched, reducing the entry cost from $49 per month to $29 per month, while providing the same level of customer service and support. As of July 26th, 2016 all new AWS accounts subscribing to Developer Support will receive the new pricing, set at the greater of $29 or 3% of monthly AWS spend.

大概是因為很多 production 用戶都只申請這個吧 (只是為了開 ticket 而已),不過這邊只提到「all new AWS accounts subscribing to Developer Support」,沒提到舊的用戶會怎麼處理...

Linode 收 PayPal 了,只是...

Linode 宣佈支援 PayPal 了:「PayPal Payments」,只是:

While any customer can use PayPal to fund their account, new customers will still need to sign up using a credit card. You can use PayPal from then on.

而原因是:

This is in part because we don’t yet have the ability to automatically transfer funds from PayPal. If you intend on paying only via PayPal, you will need to ensure that you have enough credit on your Linode account to cover your next invoice. Otherwise, our system will attempt to collect any remaining balance from the credit card you have on file.

這理由爛爆了 XDDD

Google 提出的 Jump Consistent Hash

堆了一陣子的文章...

當有 n 台 cache server 給你使用,最傳統的作法是 hash(key) % n 決定挑哪一台 cache server,但這個方法在增加或減少機器時就會讓 cache 大規模失效。Consistent Hashing 就是希望在這種情況下 (增加或是移除 cache server 時) 可以避免大規模 cache 失效的問題。

比較基本的 Consistent Hash 作法是將 hash(key) 的值對應到 ring 上 (假設是 hash value 的範圍是 32bits,也就是 0 到 0xFFFFFFFF,那麼 ring 繞一圈平均分佈),像是一開始只有三台,所以就是三個 bucket:

取自「Consistent hashing」這裡。

等加了機器後就分擔掉本來的 hash value 區段:

取自「Consistent hashing」這裡。

這樣的作法通常會需要 O(log N) 的時間複雜度 (query & add/remove server) 與 O(n) 的空間複雜度。

另外會有平均性的問題需要解決,通常的 workaround 是讓一個 server 有很多 virtual bucket 在 ring 上面解,像是這樣:

取自「The Simple Magic of Consistent Hashing」。

Google 在 2014 年發表出來的 Jump Consistent Hash 則給了更好的方案,O(1) 的空間使用率以及 O(logN) 的時間複雜度 (query only),而且非常平均的打散:「A Fast, Minimal Memory, Consistent Hash Algorithm」。

論文裡面給了 C++ 的實作:

int32_t JumpConsistentHash(uint64_t key, int32_t num_buckets) {
  int64_t b = ­-1, j = 0;
  while (j < num_buckets) {
    b = j;
    key = key * 2862933555777941757ULL + 1;
    j = (b + 1) * (double(1LL << 31) / double((key >> 33) + 1));
  }
  return b;
}

神秘數字 (還出現 double) 與神秘的迴圈... 在 Performance Analysis 這段解釋了時間複雜度明顯跟迴圈有關,分析後可以得到 O(log N):

The time complexity of the algorithm is determined by the number of iterations of the while loop. [...] So the expected number of iterations is less than ln(n) + 1.

再來是 Consistent Hash 會討論「平均性」這個問題,可以看到跟以前的方法不是同一個級別:

執行的效率也非常好,要注意的是 X 軸是對數座標:

在 Note 的部份也說明了這個演算法 Google 沒有計畫要弄專利 (也公開出來了):

Google has not applied for patent protection for this algorithm, and, as of this writing, has no plans to. Rather, it wishes to contribute this algorithm to the community.

Humble Bundle 對抗信用卡盜刷的方法

Humble Bundle 說明他們如何對抗信用卡盜刷的方法,主要是不斷的降低風險,然後讓人介入的機會降低 (因為人事成本很高):「How Humble Bundle stops online fraud」。

其中第一點是特別想提的:

Our first line of defense is a machine-learning-based anti-abuse startup called Sift Science, which we’ve been training for years across 55,000,000 transactions. Given how many orders we process, Sift Science has a really good idea when someone is up to no good. The model adapts daily as we get more data.

Sift Science 在 2014 的時候提過:「偵測信用卡交易是否為盜刷的服務」。做的事情很簡單,你把大量的資料傳給 Sift Science,包括了各種使用者身份資訊,以及信用卡資料,Sift Science 可以透過 Machine Learning 的方法告訴你這筆交易的風險,讓你進一步的判斷。

其實不少家都有做類似的服務,像是 MaxMindminFraud (就是做 GeoIP database 很有名的那家公司的另外一個產品)。當交易量很大的時候是個很有趣的應用,降低處理盜刷後續處理的成本。

維基百科的 User Agent 公開資料

Nuzzel 上看到的東西...

維基百科不掛 Google Analytics 之類的第三方服務,而是透過 Piwik 蒐集後自己分析:「Dashboards and Data Downloads for Wikimedia Projects」。

主要有兩個資料可以看,一個是「Browser Statistics」,另外一個是「Readers: Pageviews and Unique Devices」。

不過翻了一下,Piwik 好像還是沒有寫到 NoSQL 之類的方案,出自「How do I use another database like Postgresql, SQLite, Oracle? Will you support Nosql databases like Hadoop, Mongodb?」:

Piwik only works on Mysql, where all the development and testing is done. Supporting multiple databases is a long term objective for Piwik, but not our current focus.

不知道維基百科是怎麼 scale 的...

利用 CloudFlare 的 reCAPTCHA 反向找出真正的 Tor 使用者

Cryptome 這邊看到可能可以被拿來用的技巧:「Cloudflare reCAPTCHA De-anonymizes Tor Users」。

Tor 使用者連到 CloudFlare 上時,常常會出現 reCAPTCHA 的提示,要求你驗證,而這個驗證過程的 traffic pattern 太龐大而且很明顯,當情治單位同時可以監控 CloudFlare 的上游 (像是「Airtel is sniffing and censoring CloudFlare’s traffic in India and CloudFlare doesn’t even know it.」這篇提到的問題) 或是監控 Tor 的 exit node 的上游,再加上同時監測使用者可能的 ISP,就可以對照湊出使用者:

Each click on one of the images in the puzzle generates a total of about 50 packets between Tor user's computer and the Cloudflare's server (about half are requests and half are real-time responses from the server.) All this happens in less than a second, so eventual jitter introduced in onion mixing is immaterial. The packet group has predictable sizes and patterns, so all the adversary has to do is note the easily detectable signature of the "image click" event, and correlate it with the same on the Cloudflare side. Again, no decryption required.

短短的一秒鐘內會產生 50 個封包,而且 pattern 很清楚...

舊 bug 新名字:httpoxy

依照慣例,security issue 都會取個名字,這次叫做 httpoxy:「A CGI application vulnerability for PHP, Go, Python and others」。

事情發生在兩個命名變數上的衝突:

  • RFC 3875 (The Common Gateway Interface (CGI) Version 1.1) 定義了 CGI 環境會把 Header 裡的 Proxy 欄位放到環境變數裡的 HTTP_PROXY
  • 而很多程式會拿環境變數裡的 HTTP_PROXY 當作 proxy 設定。

這件事情 2001 年在 libwww-perl 就有發生過 (並且修正),curl 也發生過 (然後修正),2012 年在 Ruby 的 Net::HTTP 也發生過 (也修正了)。

然後在 2016 年還是被發現有很多應用程式會中獎... 這頭好痛啊 :o