Home » Computer » Software » Browser » Archive by category "GoogleChrome"

HTTPS Everywhere 改變更新 Ruleset 機制,變成定時更新...

HTTPS Everywhere 是我很喜歡的一個套件,裡面有 Ruleset,會將 Ruleset 表內認定有支援 HTTPS 網站的 HTTP request 都改成 HTTPS,這可以降低被攔截的風險。像是網站雖然有 HSTS 但第一次連線時走 HTTP 的情況,以及網站本身有支援 HTTPS 但沒有設定 HSTS 時,在網址列上誤打 HTTP 版本的情況。

先前版本的 Ruleset 是隨著軟體更新時,包在軟體內一起更新。這樣的缺點是更新速度比較慢,但好處是不需要伺服器端,而且隱私性也比較高。而現在 EFF 決定還是要推出線上更新的版本,以加速 Ruleset 更新的速度:「HTTPS Everywhere Introduces New Feature: Continual Ruleset Updates」。

We've modified the extension to periodically check in with EFF to see if a new list is available.

而頻寬的部份由 Fastly 贊助:

If you haven't already, please install and contribute to HTTPS Everywhere, and consider donating to EFF to support our work!

如果對這點有疑慮的,也還是可以關掉 auto updater 避免洩漏資訊給 EFF 或是 Fastly。

本來 Google Chrome 要繞過 HSTS 的 badidea 被換掉了...

先前在「在 Google Chrome 連上因 HSTS 而無法連線的網站」中提到的關鍵字 badideaGoogle Chrome 65 發現沒用了,找了一下發現是被換掉了:「Chrome 65 replaces the "badidea" bypass keyword with "thisisunsafe"」,這 Reddit 的標題就說明了換成什麼了 XDDD

而且從 source code 裡面可以看到,本來是明碼的 badidea,改用 window.atob 來存了:「Diff - d8fc089b62cd4f8d907acff6fb3f5ff58f168697^! - chromium/src - Git at Google」。

anyway,要記其他的字串了 XDDD

今年十月 Firefox 將完全不信任 Symantec 簽出的 SSL Certificate

Mozilla 旗下的產品 (包括 Firefox) 將在今年十月對 Symantec 簽出的 SSL Certificate 終止信任:「Distrust of Symantec TLS Certificates」。

Mozilla 有把發生的事情都整理出來:「CA:Symantec Issues」,另外 Firefox 的動作分成三個階段,目前 stable 是 58,但 nightly 是 60 了:

  • January 2018 (Firefox 58): Notices in the Browser Console warn about Symantec certificates issued before 2016-06-01, to encourage site owners to replace their TLS certificates.
  • May 2018 (Firefox 60): Websites will show an untrusted connection error if they use a TLS certificate issued before 2016-06-01 that chains up to a Symantec root certificate.
  • October 2018 (Firefox 63): Distrust of Symantec root certificates for website server TLS authentication.

去年 Google Chrome 就有先丟出對 Symantec CA 的計畫 (參考「Google Chrome 對 Symantec 全系列憑證的不信任計畫」這篇),看起來 Mozilla 的計畫也差不多,但時間有些差異...

Windows 上的 Chrome 改用 Clang 編譯

這應該是上個禮拜蠻熱鬧的一件事情 (i.e. 很多人看熱鬧 XD),就是 Google ChromeVisual C++ 改成用 Clang 編譯:「Clang is now used to build Chrome for Windows」。

文章裡推敲效能應該不是主要的因素,因為在不同項目測試下各有千秋,而且差距都不大:

We conducted extensive A/B testing of performance. Performance telemetry numbers are about the same for MSVC-built and clang-built Chrome – some metrics get better, some get worse, but all of them are within 5% of each other.

後面有猜測換過去的原因,可以看出因為 open source 加上 Google Chrome 團隊有強大的技術能力下,用 open source 軟體可以對 compiler 大量客製化各種功能,另外也是因為一個 compiler 就可以吃多個平台,可以省下一些跨平台的力氣 (像是相容性語法)。

而 Visual C++ 在商業支援與文件兩方面比較好的優勢,在這個情況下就顯得不是那麼重要了...

Firefox 對 HTTPS 網站中 "Referer" 的保護

Firefox 從 59 之後,在開啟 Private Browsing 的情況下,不會送出完整的 Referer:「Preventing data leaks by stripping path information in HTTP Referrers」。

這篇吸引到我的是 EFF 的研究員發現的事情:

EFF researchers discovered this leak of personal health data from healthcare.gov to DoubleClick.

其中 EFF 研究員的文章是「HealthCare.gov Sends Personal Data to Dozens of Tracking Websites」這篇。

更好的作法應該是平常就完全阻擋,像是 Firefox 可以用 Referrer Control 設定,或是 Chrome 裡用 Referer Control 設定。

V8 version 6.5 (Chrome 65) 的改變

V8 version 6.5 將會有不少改變:「V8 release v6.5」。

其中因為 Spectre 的關係,新的 V8 設計了 Untrusted code mode,拿來跑不信任的程式,裡面會設計反制措施。而且這在新版的 Chrome 將會預設開啟:

In response to the latest speculative side-channel attack called Spectre, V8 introduced an untrusted code mode. If you embed V8, consider leveraging this mode in case your application processes user-generated, not-trustworthy code. Please note that the mode is enabled by default, including in Chrome.

另外是針對 WebAssembly 提供邊下載邊 compile 的能力,這讓速度大幅提昇。在原文是拿一個比較大包的 WebAssembly 來測試:

For the graph below we measure the time it takes to download and compile a WebAssembly module with 67 MB and about 190,000 functions. We do the measurements with 25 Mbit/sec, 50 Mbit/sec, and 100 Mbit/sec download speed.

可以看到網路不夠快的使用者就會直接被 compile 速度跟上,讓瀏覽器在下載時就做一些事情。

另外在某些情況下對 Array 的操作會有大幅改善:

這些新功能與改善都會在 Chrome 65 推出。依照「Chrome Platform Status」這邊的資料,stable 版預定在三月初,beta 版應該是要出了... (雖然上面寫著 2/1,但目前好像還沒更新)

幾個 Web API Manager 要設定的東西...

在上一篇提到的「控制瀏覽器裡的 Web API」,用了一兩天後有遇到一些問題,大概整理一下...

  • Gmail 會開不起來,需要將 mail.google.com 列入白名單 (一個阻擋條件都不能設),這是因為遇到瀏覽器的 bug,在「General breakage on specific site · Issue #55 · snyderp/web-api-manager」這邊作者有找到問題,他判斷是瀏覽器的問題後開了 ticket 給 FirefoxChrome,不知道什麼時候會好...
  • 同理,Facebook 右上角的通知也出不來,也是同樣的問題,需要把 www.facebook.com 列入白名單。
  • 另外是 Google Maps 用滑鼠滾輪滾動本來是平滑式的縮放,現在用起來會變成階段式的縮放,原因是 Google Maps 用到 WebGL Specification (在 Lite 裡面會阻擋)。這有兩個方向可以改,一個是把 www.google.com (或是 www.google.com.tw,看你用的網域) 另外開一組設定管理,另外一個是直接把 WebGL Specification 的阻擋關掉。

目前遇到的大概就是這些了...

控制瀏覽器裡的 Web API

在「阻止网站调用不必要的你的浏览器 API」這篇裡面看到的,論文的作者發展了 ChromeFirefox 的延伸套件,可以控制瀏覽器內的 Web API。套件原始程式碼在 GitHubsnyderp/web-api-manager,頁面上有 Chrome 與 Firefox 延伸套件的連結可以直接安裝。

套件本身預設不會擋任何 Web API,但提供了三種不同的 Preset 讓你選 (Lite、Conservative 與 Aggressive),一般情況下用 Lite (擋掉 17 種 Web API) 就有不錯的效果了。另外也可以針對某些網域做另外的調整... (雖然還沒用過 XD)

直接抓 Google Chrome 上給的截圖:

這是個好東西啊,有些 API 出來擺明就是來追蹤使用者的... 關掉省麻煩 XD

2FA 的 QR code 與 CanvasFingerprintBlock

在「Rasmus Lerdorf 關於 VPS 的介紹測試...」這篇的留言裡,Jimmy 提到 Vultr 是有 2FA 可以用的 (當初沒找到...),於是就花了點時間設定...

但設定的過程中發現 TOTP 的 QR code 出不來,但在 dev console 裡面卻看得到 img 元素。

這種情況前幾個月在另外一個網站上也遇過 (當下拿 Firefox 測也不行),於是就認為他們網站的問題,開了 support ticket 也沒回,一直沒下文的情況下就丟著。現在在 Vultr 上又遇到同樣的問題的話,看起來有可能是我的問題 (或是他們兩個站台都用同樣的 library),於是就仔細點找...

找的過程中間發現有 canvas 元素,然後 canvas 元素有個 inline css 是 display: none;,先試著把這條拿掉,就出現了... 接下來就好猜了。

在 2014 年的「用 Canvas Fingerprint 取代部份 Cookie」這篇就有提過可以用 Canvas 追蹤使用者的問題,於是就有介紹了 CanvasFingerprintBlock 這個在 Google Chrome 上的套件,阻擋 Canvas 的存取。一關掉這個套件就正常了 XDDD

為了隱私問題,套件本身還是掛著,但當遇到發現有 QR code 出不來的時候就知道去 dev console 內改掉 XDDD

然後回到原來本來以為有問題的那個網站,也是一樣進 dev console 改掉後就看得到可以掃了... 看起來這兩個站可能是用一樣的 library?找出來再去戳這兩個站好了...

Archives