Home » Posts tagged "safari"

在手機上看 Trac 的套件

這邊講的是 Safari 這些瀏覽器看 Trac,而不是講 app...

這次從高雄回來,在高鐵上想說用手機看看 Trac,發現桌機版的界面是會動,但在手機上不太好用,所以找看看有什麼套件可以改善...

回到家後找到 BlueFlatTheme 這套 (需要透過 ThemeEnginePlugin 啟用),標語是「A responsive, flat, blue theme using Bootstrap」,拿官方的 screenshot 可以看出來有特地為了寬度比較窄的情況調整:

裝好後用手機測了一下,還是有不滿意的地方,不過改善不少了,先這樣撐著...

Mozilla 跟 Google 都宣佈了 TLS 1.0 與 TLS 1.1 的退役計畫

UpdateApple 也宣佈了,時間點跟大家都差不多:「Deprecation of Legacy TLS 1.0 and 1.1 Versions」。

Mozilla 宣佈了「Removing Old Versions of TLS」,而 Google 也宣佈了「Modernizing Transport Security」,兩篇都是講自家瀏覽器 TLS 1.0 與 TLS 1.1 的退役時程。

Mozilla 這邊的計畫是 2020 年三月移除:

In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.

Google 這邊的計畫則是 Chrome 81 移除,換算成時間會從 2020 年一月開始影響到 canary channel,到 release channel 應該跟 Firefox 差不多時間:

In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.

差不多試從現在開始的一年半。

雖然這是講瀏覽器端的支援,但如果伺服器想要只支援 TLS 1.2+ 的話,就得考慮一下舊 client 支援的情況了。

桌機影響會比較小 (升級比較方便,替代方案也比較多),而行動平台看起來需要 Android 4.4+、iOS 7+,就要看各網站或是服務的族群了...

WebKit 對 HSTS Super Cookie 提出的改法

Twitter 上看到 WebKitHSTS 所產生的 Super Cookie 提出的改善方案:

拿原文的例子來說明,先指定一個隨機數給 user,像是 8396804 (二進位是 100000000010000000000100),所以就存取下面的網址:

https://bit02.example.com
https://bit13.example.com
https://bit23.example.com

在存取這些 HTTPS 網址時都會指定 HSTS,所以之後連到這三個網址的 HTTP request 就不會觸發到 HTTP 版本,會因為 HSTS 被轉到 HTTPS 版本。於是就可以用 32 個 HTTP request 測試 32bits 而判斷出身份。(當然你可以用更多)

WebKit 提出的改善方案大概有幾種,主要是就觀察到的現象來限制。

第一種解法「Mitigation 1: Limit HSTS State to the Hostname, or the Top Level Domain + 1」是因為會看到這樣的設計:

https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.example.com
…etc...
https://bit00.example.com
https://bit01.example.com
https://bit02.example.com
...etc...
https://bit64.example.com

所以提出的方案是只有目前網站的 domain 以及 top domain + 1 (像是 example.com) 可以被設定 HSTS:

Telemetry showed that attackers would set HSTS across a wide range of sub-domains at once. Because using HSTS in this way does not benefit legitimate use cases, but does facilitate tracking, we revised our network stack to only permit HSTS state to be set for the loaded hostname (e.g., “https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com”), or the Top Level Domain + 1 (TLD+1) (e.g., “https://example.com”).

但其實廣告主只需要註冊 32 domains (或是 64) 就可以避開這個問題。

第二種是「Mitigation 2: Ignore HSTS State for Subresource Requests to Blocked Domains」,如果在 HTTPS 頁面上,某個 domain 的 cookie 已經因為某些原因被阻擋 (像是手動設定),那麼就忽略掉 HSTS 的設計:

We modified WebKit so that when an insecure third-party subresource load from a domain for which we block cookies (such as an invisible tracking pixel) had been upgraded to an authenticated connection because of dynamic HSTS, we ignore the HSTS upgrade request and just use the original URL. This causes HSTS super cookies to become a bit string consisting only of zeroes.

後面這點在現在因為 SEO 設計而使得各大網站都往 HTTPS 方向走,應該會有些幫助吧...

所有主流瀏覽器的最新版都支援 WebAssembly 了

Mozilla 的「WebAssembly support now shipping in all major browsers」提到了最近幾個禮拜,新版的 SafariEdge 都相繼支援 WebAssembly 了:

In the past weeks, both Apple and Microsoft have shipped new versions of Safari and Edge, respectively, that include support for WebAssembly.

由於 ChromeFirefox 都已經支援了,這宣告 WebAssembly 的障礙都已經排除了,接下來只是時間的問題... 對於需要效能的應用程式來說多了一個方式加速。

在 iOS 上不使用 Facebook App 時要完全砍掉 process

在「The Background Data and Battery Usage of Facebook’s iOS App」這邊提到 Facebook AppiOS 上使用了非常吃電的技巧來強制背景更新。

作者猜測,如果你把 Facebook App 設定成不允許背景更新,那麼 Facebook App 會利用 iOS 在「播放音樂」可以在背景執行來進行更新:(所以只是打開播放的 channel,但是沒有聲音)

My guess is that Facebook is hijacking audio sessions on iOS by keeping silent audio in the background whenever a video plays in the app. And because, by default, videos on Facebook auto-play on both Wi-Fi and Cellular and few people ever bother to turn it off, that means there's a high chance the Facebook app will always find a way to play a video, keep audio in the background, and consume energy to perform background tasks.

而且有些人也發現了類似的現象:

I'm not alone in noticing the mysterious "Facebook audio" background consumption, and video auto-play seems to me the most likely explanation at this point. I don't know if turning off auto-play may fix the problem, but I'd recommend doing that anyway to save data.

印象中我們家的 zonble 也有提過類似的事情,當時他好像還有抱怨不知道 Facebook App 在搞什麼鬼... Anyway,這就可以理解作者提到為什麼這麼吃電:

On my girlfriend's iPhone, for instance, iOS 9 reports 5 hours of on-screen usage for the last 7 days, and another 11 hours of background audio usage with Background App Refresh turned off.

我的想法是,如果不用的時候就按兩下 home 鍵把 Facebook App 整個踢出去,或者就如同作者建議用 Safari 開行動版本:

I wonder if Apple should consider additional battery controls to take action against shady practices like invisible background audio. What Facebook is doing shows a deep lack of respect for iOS users. I continue to recommend using Safari instead.

在 iOS 9 裡安裝 Crystal 擋掉全版廣告

蘋果的 iOS 9 在今天放出來了,更新完以後可以用 Content Blocking 擋廣告,剛剛測過可以擋下全頁式的廣告。

這篇要介紹了的是「Crystal」這個目前限時免費的 app,你可以在「Crystal - Block Ads, Browse Faster.」這邊下載安裝。

iOS 9 的 Content Blocking 功能必須要應用程式支援,而目前只有 Safari 有支援,所以以下的測試是用 Safari 打開行動版的 Facebook (https://m.facebook.com/) 測試的,就拿這篇先來測試:(這張圖片是後來抓的,所以時間是 06:20)

直接打開會先出現全版廣告 (第一張圖),關掉後還會有大量的廣告 (第二張圖):

接著我們打開 Crystal,可以看到什麼都沒得設,因為這套軟體已經做完了:(這張圖片是剛裝完就裝的,所以是 06:00)

接著到「設定」裡面打開 Safari 的阻擋功能:

改完後就會是乾淨而且沒有廣告的版本了:

uBlock 的改版:交接後再 fork 成 uBlock Origin (uBlock₀)

原先的 µBlock 改名成 uBlock₀,並且把 uBlock 的名字交出去給了 Colorado SpringsuBlock

原因可以在「Please clarify uBlock₀ vs. uBlock」這邊看到,由於這不是 full time job (他也不想要成為 full time job),所以他決定 freeze 目前的功能,僅維持 bugfix (因為對他來說夠用了,他自己平常也在用)。

依照這個原因,我的感覺是 uBlock 會成圍下一個肥大的 ABP,就乖乖留守 uBlock Origin (uBlock₀) 吧。

Archives