Adblock Plus 的公司開始賣網路廣告了...

哈哈,果然開始不擇手段了:「Adblock Plus now sells ads」,Adblock Plus 官方的說明在「New Acceptable Ads Platform launches, will redefine RTB and help small websites」這邊。

繼續用「uBlock Origin」,沒有虛偽的「Acceptable Ads」,只有速度更快,效果更好...

Facebook 用哪些資訊來決定投放給你的廣告

華盛頓郵報整理出來了 Facebook 的廣告所使用的 98 個個人資訊:「98 personal data points that Facebook uses to target ads to you」。

基本的個人資訊 (甚至是朋友的),以及使用什麼瀏覽器都可以預期;而 Like 或是參加的 Group 都會被計算也是意料中的事情,不過連信用卡的種類也都在內就頗特別的...

來檢視一下自己的防禦機制有哪些... 瀏覽器預設擋下第三方 cookie:

Ghostery 預設把所有外部元件擋下來,再用白名單開想要看的部份。用 uBlock Origin 擋下所有廣告。

另外用「Force Facebook Most Recent」強制 Facebook 轉到 Most Recent 的 Timeline 上。

不知道這樣夠不夠用...

最後來列出這 98 個條件:

  1. Location
  2. Age
  3. Generation
  4. Gender
  5. Language
  6. Education level
  7. Field of study
  8. School
  9. Ethnic affinity
  10. Income and net worth
  11. Home ownership and type
  12. Home value
  13. Property size
  14. Square footage of home
  15. Year home was built
  16. Household composition
  17. Users who have an anniversary within 30 days
  18. Users who are away from family or hometown
  19. Users who are friends with someone who has an anniversary, is newly married or engaged, recently moved, or has an upcoming birthday
  20. Users in long-distance relationships
  21. Users in new relationships
  22. Users who have new jobs
  23. Users who are newly engaged
  24. Users who are newly married
  25. Users who have recently moved
  26. Users who have birthdays soon
  27. Parents
  28. Expectant parents
  29. Mothers, divided by “type” (soccer, trendy, etc.)
  30. Users who are likely to engage in politics
  31. Conservatives and liberals
  32. Relationship status
  33. Employer
  34. Industry
  35. Job title
  36. Office type
  37. Interests
  38. Users who own motorcycles
  39. Users who plan to buy a car (and what kind/brand of car, and how soon)
  40. Users who bought auto parts or accessories recently
  41. Users who are likely to need auto parts or services
  42. Style and brand of car you drive
  43. Year car was bought
  44. Age of car
  45. How much money user is likely to spend on next car
  46. Where user is likely to buy next car
  47. How many employees your company has
  48. Users who own small businesses
  49. Users who work in management or are executives
  50. Users who have donated to charity (divided by type)
  51. Operating system
  52. Users who play canvas games
  53. Users who own a gaming console
  54. Users who have created a Facebook event
  55. Users who have used Facebook Payments
  56. Users who have spent more than average on Facebook Payments
  57. Users who administer a Facebook page
  58. Users who have recently uploaded photos to Facebook
  59. Internet browser
  60. Email service
  61. Early/late adopters of technology
  62. Expats (divided by what country they are from originally)
  63. Users who belong to a credit union, national bank or regional bank
  64. Users who investor (divided by investment type)
  65. Number of credit lines
  66. Users who are active credit card users
  67. Credit card type
  68. Users who have a debit card
  69. Users who carry a balance on their credit card
  70. Users who listen to the radio
  71. Preference in TV shows
  72. Users who use a mobile device (divided by what brand they use)
  73. Internet connection type
  74. Users who recently acquired a smartphone or tablet
  75. Users who access the Internet through a smartphone or tablet
  76. Users who use coupons
  77. Types of clothing user’s household buys
  78. Time of year user’s household shops most
  79. Users who are “heavy” buyers of beer, wine or spirits
  80. Users who buy groceries (and what kinds)
  81. Users who buy beauty products
  82. Users who buy allergy medications, cough/cold medications, pain relief products, and over-the-counter meds
  83. Users who spend money on household products
  84. Users who spend money on products for kids or pets, and what kinds of pets
  85. Users whose household makes more purchases than is average
  86. Users who tend to shop online (or off)
  87. Types of restaurants user eats at
  88. Kinds of stores user shops at
  89. Users who are “receptive” to offers from companies offering online auto insurance, higher education or mortgages, and prepaid debit cards/satellite TV
  90. Length of time user has lived in house
  91. Users who are likely to move soon
  92. Users who are interested in the Olympics, fall football, cricket or Ramadan
  93. Users who travel frequently, for work or pleasure
  94. Users who commute to work
  95. Types of vacations user tends to go on
  96. Users who recently returned from a trip
  97. Users who recently used a travel app
  98. Users who participate in a timeshare

CloudFlare 的 Origin CA:保護 CloudFlare 到 Origin 這段的傳輸過程

CloudFlare 推出的 Origin CA 用來保護從 CloudFlare 到 Origin Server 這段的過程:「Introducing CloudFlare Origin CA」,也就是右半部這段:

CloudFlare 把這個新功能包裝得很神,但實際上只是弄個 CA 出來跑而已,僅此而已。

當然,由於他不需要處理 Public CA 的問題,所以有很多在一般 TLS 連線需要做的檢查步驟可以被簡化,藉此達到效能改善,包括了省掉 intermediate certificates、OCSP 以及 SCTs:

With Origin CA certificates, we’ve stripped everything that’s extraneous to communication between our servers and yours to produce the smallest possible certificate and handshake. For example, we have no need to bundle intermediate certificates to assist browsers in building paths to trusted roots; no need to include signed certificate timestamps (SCTs) for purposes of certificate transparency and EV treatment; no need to include links to Certification Practice Statements or other URLs; and no need to listen to Online Certificate Status Protocol (OCSP) responses from third-parties.

進而省下大量的連線成本:

Eliminating these unnecessary components typically found in certificates from public CAs has allowed us to reduce the size of the handshake by up to 70%, from over 4500 bytes in some cases to under 1300.

阻擋 PIXNET 的三分鐘閒置視窗

在看宵夜文「2016更新【2013台北宵夜美食小吃精選】松山區信義區大安區」的時候做其他事情,回來就看到 in-window popup 視窗,決定擋下來,所以就把 html 找出來:

<div class="modal idle-pop" tabindex="-1" role="dialog" aria-describedby="dialog">
    <div class="modal-content">
      <div class="modal-header">本網頁已閒置超過 3 分鐘。請點 <kbd>關閉>/kbd> 或 <kbd>點擊</kbd>任一空白處,即可回到網頁</div>
      <div class="modal-body">

我選擇的方法是透過 uBlock Origin 阻擋元素:

pixnet.net##.idle-pop

然後重新開 blog 頁面,等個幾分鐘後確認就可以了。

Google CDN 進入 Beta

最近 CDN 產業裡有不少蕭期,其中一個新聞是 Google CDN 進入 beta,Google 藉由在全球佈署的機房來服務。

不過雖然進入了 Beta,但仍然有很嚴重的技術限制,只能透過 GCE 當 origin server,這使得實用性低很多:

Origins
Delivers HTTP/HTTPS content originating from Compute Engine VM instances. External origin servers are not supported.

有些特點是跟一般 CDN 不同的,一個是 Google 對 HTTPS 的口號,所以 HTTP 與 HTTPS 的價錢相同。其實你就當做他把 HTTP 的費用收的跟 HTTPS 一樣就好:

SSL Shouldn't Cost Extra
The web is moving to HTTPS, and your cacheable content should, too. With Cloud CDN, you can secure your content using SSL/TLS for no additional charge.

另外一個特點是從技術上就宣稱完全使用 Anycast,而不是見到的 DNS + Anycast:

Anycast
Serve all your content from a single IP address with low latency worldwide.

另外,計價的方式與其他的 CDN 有不少地方不一樣,另外也有針對中國地區另外處理。

首先是他把 Cache Egress (從 CDN 給使用者) 與 Cache Fill (從 CDN 到 Origin 取得資源) 分開收,一的般 CDN 都只收 Cache Egress 這塊。

再來是中國大陸地區的價錢另外標示,有特地標明不是從中國大陸地區直接提供服務:

Traffic destined for mainland China is served from Google locations outside of mainland China. Performance and reliability may be lower than for traffic served from in-country locations.

言下之意就是另外買 optimized 的頻寬來服務,但還是不會像在中國大陸地區有機房的效果這麼好,不過好處是不需要 ICP 之類的證照。

不過不得不說價錢其實還蠻便宜的,無論是歐美還是亞洲區。

HTTPS 因為安全性而不能使用 Referrer 的問題

Nuzzel 上看到老文章在討論 HTTPS 環境下因為安全性考量,而不能帶出 Referrer 的問題:「Where did all the HTTP referrers go?」。

原文中「Fixing Referrers in HTTPS: The Meta Referrer」這邊就有提到 HTML5 meta referrer,也就是 W3C 的「Referrer Policy」,問題是到現在還是 Draft 啊...

也因為過了三年,其實 draft 裡面多了不少參數可以用:

  • neverno-referrer 表示不傳。
  • origin 表示只傳 protocol + host 的部份,後面 path 的部份不要傳。
  • defaultno-referrer-when-downgrade 表示當 downgrade 時 (HTTP request 的部份) 不要傳。
  • origin-when-cross-origin 表示當跨站時用 origin 的邏輯,但本站還是用完整的路徑。
  • always 或是 unsafe-url 則是永遠都傳。

其中刪節號表示 W3C 不建議再使用,應該用後者比較新的。

不過因為在 Can I use 上面可以看到 Microsoft Edge 只支援舊的關鍵字 (也就是刪節號的那些),所以還是可以考慮先用舊的關鍵字,讓 Microsoft Edge 也可以被保護到:「Referrer Policy」。

CloudFront 對 Origin 支援 TLS v1.1 與 v1.2

CloudFront 宣佈支援對 Origin 使用 TLS v1.1 與 v1.2 了:「CloudFront Update – HTTPS & TLS v1.1/v1.2 to the Origin, Add/Modify Headers」。

另外一個重要的功能是,強制使用 HTTPS 往 Origin 存取,即使使用者對 CloudFront 使用 HTTP,往後也還是會用 HTTPS,確保資料不會被中間的 ISP 改掉。

再來比較期待的功能是有沒有類似 Akamai 的 TD (Tiered Distribution) 或是 EdgeCast 的 Super PoP,也就是全球的 Edge 都透過這組 Server 再跟 Origin 要資料。這樣可以大幅度提高 hitrate,並且降低對 Origin 的負載。

Amazon API Gateway 支援 CORS 了

在「Enable CORS in Amazon API Gateway」這邊看到 Amazon API Gateway 支援 CORS (Cross-origin resource sharing) 了,這樣前端頁面就可以直接 call 進去使用了...

文件可以在「Enable CORS for a Method in API Gateway」這邊看到,主要就是這個頁面的設定:

看起來是個小功能,但卻影響很大... 這代表又有一大塊開發者會進去研究。

Google Chrome 會 bypass Adblock 的問題

新版的 Google Chrome 使得 YouTube 可以繞過 Adblock 類軟體的阻擋限制 (像是 uBlock Origin),導致這些使用者會需要「看完完整的廣告影片 (無法 skip)」才能看本篇:「Google Chrome reportedly bypassing Adblock, forces users to watch full-length video ads」。

目前確認這是在修正 CVE-2015-1297 時產生的 bug:

Update: We have been contacted by Rob Wu, a developer on the Chromium project - the open-source foundation for the Chrome browser - who has informed us that this change was not intentional but, rather, an unintended result of fixing a previous security issue (CVE-2015-1297). He confirmed that the issue will only be seen if the YouTube app is installed and that, at the moment, apart from disabling AdBlock or whitelisting YouTube, the only solution, as described above, is to uninstall the app. The problem is expected to be patched in the upcoming weeks or, at least, when Chrome 46 is released.

目前的暫時解法是移除掉 YouTube 這隻 app,或是將 YouTube 放到白名單網站。

uBlock₀ 提供阻擋 WebRTC 取得 Local IP address 的功能

Google Chrome 上之前是透過 WebRTC Block 之類的軟體阻擋網站透過 WebRTC 取得 Local IP address 的功能,現在則內建在 uBlock₀ 內了。

在「You can block WebRTC from leaking your IP now in uBlock Origin」這邊看起來是這個月月初 (2015 年 7 月) 開發出來的功能。

WebRTC Leaktest 交叉測試可以發現 Public IP address 的部份,目前測過的套件都擋不下來,但 Private IP address 的部份都有順利擋下來。

又可以少裝一個套件了...