Uber 戰火蔓延到 Unroll

最近 Uber 的 CEO 被 Tim Cook 叫去喝咖啡的事情被報導出來:「Uber’s C.E.O. Plays With Fire」,裡面提到了 Uber 試著要「辨別」使用者的 iPhone,而這違反蘋果的政策:

To halt the activity, Uber engineers assigned a persistent identity to iPhones with a small piece of code, a practice called “fingerprinting.” Uber could then identify an iPhone and prevent itself from being fooled even after the device was erased of its contents.

There was one problem: Fingerprinting iPhones broke Apple’s rules. Mr. Cook believed that wiping an iPhone should ensure that no trace of the owner’s identity remained on the device.

而 Uber 的搞法是針對蘋果總部所在地點屏蔽這個功能:

So Mr. Kalanick told his engineers to “geofence” Apple’s headquarters in Cupertino, Calif., a way to digitally identify people reviewing Uber’s software in a specific location. Uber would then obfuscate its code for people within that geofenced area, essentially drawing a digital lasso around those it wanted to keep in the dark. Apple employees at its headquarters were unable to see Uber’s fingerprinting.

然後被蘋果工程師抓到,於是 Tim Cook 把人叫來喝咖啡:

The ruse did not last. Apple engineers outside of Cupertino caught on to Uber’s methods, prompting Mr. Cook to call Mr. Kalanick to his office.

另外提到了 Uber 從 Unroll.me 買來 Lyft 的帳單資料當作分析:

Using an email digest service it owns named Unroll.me, Slice collected its customers’ emailed Lyft receipts from their inboxes and sold the anonymized data to Uber. Uber used the data as a proxy for the health of Lyft’s business. (Lyft, too, operates a competitive intelligence team.)

而更精彩的在 Hacker News 上的這串爆了不少料,提到 Unroll 會把所有信件掃下來,丟到 S3 上面:

I worked for a company that nearly acquired unroll.me. At the time, which was over three years ago, they had kept a copy of every single email of yours that you sent or received while a part of their service. Those emails were kept in a series of poorly secured S3 buckets. A large part of Slice buying unroll.me was for access to those email archives. Specifically, they wanted to look for keyword trends and for receipts from online purchases.

The founders of unroll.me were pretty dishonest, which is a large part of why the company I worked for declined to purchase the company. As an example, one of the problems was how the founders had valued and then diluted equity shares that employees held. To make a long story short, there weren't any circumstances in which employees who held options or an equity stake would see any money.

I hope you weren't emailed any legal documents or passwords written in the clear.

而在 FAQ 的「If I delete my Unroll.Me account, what will happen to all of my previously rolled up emails?」裡則是說我們沒有存你的信件:

這爆米花要多買一些了...

在 F5 設備上使用 Let's Encrypt 憑證

找資料的時候翻到 F5 官方有給一篇導引,介紹如何自動化 Let's Encrypt 的憑證:「Lightboard Lessons: Automating SSL on BIG-IP with Let's Encrypt!」。

在 F5 的 GitHub 上也有一包「f5devcentral/lets-encrypt-python」可以看看。

還沒仔細看 & 測試,但大概有些輪廓了。看起來要考慮到裡面用的 letsencrypt.sh 已經改名成 dehydrated,另外就是實際測試了...

其實憑證貴的不是費用,是跑採購流程的成本... 單 domain 的如果可以用 Let's Encrypt 解決的話會可以省下不少功夫。

Netflix 的 BetterTLS,推廣 CA 的 Name Constraints

Netflix 因為想用 Name Constraints,所以決定自己跳出來推廣了:「BetterTLS - A Name Constraints test suite for HTTPS clients」。

就是在 CA 上可以綁定條件,只允許哪些 domain 可以被發放:

網站在「BetterTLS: Name Constraints」這邊可以看。

利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊

在「Netflix found to leak information on HTTPS-protected videos」這篇看到了研究員透過 VBR 所透露出的 side channel 資訊,成功的取得了被 HTTPS 保護的 Netflix 影片資訊。這對於美國的 ISP 是個大利多 (加上之前通過的法案),但對於個人隱私則是嚴重的打擊。

這項研究的準確率非常高:

To support our analysis, we created a fingerprint database comprised of 42,027 Netflix videos. Given this collection of fingerprints, we show that our system can differentiate between videos with greater than 99.99% accuracy. Moreover, when tested against 200 random 20-minute video streams, our system identified 99.5% of the videos with the majority of the identifications occurring less than two and a half minutes into the video stream.

而且他們居然是用這樣的單機分析:

null

苦啊...

關閉與開啟 Windows 10 內一堆侵犯與增強隱私的設定

DuckDuckGo 前陣子整理了一篇關於如何調整 Windows 10 的文章,洋洋灑灑列了十五條方式供使用者調整:「How To Protect Privacy On Windows 10」。

像是可以將無線網路的 MAC address 隨機化的方式就頗不錯:

然後有一堆要把資料送回 Microsoft 的...

Tor 在考慮使用 Rust 改寫

不過也不確定是不是愚人節消息就是了:「[tor-dev] Tor in a safer language: Network team update from Amsterdam」。

Tor 考慮使用 Rust 改寫,目前已經完成的部份,以及接下來的規劃:

What has already been done:
- Rust in Tor build
- Putting together environment setup instructions and a (very small) initial draft for coding standards
- Initial work to identify good candidates for migration (not tightly interdependent)

What we think are next steps:
- Define conventions for the API boundary between Rust and C
- Add a non-trivial Rust API and deploy with a flag to optionally use (to test support with a safe fallback)
- Learn from similar projects
- Add automated tooling for Rust, such as linting and testing

目前看到後續的討論只有「[tor-dev] Tor in a safer language: Network team update from Amsterdam」這篇,也許等全世界的 4/1 都過了之後再回來確認吧...

未來 CA 將會強制要求檢查 DNS CAA record

CA/Browser 通過提案,要求以後 CA 單位都要檢查 DNS CAA record 才能發放憑證 (RFC 6844 的「DNS Certification Authority Authorization (CAA) Resource Record」):「Ballot 187 - Make CAA Checking Mandatory」。

Certificate Authority Authorization (CAA) is a DNS Resource Record defined in RFC 6844 – https://datatracker.ietf.org/doc/rfc6844/ , published in January 2013. It allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain and, by implication, that no other CAs are authorized.

透過 DNS CAA 資料,你可以限制只有誰可以發你的憑證,直接用白名單做控管。

Heroku 支援自動化 Let's Encrypt 了

本來 Heroku 提供的 SSL certificate 是要收費的,現在則是提供 Let's Encrypt 的免費版本,而且提供自動更新 (不過必須是收費的 Dynos):「Announcing Free and Automated SSL Certs For All Paid Dynos」。

Heroku has always made it easy to add SSL encryption to web applications — today’s release of ACM extends that further to automatically generate a TLS certificate issued by Let’s Encrypt for your application’s custom domains.

細節的操作可以參考「Automated Certificate Management」這邊的說明。

OpenSSL 將轉為 Apache 2.0 License

OpenSSL 最近打算把原本的 license 換成 Apache License, Version 2.0:「Licensing Update」。

主要的原因是希望相容於現有大多數的 open source project:

OpenSSL Re-licensing to Apache License v. 2.0 To Encourage Broader Use with Other FOSS Projects and Products

但這非常詭異啊,舊的 license 最大的問題就是與 GPLv2 不相容,而預定要換的 AL 2.0 也還是不相容啊,搞屁啊。

檢查瀏覽器是否阻擋不安全的 SSL 連線

在這邊看到可以測試瀏覽器的 SSL 連線,網站在 https://badssl.com/dashboard/ 這邊:

Google Chrome 都有過,但是 Firefox 與 IE11 都還可以連 dh1024... (ouch)