在 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₀) 吧。

jQuery 1.11.2 與 2.1.3 修正 iOS 8 上 Safari 7.1/8 的嚴重 bug

看到 jQuery 官方放出一個特別更新,專門為了 iOS 8 + Safari 7.1/8 的修正:「jQuery 1.11.2 and 2.1.3 Released – Safari Fail-Safe Edition」。

依據「Test failure on iOS 8: child and adjacent -> p#firstp + p」的說明,死在 document.querySelectorAll("p#firstp + p") 這邊,另外以下的 selector 也都掛掉:

p#a + p
p#a ~ p
.b#a ~ [id]
[style]#a ~ p

由於這個用法太基本,讓 jQuery 官方決定在 library 放 workaround 修正這個問題...

修正 Mac OS X Yosemite (10.10) 的設定以確保隱私

Hacker New Daily 上看到的:「Fix Mac OS X Yosemite」。原因是 Spotlight 的部份 AppleBing 合作:

If you've upgraded to Mac OS X Yosemite (10.10) and you're using the default settings, each time you start typing in Spotlight (to open an application or search for a file on your computer), your local search terms and location are sent to Apple and third parties (including Microsoft).

有兩個地方要關閉。一個是系統設定,一個是 Safari 設定,細節在原文裡面有,這邊就不抄過來了。

Wildcard EV Certificate...

Netcraft 這篇「Wildcard EV certificates supported by major browsers」提到幾個重點...

首先是 EV 規範內禁止使用 Wildcard certificate (出自「Guidelines ForThe IssuanceAnd Management Of ExtendedValidationCertificates」):

Wildcard certificates are not allowed for EV Certificates.

然後還是有人發 *.cclearning.accenture.com,而且主流瀏覽器會正常照 EV 模式顯示出來:(這邊拿 Google Chrome 的範例,原文有所有截圖)

只有 Safari 的手機版本當作普通 certificate 處理的:(下面兩張圖,上圖是桌機版,下圖是手機版)

被抓出來鞭後應該會修正... 吧?

Update:感謝 comment 的糾正,Safari 的地方寫錯了...

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 沒幾家)

window 的 hashchange (onhashchange) 事件

hashchange 是 HTML5 event,紀錄一下目前支援的情況:

目前 IE6/IE7 常見的模擬方式是透過 hidden iframe 做類似的效果...

另外在偵測瀏覽器是否有支援 hashchange 可以利用「Detecting event support without browser sniffing」這篇說明的方式偵測是否有支援特定的 event,可以避免使用 browser sniffing。