因為 Google Chrome 太慢而換 CPU (以及主機板)

本來是用 AMDX4 905e,拿來跑 Ubuntu 當跳板機,偶而看看影片還算夠用,不過 Google Chrome 的速度已經影響到工作了,星期六晚上家庭聚餐結束後就去八德路上原價屋拿了一顆新的 CPU 與主機板...

換上 IntelXeon E3-1230 v3 後 Ubuntu 也不需要重裝,Google Chrome 的速度也快多了...


取自「PassMark - AMD Phenom II X4 905e - Price performance comparison


取自「PassMark - Intel Xeon E3-1230 v3 @ 3.30GHz - Price performance comparison

沒想到是因為瀏覽器而換 CPU...

Google Chrome 上預防 Clickjacking 的套件...

Gene 寫的「如何在你不知情被自動加入粉絲團的秘技, 以 "粉你的" 作示範」這篇裡面用到的技巧叫做 Clickjacking (點擊劫持)。

Facebook 有給出「What is clickjacking?」的說明,不過相當白話 (而且沒有幫助 Orz)。

技術上的解釋是,其中一種實作是在要點擊的對象上加上一層「透明的」DOM 物件,當 click 時就會點到該物件。目前最常見的是 Facebook 的 Like 按鈕。(i.e. Gene 寫的那篇)

Google Chrome 上可以用「Clickjacking Reveal」這個套件:

This extension tries to warn you if it found clickjacking technique on the page you are viewing.

Tired because of webpage tricks you into clicking social network buttons? This extension will try to detect those hidden bad buys and force them to show themselves.

效果是這樣:(範例出自「胖妞變身大美女 甩肉40斤練出腹肌」這篇)

Google 對四個 Cipher 的分析... (以及 ChaCha20-Poly1305)

Google Online Security Blog 上對四種 cipher 的分析:「A roster of TLS cipher suites weaknesses」。

分別是 RC4、AES-CBC、AES-GCM、ChaCha20-Poly1305 四個 cipher。其中 RC4 與 AES-CBC 的問題都很多,而 AES-GCM 與 ChaCha20-Poly1305 是目前還沒有有效攻擊的 cipher。

前面三個都算熟悉,第四個是到是頗意外會出現... 不過 ChaCha20-Poly1305 不只一家打算跳下去實做了:

ChaCha20 與 Poly1305 都是 D. J. Bernstein (djb) 的作品,不知道 OpenSSL 會不會納進去...

在「ChaCha20 and Poly1305 for TLS」這邊有些為什麼有了 AES-GCM 後還要用 ChaCha20-Poly1305 的原因,主要是速度考量。兩者的速度差非常多...

Windows XP 上的瀏覽器...

微軟對 Windows XP 的支援到 2014 年 4 月 8 日:


出自「Support is ending for Windows XP - Microsoft Windows

Google Chrome 也宣佈只支援到 2015 年 4 月 (晚一年):「Extending Chrome support for XP users until April 2015」。

目前 Mozilla 還沒說什麼,不過應該也不會比 Google Chrome 長太久吧,畢竟 Windows 7 的市占率一直在提昇...

移除 Remove Facebook Redirections...

Google Chrome 裝上 Remove Facebook Redirections 可以避免 Facebook 重導,加減提高些隱私性...

不過最近發現當 Facebook 捲頁捲很長時會變得爆慢,但網路上好像沒有人提到這個問題?看起來應該是我的某個 extension 造成的,測了老半天發現是這個 extension 的問題 :o 然後身為工程師的直覺,這八成是每次增加元素後直接對整個 document 全掃一次造成的...

翻 source code 後 (直接到 Default/Extensions/onhdomkbnapoacbialllfpbcckckidck/1.2_0/ 裡的 RemoveFacebookRedirections.js 翻) 可以發現 huntForLinks() 果然就是這樣做...

先移除掉再說 @_@

Firefox 加強對 Cookie 的管制...

Mozilla 官方的 Blog 上說明了 Firefox Nightly 引入了新的 Cookie 機制,預設將不允許以追蹤為目的的 cookie:「Firefox getting smarter about third-party cookies」。

最粗淺的想法是,如果 cookie 是沒有逛過的網站所發出來的就擋掉。所以:(出自 bug 818340 的 comment)

1) if an origin is first-party, it has ordinary cookie permissions
2) if an origin is third-party
	a) if the origin already has cookies, it has ordinary cookie permissions
	b) otherwise, the origin gets no cookie permissions

也就是在 Mozilla Bugzilla 裡的紀錄「Block cookies from sites I haven't visited」,開 bug 的作者是看到 Safari 處理 cookie 的方式而決定要在 Firefox 上也幹類似的事情 :p

所以 google-analytics.com doubleclick.net 的 cookie 永遠不會成立 (因為沒去過這個網站),但 facebook.com 的外掛還是會動... 其他的廣告商就類推... XD

這對於目前的廣告商會很傷 :p 透過 cookie 實作個人化廣告的功能會被廢掉一半的武功,得用其他方法惡搞 :o 可以預期在 Google Chrome 後面的 Google 一定超級不想實作這功能... XD

不過 Google Chrome 好像可以自己阻擋第三方 cookie,然後設定白名單,晚點來研究看看... (反正會保持登入的 social network 沒幾家)

新版的 Google Chrome 將會在 Tab 上 Icon 標示發出聲音...

開了一堆頁面,卻找不到放音樂的 tab 是哪個?在新版的 Google Chrome 裡會將正在放音樂的 tab 用動畫標示在 tab 上的 icon:「Chrome Shows Which Tab Is Making a Noise」,像是這樣的提示:

目前在 Canary channel 裡才有,等個幾個月就會在正式版本出現了... (canary -> dev -> beta -> stable)

這次 TURKTRUST 誤發 *.google.com SSL 憑證...

這次 TURKTRUST 誤發 *.google.com 憑證被 Google 當初佈下的網子抓到:「Enhancing digital certificate security」。

首先是每次 CA 出問題後都會對目前的 PKI 提出質疑的文章 (像是「TURKTRUST Incident Raises Renewed Questions About CA System」),在沒有有效的方法可以取代目前的 PKI 前,都是吵一吵之後就沒有結論,所以先不管這個題目。

想要提出來的是 Google 這次抓到的機制:「Public Key Pinning Extension for HTTP」,目前狀態仍是 draft。不過 Google 在 Google Chrome 13 就已經實作一部分了,並且把一堆 domain 寫死進去:「View of /trunk/src/net/base/transport_security_state_static.json」,可以看到 Google 的 domain 只允許這些 CA 簽:

      "name": "google",
      "static_spki_hashes": [
        "VeriSignClass3",
        "VeriSignClass3_G3",
        "Google1024",
        "Google2048",
        "EquifaxSecureCA",
        "GeoTrustGlobal"
      ],

任何想要在太歲爺上動土的都會被抓包 XD

另外 Google Chrome 還是沒有 Certificate 相關的 API,目前只有 API Proposal 掛著:「webRequest SSL Hooks」,相較於 Firefox 有不少 extension 可以用,這方面 Google Chrome 就差了不少...

Google Chrome 23 內建 DNT 設定了...

在「Google Implements Do Not Track in Chrome 23」這邊被提醒 Google Chrome 23 支援 DNT,到設定頁裡把「顯示進階設定...」展開,然後把『將「不追蹤」要求與瀏覽流量一併送出』勾起來就可以了:

開發工具可以看到送出要求時會帶 DNT: 1