Tag: compression

使用 PNG 對圖片失真壓縮...

PNG 是無失真影像壓縮格式，但我們仍然可以修改 pixel (失真) 讓 PNG 壓縮率更好。今天在「PNG can be a lossy format」看到的 Mac OS X 應用程式就是這個用途。

雖然是應用程式，但作者還是有說明 algorithm 是哪些，分別是從哪裡來。其中兩個是：

文章最後，作者對 GIF 很感冒... XD

GIF has antiquated compression and it's a complete waste of bandwidth. Even lossy GIF is worse than lossless optimized PNG.

另外，JPEG/WebP 還是比較小，不過 JPEG 有很多格式，瀏覽器與作業系統的支援度還是很大的阻礙：

Whether lossy PNG gives better results than JPEG depends on the image. JPEG often gives smaller files, except when image has sharp edges (e.g. text) or any transparency (which JPEG does not support at all).

Optimized lossy PNG is still a bit larger than lossy JPEG-XR/WebP/JPEG-2K, but unlike these formats it's supported by all browsers and operating systems without any fuss or hacks.

最後發現 lossypng 是 Go 寫的，程式碼也不長，看起來頗好玩的... (也許包成 ports？)

新的 HTTPS 攻擊：BREACH Compression Attack

也是一個禮拜前的消息，在 Slashdot 上看到對 HTTPS 的新攻擊，目前沒有好解法，NSA 應該開心到爆炸：「BREACH Compression Attack Steals SSL Secrets」。

說明可以參考「Vulnerability Note VU#987798 BREACH vulnerability in compressed HTTPS」這篇。

假設你的 ISP 想要抓出你的 Facebook (HTTPS) session id 或是 CSRF token (只要是有能力在中間攔截封包並修改資料的團體都可以，這邊以 ISP 為例)，作法是針對 HTTP 頁面值入 script，讓你的瀏覽器對 https://www.facebook.com/ 發出大量 request，藉由觀察這些 HTTPS 的長度就有機會取得 session id (或 CSRF token)...

CERT 的 security advisory 上是寫：

With a token of length 32 and a character space of size 16 (e.g. hex), the attacker needs an average of approximately 1,000 request if no recovery mechanisms are needed. In practice, we have been able to recover CSRF tokens with fewer than 4,000 requests. A browser like Google Chrome or Internet Explorer is able to issue this number of requests in under 30 seconds, including callbacks to the attacker command & control center.

四千次就搞定了... 太！歡！樂！了！

UglifyJS - 更強大的 JS Compressor

John Resig 在 Twitter 上提到 UglifyJS 還可以對 .min.js 版本再壓 700bytes：

It seems like the UglifyJS minifier shaves about 700B off the gzipped size of jQuery. Will explore more, already impressed.

號稱比 YUI Compressor 更強大，比 Google Closure Compiler 更穩定...

用 node.js 寫的，以 JS 壓縮 JS 的程式...

利用 AWS CloudFront 的 Custom Origin 實做標準 deflate/gzip 壓縮

在「gzip support for Amazon Web Services CloudFront」這篇提到了要如何用 CloudFront 的 Custom Origin 實做標準 deflate/gzip。

之前 CloudFront 就有支援 Vary header，雖然只支援 Accept-Encoding，但這就是我們要的：(Appendix: Custom Origins)

The only acceptable value for the Vary header is Accept-Encoding.

本來 S3 沒有能力依據 Accept-Encoding 送出不同的結果，這次有了 Custom Origin 出來以後掛個有能力 gzip-on-the-fly 的 Web Server 就可以做到了，檔案也不一定要放到 S3 上 (可以放 EBS)。

基本上這個功能可以用現有的外部機器做 (因為 CloudFront 連到 Origin 的量應該不大)，或是 EC2 的 micro instance 應該也夠用了...

xz (LZMA) 的壓縮率

之前 BBS 備份都是用 gzip 加上 openssl 加密後丟上 Amazon S3，檔案大約 1GB 左右，曾經用過 bzip2，大約是 900MB，但多出來的壓縮時間與換到的空間讓人沒辦法接受...

前陣子在測 7z 格式時才發現 xz 的壓縮率高的嚇人... 當然，壓縮的時間會更久，但可以壓到少於 500MB，這對於丟上 S3 的成本就少了很多...

這是壓縮的結果：

xz -1 與 xz -2 的速度都非常快，跟 gzip -9 以及 bzip2 -9 差不多。沒意外的話 (像是軟體專利)，應該是未來的趨勢了...