幹壞事是進步最大的原動力
剛剛在「How to Android without Google」這邊的文章裡看到「How to Android without Google [easy way]」這篇指南，說明如何弄出一個沒有 Google 專屬套件的 Android 環境。
主要是 LineageOS 當作底層基礎 (作業系統)，然後用 microG 提供 API 相容層，並且用 F-Droid 安裝 Open Source 軟體。
裡面有兩個方案以前沒看過，一個是 XPosedFramework，提供框架讓使用者有更強的控制力，更完整的說明可以參考「Xposed Framework + App Settings 為每個 App 設定不同的運行模式」這篇。
另外一個是 Yalp Store，當軟體只在 Google Play 平台上提供安裝的時候，就需要透過這個套件了 XD
在 SSL Labs 上翻資料的時候發現看到台灣有些網站的 SSL 憑證在 Java Trust Store 內是不會取得信任授權的，但其他的都支援，像是這樣：
翻了幾個後發現都是 TWCA 的，在其他家都是這樣授權出來的 (Mozilla/Apple/Android/Windows)：(TWCA Root Certification Authority -> ) TWCA Global Root CA -> TWCA Secure SSL Certification Authority -> Final，也就是 TWCA 的兩個 Root CA 都在 trust store 內，走任何一條授權都可以拉出來。
印象中之前應該都是支援的... 先前是 cross sign 嗎？@_@
AWS 推出 AWS Secrets Manager，你可以把各種帳號密碼丟進去讓系統管理，另外內建 rotate 的功能，針對 AWS 支援的服務可以無縫更換密碼 (目前看起來是 RDS)，或是透過 Lambda 換：「AWS Secrets Manager: Store, Distribute, and Rotate Credentials Securely」。
是個整合性的服務，之前就可以做 (用 Lambda 定時跑)，現在則是包裝起來針對 AWS 自家的服務弄的更簡單。
收到標題是「Upcoming Changes to SSL Certificates in Amazon CloudWatch Logs」的信件，說明 Amazon CloudWatch Logs 要換 SSL Certificate 的 CA，看起來是要換成自家的：
We will be updating the certificate authority (CA) for the certificates used by Amazon CloudWatch Logs domain(s), between 8 January 2018 and 22 January 2018. After the updates complete, the SSL/TLS certificates used by Amazon CloudWatch Logs will be issued by Amazon Trust Services (ATS), the same certificate authority (CA) used by AWS Certificate Manager.
然後有提到 cross-sign 的部份，有透過 Starfield 的 Root CA 簽，所以只要下面有任何一個有在 Root CA store 裡面就應該會信任：
The update means that customers accessing AWS webpages via HTTPS (for example, the Amazon CloudWatch Console, customer portal, or homepage) or accessing Amazon CloudWatch Logs API endpoints, whether through browsers or programmatically, will need to update the trusted CA list on their client machines if they do not already support any of the following CAs:
- "Amazon Root CA 1"
- "Starfield Services Root Certificate Authority - G2"
- "Starfield Class 2 Certification Authority"
另外條列出有哪些 API endpoint 會改變：
This upgrade notice covers the following endpoints:
logs.ap-northeast-1.amazonaws.com
logs.ap-northeast-2.amazonaws.com
logs.ap-south-1.amazonaws.com
logs.ap-southeast-1.amazonaws.com
logs.ap-southeast-2.amazonaws.com
logs.ca-central-1.amazonaws.com
logs.eu-central-1.amazonaws.com
logs.eu-west-1.amazonaws.com
logs.eu-west-2.amazonaws.com
logs.eu-west-3.amazonaws.com
logs.us-east-1.amazonaws.com
logs.us-east-2.amazonaws.com
logs.us-west-1.amazonaws.com
logs.us-west-2.amazonaws.com
logs.sa-east-1.amazonaws.com
然後也列出了有哪些系統「應該」會支援：
* Operating Systems With ATS Support
- Microsoft Windows versions that have January 2005 or later updates installed, Windows Vista, Windows 7, Windows Server 2008, and newer versions
- Mac OS X 10.4 with Java for Mac OS X 10.4 Release 5, Mac OS X 10.5 and newer versions
- Red Hat Enterprise Linux 5 (March 2007), Linux 6, and Linux 7 and CentOS 5, CentOS 6, and CentOS 7
- Ubuntu 8.10
- Debian 5.0
- Amazon Linux (all versions)
- Java 1.4.2_12, Java 5 update 2, and all newer versions, including Java 6, Java 7, and Java 8
不過沒看到 Windows XP 耶，不知道是怎樣 XD
AWS CodeBuild 可以管理 secret 了：「AWS CodeBuild Now Provides Ability To Manage Secrets」。
AWS CodeBuild now further enhances securing your build environment. CodeBuild can now store sensitive information as secrets, which can now get directly passed to your build jobs. This can be achieved by modifying the parameter store directly in your buildspec.yml, or via the CodeBuild console.
在文件裡提到：
We strongly discourage using environment variables to store sensitive values, especially AWS access key IDs and secret access keys. Environment variables can be displayed in plain text using tools such as the AWS CodeBuild console and the AWS CLI. For sensitive values, we recommend you use the parameter-store mapping instead, as described later in this section.
這次算是補上其他家已經有蠻久的功能...
不過在找資料的時候，發現 AWS CodeBuild 提供了每個月一百分鐘的 free quota，不論是新帳號還是現有帳號都一直有？(這點是之前沒注意到的...)
The AWS CodeBuild free tier includes 100 build minutes of build.general1.small per month. The CodeBuild free tier does not expire automatically at the end of your 12-month AWS Free Tier term. It is available to new and existing AWS customers.
Dgraph 在推銷自家發展出來的 Badger：「Introducing Badger: A fast key-value store written natively in Go」。
標靶是 RocksDB，號稱比 RocksDB 快好幾倍：
Based on benchmarks, Badger is at least 3.5x faster than RocksDB when doing random reads. For value sizes between 128B to 16KB, data loading is 0.86x - 14x faster compared to RocksDB, with Badger gaining significant ground as value size increases. On the flip side, Badger is currently slower for range key-value iteration, but that has a lot of room for optimization.
不過我覺得有些重要的功能在 Badger 不提供，這比起來有種橘子比蘋果的感覺... 像是 RocksDB 提供了 Transaction，而 Badger 則是直接講明他們不打算支援 Transaction：
Keep it simple, stupid. No support for transactions, versioning or snapshots -- anything that can be done outside of the store should be done outside.
Amazon EBS 可以動態增加大小了，是個對不少人還蠻方便的功能：「Amazon Elastic Block Store (Amazon EBS) Enables Live Volume Modifications with Elastic Volumes」。
這邊講的沒有 downtime 當然還是得需要 filesystem 支援：
Today we are introducing the Elastic Volumes feature for Amazon Elastic Block Store (Amazon EBS). This new capability allows you to modify configurations of live volumes with a simple API call or a few console clicks. Elastic Volumes makes it easy to dynamically increase capacity, tune performance, and change the type of any new or existing current generation volume with no downtime or performance impact.
另外提到一個特殊的組合，是配合 CloudWatch 與 Lambda 調整：
You can streamline and automate changes using Amazon CloudWatch with AWS Lambda.
這方法頗有趣的 XDDD
在「Intern Impact: Brotli compression for Play Store app downloads」這邊介紹了 Google Play Store 引入 Brotli 的情況。
選擇 Brotli 除了是 Google 自家研發出來的東西以外，另外是考量到 Brotli 的壓縮與解壓縮速 (尤其是後者) 不會增加太多，卻可以多出不少壓縮率。維基百科這邊說明的是文字的部份：
Replacing deflate with brotli typically gives an increase of 20% in compression density for text files, while compression and decompression speeds are roughly unchanged.
不過實際在 Google Play Store 上測試 binary 的效果也不錯：
當然，如同之前提到的「Google 再次改善 Android 的 APK 更新，讓下載的量更小」，在去年 12 月時 Google 對於背景更新的下載 File-by-File 的更新來降低流量 (但在手機上會需要大量的 CPU 資源計算，不過因為是背景 idle 時跑而不會影響使用者，所以被採用)，透過這兩個改善互相搭配繼續壓低流量。
在接下來的幾個禮拜會生效：
Brotli compression for app downloads is rolling out now, and users should start to enjoy the benefits over the coming weeks.
之前提到的「阻擋廣告的攻性防壁 AdNauseam」沒什麼意外被 Google 擋掉了：「AdNauseam banned from the Google Web Store」。
Earlier this week, on Jan 1st 2017, we were informed by our users that Google had banned AdNauseam from its Chrome Web Store.
現在變成要手動下載安裝：「Install AdNauseam on Chrome Without Google's Permission」。
Mozilla 對 WoSign + StartCom 的不信任處分出爐了：「Distrusting New WoSign and StartCom Certificates」，最後處分的內容跟之前的討論差不多 (參考先前寫的「Mozilla 對於 WoSign + StartCom 根憑證的新發展：拔除」)。
Mozilla 台灣有放出中文版的說明 (差不多就是英文翻譯的版本)：「取消對 WoSign 與 StartCom 新簽發憑證的信任」。
這次比較麻煩的地方在於要信任已經發出的 certificate，而且量太大無法窮舉。所以必須改增加程式碼處理，而這個方法無法對使用 Mozilla CA Certificate Store 的人生效 (因為這包套件只是一堆 pem 檔案，沒辦法放特殊的邏輯進去...)
另外現在 Firefox 是 49 版，要到 51 版才會生效，看起來還會花一陣子...