January 2019 – Gea-Suan Lin's BLOG

Google 也透過同樣機制蒐集使用者的行為

Update：Google 的憑證也被 revoke 了，另外 Facebook 的恢復內部使用的部分了：「Apple blocks Google from running its internal iOS apps」。

昨天是 Facebook 被發現在 iOS 上使用 Enterprise Certificate 取得使用者的行為記錄 (參考「Facebook 花錢向使用者購買他們的行為記錄」)，後來 Apple 撤銷了這張 Enterprise Certificate (因為不符合 Enterprise Certificate 的使用條款)，並且使得 Facebook 內部符合 Enterprise Certificate 的應用程式都失效。

而 Google 也被抓出幹同樣的事情，叫做 Screenwise Meter：「Google will stop peddling a data collector through Apple’s back door」。

目前 Google 自己已經下架，但這表示已經有的 spyware 還是會生效，就看 Apple 要不要拔了...

Facebook 花錢向使用者購買他們的行為記錄

這則從 Nuzzel 上看到的，國外討論得很凶：「Facebook pays teens to install VPN that spies on them」。

Facebook 付錢給使用者，要他們安裝 VPN (以及 Root CA，看起來是為了聽 HTTPS 內容)，然後從上面蒐集資料，這本身就不是什麼好聽的行為了，但更嚴重的問題在於包括了未成年人：

Since 2016, Facebook has been paying users ages 13 to 35 up to $20 per month plus referral fees to sell their privacy by installing the iOS or Android “Facebook Research” app. Facebook even asked users to screenshot their Amazon order history page. The program is administered through beta testing services Applause, BetaBound and uTest to cloak Facebook’s involvement, and is referred to in some documentation as “Project Atlas” — a fitting name for Facebook’s effort to map new trends and rivals around the globe.

這個計畫在 iOS 平台下架了，但 Android 平台看起來還是會繼續：

[Update 11:20pm PT: Facebook now tells TechCrunch it will shut down the iOS version of its Research app in the wake of our report. The rest of this article has been updated to reflect this development.]

Facebook’s Research program will continue to run on Android. We’re still awaiting comment from Apple on whether Facebook officially violated its policy and if it asked Facebook to stop the program. As was the case with Facebook removing Onavo Protect from the App Store last year, Facebook may have been privately told by Apple to voluntarily remove it.

未成年人部份應該會是重點，拉板凳出來看...

Kubernetes 的失敗案例

有人把 Kubernetes (通常縮寫成「K8S」) 的失敗案例 (轉移失敗、爛掉、...) 整理到 GitHub 上：「Kubernetes Failure Stories」，裡面有文章也有演講影片，然後也有重複的公司在不同時間點說明。

先來講 K8S 好了，如果要粗略的解釋 K8S 是什麼東西，我會說就像是架一組 AWS 服務起來，但是是基於 container 而非 VM。

拿 AWS 的詞彙來說，他在上面疊了一層 Amazon VPC (會對應到 Kubernetes 的 overlay network 與 CNI)，然後也提供 AMI (透過 Docker Image) 與 EC2 (因為是比喻，這邊就拿 AMI + EC2 來對比)，還有基本的 ELB (各種 NodePort、HostPort 與 Ingress) 與 Service Discovery。

比較特別的是 Pod 的概念，在一般的雲上不太會看到。

不過大致上你可以想像這是一個小型的 AWS，而試著去猜測管理一個小型的 AWS 會需要了解多少底層知識，加上 K8S 一直在發展，很多功能可能都還不成熟 (所以用起來會覺得設計很奇怪)，然後上面整理出的失敗案例就不意外了... XD

如果你是自己有機房，或是用便宜的 VPS (像是 Linode、DigitalOcean、Vultr)，那麼我覺得在上面堆 K8S cluster 還算合理，畢竟你可以透過 K8S 幫你整合不少以前得自己架設的服務。

但如果你是已經在 Cloud 上面，然後還想在上面跑 K8S cluster，我是覺得還是要有個理由 (不管是技術上或是政治上的)。如果只是因為 K8S 潮到出水而用的話，可能過一個月後你家就淹水了 XD

另外講一些題外話，因為最近弄 Kubernetes 的關係 (可以參考我的筆記「Kubernetes」)，才能理解為什麼 Linode 這些 VPS 會推出 load balancer 與 block storage，算是後知後覺...

HiNet 對於 DNS flag day 的公告

先前提到了各大 Public DNS 服務將會在二月正式關閉對 EDNS 的 workaround，也就是 DNS flag day：「從二月開始不回應 EDNS 的 DNS server 將會無法查詢」，而 HiNet 也發出對應的公告了：「(DNS flag day) 部分Public DNS業者將於2019年2月1日執行EDNS符合性驗證」。

說明：一、因應部分Public DNS服務(如Cloudflare 1.1.1.1、Google 8.8.8.8、IBM 9.9.9.9等)將於2019年2月1日執行EDNS符合性驗證(Extension mechanisms for DNS, DNS延伸機制)，屆時如不支援EDNS協定之域名將造成Public DNS無法順利解析或解析反應變慢。 ( 參閱TWNIC 2019-01-23最新消息 https://blog.twnic.net.tw/2019/01/23/2286/ ) 二、使用HiNet DNS服務(168.95.1.1與168.95.192.1)及HiNet代管DNS服務，皆可正常解析不受影響。三、若使用上述Public DNS服務，發生有部分域名無法解析情況，可改使用HiNet DNS服務，即可恢復正常解析。

一方面說明他們有處理他們自己的 DNS hosting，另外一方面順便推廣一下自家本來的 168.95.1.1 與 168.95.192.1，但目前沒打算拿掉 DNS flag day 的 workaround XDDD

保護 Linux 的檢查清單...

在 trimstray/the-practical-linux-hardening-guide 這邊看到保護 Linux 系統的方式，列成清單：

This guide details the planning and the tools involved in creating a secure Linux production systems - work in progress.

從實體的開始講，然後 BIOS，再來是 OS 層，接下來是基本服務，再來到應用程式，一般人做的到的該涵蓋的都有涵蓋到了...

不過在一般情況下要全部都完成不太可能 (通常是人太懶)，但可以當清單掃一輪挑著做，加強系統的安全性...

B612 字型

B 612 是小王子裡的星球，被拿來引用當作字型名稱了：「B612 – The font family」。

這是空中巴士設計給飛機上的系統用的，所以包括了「舒服」(長時間) 與「易讀」，算是某種以「安全」為考量的字體？

In 2010, Airbus initiated a research collaboration with ENAC and Université de Toulouse III on a prospective study to define and validate an “Aeronautical Font”: the challenge was to improve the display of information on the cockpit screens, in particular in terms of legibility and comfort of reading, and to optimize the overall homogeneity of the cockpit.

然後包括了 regular 與 monospace 兩種：

看 Git 的記錄已經 open source 一陣子了，拿來當 sans-serif 用一段時間看看好了...

apt-get 的安全性漏洞

前幾天寫的「APT 不使用 HTTPS 的說明」的當下就已經有看到在講這個漏洞，但沒讀完就一直放著沒寫：「Remote Code Execution in apt/apt-get」。

漏洞出在實作上的問題，對於 HTTP 重導的程式碼沒有處理好外部字串，在還沒修正的機器上用這個指令關閉 redirect，避免在修正的過程反而被 RCE 打進去：

sudo apt update -o Acquire::http::AllowRedirect=false
sudo apt upgrade -o Acquire::http::AllowRedirect=false

但也不是 HTTPS 就能避免這個問題，因為 HTTPS 連線用的程式碼又是另外一份，裡面不知道有沒有問題 (像是之前經典的 Heartbleed)，所以應該還是會繼續爭吵吧...

TiDB 單機效能

TiDB 是一個支援分散式運算的資料庫，希望能夠完整地模擬 MySQL Protocol，而 Percona 試著測試 TiDB 在單機的效能，雖然測試的項目很簡單，但結果頗有趣的：「A Quick Look into TiDB Performance on a Single Server」。

Percona 觀察到的現象是 TiDB 對於單一 SQL query 支援多 CPU 運算 (MySQL 只會使用單 CPU)，所以在高階的機器上，某些 SQL query 會快很多。而 OLAP 類型的 SQL query 也不錯，但常見的 OLTP 應用則慢不少：

Short version: TiDB supports parallel query execution for selects and can utilize many more CPU cores – MySQL is limited to a single CPU core for a single select query. For the higher-end hardware – ec2 instances in my case – TiDB can be 3-4 times faster for complex select queries (OLAP workload) which do not use, or benefit from, indexes. At the same time point selects and writes, especially inserts, can be 5x-10x slower. Again, please note that this test was on a single server, with a single TiKV process.

是個有趣的 drop-in...

NLB 也可以幫忙處理 TLS 了...

AWS 推出的新功能，讓 NLB (network load balancer) 可以直接做完 SSL offload：「New – TLS Termination for Network Load Balancers」。

而且 NLB 可以保留 source ip，不需要在 web server 上處理特殊的 header (像是 X-Forwarded-For 這類的 HTTP header)。這點倒是頗有趣...