幹壞事是進步最大的原動力
目前我在 blog 上使用 Imgur 的圖檔主要是用 WebP 格式，然後針對不支援 WebP 的瀏覽器 (主要就是蘋果家的 Safari) 是用 JavaScript 換回 JPEG 格式...
昨天早上看到「AVIF has landed」這篇，提醒我有 <picture> 這個原生支援的方式可以用，翻了一下 Can I Use 上面的支援程度，看起來除了 IE11 以外幾乎都支援了 (參考「Picture element」)，而且 IE11 應該也會因為語法的關係走到正確的 JPEG fallback，大概是這樣：
<picture>
<source type="image/webp" srcset="https://i.gslin.com/imgur/xxxxxx.webp" />
<img src="https://i.gslin.com/imgur/xxxxxx.jpg" alt="" />
</picture>
換完後來觀察看看...
現在 Google Chrome 的穩定版是 77，到了十二月會推出的 79 的時候，就會有一連串的避免 HTTPS 頁面使用 HTTP 資源的措施：「No More Mixed Messages About HTTPS」。
首先是 79 的時候會有新的界面，讓使用者可以修改阻擋類的設定。
到了 80 的時候會試著將 HTTP 的影音 <audio> 與 <video> 升級到 HTTPS 連線，如果 HTTPS 讀不到的話就當作讀取失敗。但圖片 <img> 的部份則是會讀進來，只是安全性上會顯示 Not Secure。
到了 81 就是這系列的最終階段，包括 <img> 也會一使用 80 時影音的邏輯，沒辦法在 HTTPS 上讀到就當作讀取失敗。
看到「imgproxy: Resize your images instantly and securely」這篇文章，介紹「DarthSim/imgproxy」這個專案，想起很久以前的同事在 PIXNET 弄的 *.pimg.tw 系列服務...
imgproxy 可以 resizing，也可以 croping，然後也支援 signature token 機制，感覺是每個大一點的站台都會自己刻一次的服務 XD
整個專案以 Golang 為主，效能應該是不錯... 不過一般前面還是會放 cache 機制 (像是 CDN 之類的服務)，而不會把 loading 直接打進來，避免同樣的圖片一直重複計算。
在「Using Facebook Notes to DDoS any website」這篇文章裡提到了利用 Facebook Notes 允許使用者嵌入 <img> 標籤時的特性，利用 Facebook 的 server 進行 DDoS...
在 Notes 一般的 <img> 會被 Facebook 的伺服器 cache 起來，但如果是帶有 query string 的 <img> 就不會 cache (因為不同的 query string 表示不同的 url 是合理的)，於是就可以利用這個特性打出超高的流量：
這個問題被 Facebook 認為不是問題，不會也不打算修正...
文章後提到的指令還蠻有趣的，要抓出某個 AS number 有哪些 IP address，可以用這樣的指令抓出來：
whois -h whois.radb.net — '-i origin AS32934' | grep ^route
試著抓了 AS9916 與 AS18185，的確是蠻有趣的東西 XD