Tag: in

南韓對 Apple 與 Google 的 In-App 付款機制的提案

在 WSJ 上看到南韓對 Apple 與 Google 的 in-app 付款機制提案，強制 Apple 與 Google 讓 app 的開發者 (或是開發商) 使用第三方支付平台：「Google, Apple Hit by First Law Threatening Dominance Over App-Store Payments」。

看不到 WSJ 內文的可以看「Apple and Google must allow developers to use other payment systems, new Korean law declares」這篇，裡面有引用韓國的媒體報導 (英文版)：「S. Korea looks set for legislation to curb Google, Apple's in-app billing system」。

要注意這還沒有通過，目前過委員會而已 (parliamentary committee)，接下來要表決才會成為正式法律。

先前美國亞利桑那州的法案被擋下來，然後參議院提的法案也還在進行中，看起來還有很硬的仗要打：「由美國參議院提出的 Open App Markets Act」。

先繼續等後續發展，可以想見 Apple 與 Google 一定會想辦法抵制...

Mitmproxy 7 支援 TLS over TCP 的分析了

在 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 安裝的話)

Amazon SNS 也支援 FIFO 模式了

看到 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 推出了 Hermes，為了 React Native 而生的 JS Engine

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

Amazon Aurora for MySQL 支援 Point-in-Time Recovery 了

繼四月出 DynamoDB 推出的 PITR 後 (參考「Amazon DynamoDB 的 Point-In-Time Recovery」這篇)，Amazon Aurora for MySQL 也宣佈支援 PITR 了：「Amazon Aurora Backtrack – Turn Back Time」。

從截圖可以看到支援到秒層級：

然後最多 72 小時，會有額外費用：

這樣又讓 DBA 少了一些事情 XD

Amazon DynamoDB 的 Point-In-Time Recovery

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.

比對一下，應該是巴黎與美國政府用的區域沒進去... 一個是去年年底開幕的區域，另一個是本來上新功能就偏慢的區域。

重設密碼 + Social Engineering

在「The password reset MitM attack」這邊看到 PRMitM (Password Reset Man-in-the-Middle) 這樣的攻擊，原始論文在「The Password Reset MitM Attack」這邊可以取得。

用圖說明基本版的攻擊方式：

另外列出了各大站台的狀態：

以及各家簡訊的文字，可以發現不是每一家都有把產品的名稱寫上去：

這方法好有趣啊... XD

V8 對 for-in 的最佳化

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.