幹壞事是進步最大的原動力
OpenSSL 的文章「Using TLS1.3 With OpenSSL」提到了：
The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3.
另外也提到了 TLS 1.3 的標準是 blocker，在 TLS 1.3 沒出來前不會出 OpenSSL 1.1.1：
OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised.
OpenSSL 實做的 TLS 1.3 支援了這些 cipher：
GCM 的部份不算意外，比較特別的是包括了 ChaCha20 與 Poly1305 (喊很久了)，另外包括了 CCM mode 的實做...
瀏覽器的 headless 模式讓開發者可以透過 command line 或是 API 界面操作，對於自動化開發測試很有用。而 Google Chrome 將在 59 版 (目前 57 版) 引入 headless 模式：「Headless mode」。
Headless mode allows running Chromium in a headless/server environment. Expected use cases include loading web pages, extracting metadata (e.g., the DOM) and generating bitmaps from page contents -- using all the modern web platform features provided by Chromium and Blink.
To use headless, start Chrome with a command line flag:
$ chrome --headless --remote-debugging-port=9222 https://chromium.org
而 PhantomJS 則是因為 Google Chrome 決定要支援 headless 模式，主要的貢獻者 Vitaly Slobodin (參考 Contributors to ariya/phantomjs 這邊) 決定退出維護：「[Announcement] Stepping down as maintainer」。
是個功成身退的感覺...
A text editor that only allows the 1,000 most common words in English
限制你使用比較簡單的英文，這樣可以讓讀的人比較容易了解 (尤其是非母語的人)。
有種跟 Simple English Wikipedia 的想法很像的感覺：
The project uses around 2,000 common English words, and is based on Basic English, an 850-word auxiliary international language created by Charles Kay Ogden in the 1920s.
另外還有提供 Trump mode XDDD：
Trained with a few of Trump's best known speeches, the app is now ready to help you write like a billionaire.
這好壞 XDDD
Google 決定加倍對 Chromebook 訪客模式下攻陷系統的獎金：「After 0 successful submissions, Google doubles top reward for hacking a Chromebook to $100,000」。
原先是五萬美金：
Last year, Google introduced a $50,000 reward for the persistent compromise of a Chromebook in guest mode. The company’s security team says it hasn’t received a single successful submission.
提升到十萬美金：
As such, Google has doubled the bounty, which was already the top Chrome reward, to $100,000. The company really wants someone to hack Chrome OS to pieces. “That said, great research deserves great awards, so we’re putting up a standing six-figure sum, available all year round with no quotas and no maximum reward pool,” Google declared.
有人發現他的 Gmail 進入了 Debug Mode：「Someone left my Gmail in debug mode」。
原文可以看到很多截圖，看起來像是 debug console 給內部找問題用的東西？
Debug 模式會比一般的模式來的慢，但可以看到更多資訊。以往的問題是 5xx 難以重製，而 NGINX 的「Capturing 5xx Errors with a Debug Server」這篇文章介紹了如何用 nginx 實作標題的功能。
如果是隨機造成的問題就沒辦法重製，但如果是 client 的狀態造成的問題，就很有可能可以抓出來... 不是解決所有問題，但可以幫助解掉以前不太好解的狀況。
Amazon 之前放 s2n 出來當作 TLS protocol 的方案，於是就有人摸出東西來：「Lucky Microseconds: A Timing Attack on Amazon's s2n Implementation of TLS」。
即使是經過外部資安檢證，仍然還是有找到問題。這次找到的問題是 timing attack 類在 CBC-mode 下的 plaintext recovery：
At the time of its release, Amazon announced that s2n had undergone three external security evaluations and penetration tests. We show that, despite this, s2n - as initially released - was vulnerable to a timing attack in the case of CBC-mode ciphersuites, which could be extended to complete plaintext recovery in some settings.
攻擊分成兩個階段：
Our attack has two components. The first part is a novel variant of the Lucky 13 attack that works even though protections against Lucky 13 were implemented in s2n. The second part deals with the randomised delays that were put in place in s2n as an additional countermeasure to Lucky 13. Our work highlights the challenges of protecting implementations against sophisticated timing attacks.
最後還是酸了一下 Amazon：
It also illustrates that standard code audits are insufficient to uncover all cryptographic attack vectors.
Amazon 的官方說明則在「s2n and Lucky 13」這邊可以看到。
Percona 老大 Peter Zaitsev 寫了一篇關於 InnoDB 的 isolation mode 與效能的關係：「MySQL performance implications of InnoDB isolation modes」。
關於 isolation level 的介紹，也可以參考維基百科上的說明：「Isolation (database systems)」。
其中有個我也認同的的建議：
In general I think good practice is to use READ COMITTED isolation mode as default and change to REPEATABLE READ for those applications or transactions which require it.
需要 REPEATABLE READ 需求的 transaction 可以在 session 裡面開，不需要平常就開著。
而剛從 MyISAM 轉過去的因為本來就沒有 transaction，換到 InnoDB 時強烈建議就直接設上去 (剛好在註解也有提到)：
I think READ-COMMITTED is better default yet it can break some applications. Though so changing to default storage engine from MyISAM to Innodb did.
在 Percona 的「How to deal with MySQL deadlocks」這篇文章裡面提到了 MySQL InnoDB Deadlock 的判讀與處理。
在支援 transaction 的 engine 裡 deadlock 是不可避免的常態。
在 MySQL 5.5 以及之前的版本，可以透過 Percona 的 pt-deadlock-logger 這隻 script，每固定幾秒鐘就跑一次 SHOW ENGINE INNODB STATUS 記錄下來。在 MySQL 5.6 之後，可以直接使用 innodb_print_all_deadlocks 這個參數，遇到 deadlock 時就寫到 error log 裡。
有了 log 後，接下來就可以判讀 deadlock 的情況，得知是什麼樣的情況造成 deadlock。
文章最後面則是對減少 deadlock 的方法給了一些建議，都是比較一般性。一般還是要靠 bussiness logic 的分析來切割降低 deadlock 的情況。
不過這篇文章需要一些背景知識，像是 InnoDB Lock Modes 與維基百科上的「Multiple granularity locking」，對解讀會有更多幫助。