幹壞事是進步最大的原動力
看到 Amazon CloudFront 宣佈在東京開到第八個點了：「Amazon CloudFront launches eighth Edge location in Tokyo, Japan」。
Amazon CloudFront announces the addition of an eighth Edge location in Tokyo, Japan. The addition of another Edge location continues to expand CloudFront's capacity in the region, allowing us to serve increased volumes of web traffic.
這個成長速度有點驚人，一月才加了兩個，現在又要再加一個... 不過大阪還是維持一個。
在朋友的 tweet 裡看到微軟啟用自己的 Azure CDN 了，先前應該是提供 Akamai 與 EdgeCast 的服務：「Announcing Microsoft's own Content Delivery Network」。
看圖似乎是有台灣的點，不過我找不到可以測試 traceroute 的 endpoint，頁面上用的圖還是 EdgeCast 的啊 XDDD
;; ANSWER SECTION: azurecomcdn.azureedge.net. 1604 IN CNAME azurecomcdn.ec.azureedge.net. azurecomcdn.ec.azureedge.net. 3404 IN CNAME cs9.wpc.v0cdn.net. cs9.wpc.v0cdn.net. 3404 IN A 117.18.232.200
然後公測期間優惠價 50%：
Azure Content Delivery Network Standard from Verizon (S1) and Akamai (S2) and Microsoft (S3)*
*S3 is currently in public preview. CDN rates will be 50% of the stated price during this period.
看到有人實做 Seam Carving (接縫裁剪) 了，用 Golang 寫的，放在 GitHub 的 esimov/caire 這邊，副標題「Content aware image resize library」。實做了「Seam Carving for Content-Aware Image Resizing」這篇論文。
Seam Carving 指的是知道內容的 resize，像是把上面這張變成下面這張：
或是變大：
馬上可以想到的應用是需要保留資訊內容，但又想要大量提供資訊的地方，像是 Nuzzle 的縮圖 (或是以前的 Zite)，或是網路新聞媒體的首頁所用的縮圖。不知道還有沒有其他地方可以用...
我第一眼看到的時候還在想是哪個 content farm 的標題，我應該沒有訂到 content farm 的 RSS feed 才對... 結果發現是 Google Cloud Platform 上的文章：「12 best practices for user account, authorization and password management」。
然後看完內容後還是有種 content farm 的感覺... (歡樂)
Amazon API Gateway 支援壓縮了：「Amazon API Gateway Supports Content Encoding for API Responses」。
You can now enable content encoding support for API Responses in Amazon API Gateway. Content encoding allows API clients to request content to be compressed before being sent back in the response to an API request. This reduces the amount of data that is sent from API Gateway to API clients and decreases the time it takes to transfer the data. You can enable content encoding in the API definition. You can also set the minimum response size that triggers compression. By default, APIs do not have content encoding support enabled.
打開後傳回的資料就會自動壓縮了，然後還可以設定觸發的 response size... 依照文件 (Content Codings Supported by API Gateway)，目前支援的壓縮格式應該是最常見的 gzip 與 deflate。
這功能好像是一開始有 API Gateway 就一直被提出來的 feature request...
在 Twitter 上看到有人提到 curl 支援 Brotli 了：「HTTP: implement Brotli content encoding」。
Brotli 對文字系列的資料比較有幫助 (像是 html)：
Unlike most general purpose compression algorithms, Brotli uses a pre-defined 120 kilobyte dictionary, in addition to the dynamically populated ("sliding window") dictionary. The pre-defined dictionary contains over 13000 common words, phrases and other substrings derived from a large corpus of text and HTML documents. Using a pre-defined dictionary has been shown to increase compression where a file mostly contains commonly-used words.
現在還在 master 裡面，之後的 release 版本應該就會支援了...
Adobe 發出的公告，將在 2020 年中止所有對 Flash 的支援：「Flash & The Future of Interactive Content」。
Specifically, we will stop updating and distributing the Flash Player at the end of 2020 and encourage content creators to migrate any existing Flash content to these new open formats.
然後 Google 與 Microsoft 也來補刀講兩句話：「So long, and thanks for all the Flash」、「Saying goodbye to Flash in Chrome」、「The End of an Era – Next Steps for Adobe Flash」。
用 CSP 可以做到一些簡單的保護機制，但在設計不良的情況下還是有辦法繞過。
這次是上傳合法的 JPEG 檔案，但當作 javascript 檔案繞過去：「Bypassing CSP using polyglot JPEGs」。
開頭的「FF D8 FF E0」可以在「List of file signatures」這邊看到是「JPEG raw or in the JFIF or Exif file format」，而這四個字元在 javascript 不會出問題。接下來的「2F 2A」表示 JPEG header 長度，剛好就是「/*」，把後面的東西給包起來，後面再用類似的方式一直組合就打穿了...
這種攻擊要跳過的是「用 CSP 的 self 限制不能引用外部網站 javascript」的限制，但還是有些前提：
其中第一個問題常見的解法是另外開一個 domain 來放使用者上傳的檔案 (最好是連 top domain 都不一樣，完全隔開)，才可以透過 CSP 降低風險...
Amazon CloudFront 可以指定 query string 中的某個特定的 key/value 當做 cache key 的一部分了：「Announcing Query String Whitelisting for Amazon CloudFront」，對應的文件在「Configuring CloudFront to Cache Based on Query String Parameters」這邊可以查到。
先前只能針對選擇忽略掉整個 query string，或是把整個 query string 當作 cache key 的一部分，現在可以細部調整了。
最簡單的應用可以用在 css/js 的 asset 上，針對 v=\d+ 當作 cache key 的一部分，而其他的參數可以忽略，不過這好像沒什麼特別的意義。
目前想到比較有意義的應用是針對 dynamic content 多了一些籌碼可以用，像是 Slack 把整個網站放上 CloudFront 後，應該會有很多 API 是透過 query string 傳遞參數，而這次的改變讓 CloudFront 可以細部調整。
兩個月前 Google 放出來的 Google Cloud Vision API (參考「Google Cloud Vision API」) 開放讓一般人使用了，當初沒決定的價錢也公告出來了。
可以看到分成「Optical Character Recognition (OCR)」、「Image Attributes, Landmark, Facial, Logo, or Explicit Content Detection」與「Label Detection」三種，每個月的前 1000 個單位都是免費的，後面每千張是 $2.5/$2.5/$5.0，到百萬張以上時每千張變成 $2.0/$2.0/$4.0，超過五百萬時變成 $0.6/$0.6/$2.0。
另外目前有數量限制，每個月超過兩千萬張需要另外申請：
Limits: The Google Cloud Vision API supports up to 20 Million units per month per customer project. To request additional quota, please use Cloud Vision API Quota Request.