另外一個蠻重要的應該是 microG Project，不過在文章裡沒提到...
The Register 發表了「Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign」這篇文章，算是頗完整的說明了這次的安全漏洞 (以 IT 新聞媒體標準來看)，引用了蠻多資料並且試著說明問題。
在 Google Project Zero 的文章裡面，把這些漏洞分成三類，剛好依據 CVE 編號分開描述：
- Variant 1: bounds check bypass (CVE-2017-5753)
- Variant 2: branch target injection (CVE-2017-5715)
- Variant 3: rogue data cache load (CVE-2017-5754)
(提到 Variant 1 的情況) If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU.
KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.
KAISER 後來改名為 KPTI，查資料的時候可以注意一下。
不過上面提到的是實體機器，在 VM 裡面可以預期會有更多 syscall 與 context switch，於是 Phoronix 測試後發現在 VM 裡效能的損失比實體機器大很多 (還是跟應用有關，主要看應用會產生多少 syscall 與 context switch)：「VM Performance Showing Mixed Impact With Linux 4.15 KPTI Patches」。
With these VM results so far it's still a far cry from the "30%" performance hit that's been hyped up by some of the Windows publications, etc. It's still highly dependent upon the particular workload and system how much performance may be potentially lost when enabling page table isolation within the kernel.
這對各家 cloud service 不是什麼好消息，如果效能損失這麼大，不太可能直接硬上 KPTI patch... 尤其是 VPS，對於平常就會 oversubscription 的前提下，KPTI 不像是可行的方案。
現在可以預期會有更多人投入研究，要怎麼樣用比較少的 performance penalty 來抵抗這兩套漏洞，現在也只能先等了...
This package ensures that your application doesn't have installed dependencies with known security vulnerabilities.
看一下 composer.json 就知道作法了，裡面的
Prevents installation of composer packages with known security vulnerabilities: no API, simply require it
這次的事情是 microG 的人 fork 了 LineageOS 專案，因為 LineageOS 專案拒絕 microG 的 signature spoofing patch：
Why do we need a custom build of LineageOS to have microG? Can't I install microG on the official LineageOS?
MicroG requires a patch called "signature spoofing", which allows the microG's apps to spoof themselves as Google Apps. LineageOS' developers refused (multiple times) to include the patch, forcing us to fork their project.
Wait, on their FAQ page I see that they don't want to include the patch for security reasons. Is this ROM unsafe?
No. LineageOS' developers hide behind the "security reasons" shield, but in reality they don't care enough about the freedom of their users to risk to upset Google by giving them an alternative to the Play Services.
The signature spoofing could be an unsafe feature only if the user blindly gives any permission to any app, as this permission can't be obtained automatically by the apps.
Moreover, to further strengthen the security of our ROM, we modified the signature spoofing permission so that only system privileged apps can obtain it, and no security threat is posed to our users.
於是就 fork 了新的專案... 就觀察看看吧。
Thanks to their support, we are now collaborating with AT&T to deliver emergency internet service to the hardest hit parts of the island.
接下來應該還會有不少數字丟出來... (像是透過 Project Loon 傳輸了多少資料，或是多少分鐘的語音通話)
這次波多黎各災後已經好幾個禮拜了，但還是有大量的基地台還是不通。於是 Project Loon 從 FCC 得到實驗性的執照，建立行動網路：「Alphabet’s Internet balloons will try to restore cell service in Puerto Rico」。
Nearly 82 percent of cell sites in Puerto Rico and 57 percent in the US Virgin Islands are out of service, the FCC said in its daily damage report yesterday. In nearly all counties in Puerto Rico, more than 75 percent of cell sites are not working, and "22 out of the 78 counties in Puerto Rico have 100 percent of their cell sites out of service." Large percentages of residents are also without cable or wireline service.
在 FCC 的公告裡提到授權了 900Mhz 頻段：「FCC GRANTS EXPERIMENTAL LICENSE FOR PROJECT LOON TO OPERATE IN PUERTO RICO」(PDF 檔但是標題是「Microsoft Word」...)。
Project Loon obtained consent agreements to use land mobile radio (LMR) radio spectrum in the 900 MHz band from existing carriers operating within Puerto Rico.
不過由於要讓使用者可以使用現有的 SIM 卡連上網，需要當地電信業者的合作，Google 目前還沒完全確認：
Alphabet hasn't announced a schedule for providing service in Puerto Rico, and the company says it is still determining whether it will be able to help.
Project Loon must be integrated with the network of a cellular company in order to provide service, and Alphabet is “making solid progress on this next step," the spokesperson said. Project Loon is part of Alphabet's X division, formerly known as "Google X."
首先是 Firefox 自己的數據分析，可以看到 AES-GCM 佔目前加密連線裡的大宗，再來是 AES-CBC：
在 Linux 32bits 環境上則是連預設值大幅改善，不過用的人應該少很多了：
Windows 下則是因為 64bits 或是 32bits 都有足夠的使用者，所以平常就花了不少力氣。但也可以看出對於老電腦的速度提升：
Mac (64bits only) 算是這次比較大的提升，連新電腦的預設值都大幅變快：
加上之後陸續的改善 (尤其是下一版 Firefox 57 的 Project Quantum)，這幾版應該會拉出不少效能...
不過也不確定是不是愚人節消息就是了：「[tor-dev] Tor in a safer language: Network team update from Amsterdam」。
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 都過了之後再回來確認吧...
This allows its employees to use company equipment to work on personal projects in their free time, which can occur during work hours, without fear of being sued for the IP. As long as the work isn’t related to GitHub’s own “existing or prospective” products and services, the employee owns it.
可以看得出來是挑比較大的來改，而下一版的 Google Chrome (57) 將會對
The most important for-in helpers are at position 5 and 17, accounting for an average of 0.7% percent of the total time spent in scripting on a website. In Chrome 57 ForInEnumerate has dropped to 0.2% of the total time and ForInFilter is below the measuring threshold due to a fast path written in assembler.
主要是因為 spec 對
When we look at the spec-text of for-in, it’s written in an unexpectedly fuzzy way,which is observable across different implementations.