幹壞事是進步最大的原動力
在 Hacker News 首頁上看到 Mitmproxy 7 的消息：「Mitmproxy 7」。
比較重要的功能應該就是可以針對任意的 TLS 連線攔截分析了：
不過像是 STARTTLS 這類先在 plaintext 溝通，然後送出指令進入 TLS 的方式，目前就還沒支援：
Opportunistic TLS (STARTTLS) is not supported yet, but regular TCP-over-TLS just works!
另外是可以分析 WebSocket 內的傳輸資料：
應該是跑個 pip install -U mitmproxy 就可以升級了... (如果先前是用 pip 安裝的話)
在 Hacker News Daily 上看到「Safari tries to fill username」這個 Safari 的 "feature"。
作者發現網站在 Safari 上會出現登入的提示功能，像是這樣：
本來以為是 bug，但實際測過後看起來像是 feature，但抓字串的方法很容易誤判，看起來是抓 welcome back 這組字串：
On further consideration I don't think it's a bug. I think Safari is assuming any page with "Welcome Back" on it is a login page and enabling this behaviour. Therefore I think it's intended.
然後作者也有找到 workaround，用 去閃偵測：
Nice one. I found that using a non-breaking space prevents the behaviour.
>p>welcome back</p>
其他人也有發現其他的字串也會中獎：
It seems the same applies to "Sign In"
"Log in" works too. I tried a couple other languages (Finnish, German, French, Chinese) but the issue/feature seems to only happen with English (although I did use Google Translate, so I can't guarantee I used the right idioms).
目前看起來遇到就只能先 workaround 了...
看到 Amazon SNS 也支援 FIFO 模式了：「Introducing Amazon SNS FIFO – First-In-First-Out Pub/Sub Messaging」。
Amazon SQS 在 2016 年就已經先支援了：「Amazon SQS 支援 FIFO 了」，官方的文件可以在「Amazon SQS FIFO (First-In-First-Out) queues」這邊翻到。
在使用 FIFO mode 時與 SQS 有一樣的速度限制，每個 topic 只能到 300 TPS：
You can use SNS FIFO topics in all commercial regions. You can process up to 300 transactions per second (TPS) per FIFO topic or FIFO queue. With SNS, you pay only for what you use, you can find more information in the pricing page.
不過之前有需要保持順序的應用應該都先用 SQS workaround 了，不然就是自己搞能夠 FIFO 的 pub/sub 架構了。
Facebook 提供了一個對 React Native 最佳化的 JS engine：「Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native」。
裡面有提到兩個比較重要的的部份是 No JIT 與 Garbage collector strategy，針對行動裝置的特性而設計：避免 JIT 產生的 overhead，以及降低記憶體使用量。
官方給的改善主要也都是偏這兩塊：
不過沒有提到 CPU usage 會上升多少，只是帶過去：
Notably, our primary metrics are relatively insensitive to the engine’s CPU usage when executing JavaScript code.
對於 Facebook 也許是可以接受的數量，但對於其他人就沒概念了... 要入坑的人自己衡量這部份的風險 XD
繼四月出 DynamoDB 推出的 PITR 後 (參考「Amazon DynamoDB 的 Point-In-Time Recovery」這篇)，Amazon Aurora for MySQL 也宣佈支援 PITR 了：「Amazon Aurora Backtrack – Turn Back Time」。
從截圖可以看到支援到秒層級：
然後最多 72 小時，會有額外費用：
這樣又讓 DBA 少了一些事情 XD
Amazon DynamoDB 在 3/26 發出來的功能，以秒為單位的備份與還原機制：「New – Amazon DynamoDB Continuous Backups and Point-In-Time Recovery (PITR)」。
先打開這個功能：
打開後就會開始記錄，最多可以還原 35 天內的任何一個時間點的資料：
DynamoDB can back up your data with per-second granularity and restore to any single second from the time PITR was enabled up to the prior 35 days.
這時候就算改變資料或是刪除資料，實際上在系統內都是 Copy-on-write 操作，所以需要另外的空間，這部份會另外計價：
Pricing for continuous backups is detailed on the DynamoDB Pricing Pages. Pricing varies by region and is based on the current size of the table and indexes. For example, in US East (N. Virginia) you pay $0.20 per GB based on the size of the data and all local secondary indexes.
有這樣的功能通常是一開始設計時就有考慮 (讓底層的資料結構可以很方便的達成這樣的效果)，現在只是把功能實作出來... 像 MySQL 之類的軟體就沒辦法弄成這樣 XDDD
最後有提到支援的地區，是用條列的而不是說所有有 Amazon DynamoDB 的區域都支援：
PITR is available in the US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), EU (Frankfurt), EU (Ireland), EU (London), and South America (Sao Paulo) Regions starting today.
比對一下，應該是巴黎與美國政府用的區域沒進去... 一個是去年年底開幕的區域，另一個是本來上新功能就偏慢的區域。
在 Twitter 上看到他們自家更新了 2FA 的機制，除了本來的 in-app verification 外，也提供常見的 HOTP 了：(掃 QR code，然後會產生六碼數字的那種)
We’re rolling out an update to login verification.
You’ll now be able to use a third party app for two-factor authentication instead of SMS text messages.https://t.co/UXl3xKLEaG
— Twitter Safety (@TwitterSafety) December 20, 2017
在上面的「How to use login verification」連結可以看到 HOTP 的設定方式：
還是可以選擇本來的方式以及簡訊，現在則是多了個選擇...
在「The password reset MitM attack」這邊看到 PRMitM (Password Reset Man-in-the-Middle) 這樣的攻擊，原始論文在「The Password Reset MitM Attack」這邊可以取得。
用圖說明基本版的攻擊方式：
另外列出了各大站台的狀態：
以及各家簡訊的文字，可以發現不是每一家都有把產品的名稱寫上去：
這方法好有趣啊... XD
V8 引擎的人對 for-in 的最佳化寫了一篇解釋「Fast For-In in V8」，比較直接的結果就是維基百科與 Facebook 都變快了：
For example, in early 2016 Facebook spent roughly 7% of its total JavaScript time during startup in the implementation of for-in itself. On Wikipedia this number was even higher at around 8%.
可以看得出來是挑比較大的來改，而下一版的 Google Chrome (57) 將會對 for-in 會到另外一個極致：
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 對 for-in 的定義寫得很模糊，所以就有很多實作的空間可以調整：
When we look at the spec-text of for-in, it’s written in an unexpectedly fuzzy way,which is observable across different implementations.
Amazon SQS 支援 FIFO 了：「FIFO (First-In-First-Out) Queues」。新的 FIFO Queue 有保證順序，但也因此效能上有限制：
In addition to having all the capabilities of the standard queue, FIFO (First-In-First-Out) queues are designed to enhance messaging between applications when the order of operations and events is critical, or where duplicates can't be tolerated. FIFO queues also provide exactly-once processing but are limited to 300 transactions per second (TPS).
可以看到舊版的 FAQ 對於 FIFO 的回答是 Standard Queue 會盡力做到 FIFO，但不保證：(出自 2016/08/26 的版本)
Q: Does Amazon SQS provide first-in-first-out (FIFO) access to messages?
Amazon SQS provides a loose-FIFO capability that attempts to preserve the order of messages. However, we have designed Amazon SQS to be massively scalable using a distributed architecture. Thus, we can't guarantee that you will always receive messages in the exact order you sent them (FIFO).
If your system requires the order of messages to be preserved, place sequencing information in each message so that messages can be ordered when they are received.
而現在則是名正言順的說有提供 FIFO 了：
Q: Does Amazon SQS provide message ordering?
Yes. FIFO (first-in-first-out) queues preserve the exact order in which messages are sent and received. If you use a FIFO queue, you don't have to place sequencing information in your messages. For more information, see FIFO Queue Logic in the Amazon SQS Developer Guide.
Standard queues provide a loose-FIFO capability that attempts to preserve the order of messages. However, because standard queues are designed to be massively scalable using a highly distributed architecture, receiving messages in the exact order they are sent is not guaranteed.