安排路線的服務 Trail Router

Hacker News Daily 上看到的有趣服務,給起點與終點,以及想要有的長度,可以幫你拉一條差不多長度的路徑出來,可以提供給慢跑或是騎腳踏車的人規劃路線:「Trail Router」。

然後發現原來公司對面有 YouBike 站點... XD

這個服務的作者有在 Hacker News 上接受大家的詢問,可以到 Hacker News 上討論的頁面看一下作者的回應:「Show HN: Trail Router – generate running routes that prefer greenery and nature (trailrouter.com)」。

另外值得一提的是,這個服務用了 Mapbox 的圖資 (跟 OpenStreetMap 有關),看起來台北地區的呈現已經遠超過以前「堪用」的程度了,以後如果有需要用到的話可以考慮看看,就不一定要綁在 Google Maps 上了...

TLS 憑證的最長時效將從 825 天降到 398 天

在「Reducing TLS Certificate Lifespans to 398 Days」這邊看到才想起來沒寫這篇,這邊發生了一些有趣的事情...

提案是降低 TLS 憑證的有效時效,這件事情一開始是在 CA/B Forum 討論,但經過投票後沒有通過:「Ballot SC22 - Reduce Certificate Lifetimes (v2)」。

從投票記錄可以看到所有的憑證使用方 (包括了許多瀏覽器的廠商) 都贊同,但有大約 2/3 的憑證發行方都反對:

7 votes total including abstentions:

  • 7 Yes votes: Apple, Cisco, Google, Microsoft, Mozilla, Opera, 360
  • 0 No votes:
  • 0 Abstain:

33 votes total including abstentions

  • 11 Yes votes: Amazon, Buypass, Certigna (DHIMYOTIS), certSIGN, Sectigo (former Comodo CA), eMudhra, Kamu SM, Let’s Encrypt, Logius PKIoverheid, SHECA, SSL.com
  • 20 No votes: Camerfirma, Certum (Asseco), CFCA, Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy, Izenpe, Network Solutions, OATI, SECOM, SwissSign, TWCA, TrustCor, SecureTrust (former Trustwave)
  • 2 Abstain: HARICA, TurkTrust

然後幾個比較大的憑證使用方 (AppleGoogleMozilla) 在提案被否決後就決定放到自家的規則了:「Apple strong-arms entire CA industry into one-year certificate lifespans」。

從 2020/09/01 開始,如果發出來的憑證超過 398 天就當作是無效憑證,也就是 2020/08/31 是最後一天可以發有效期限為 825 天的憑證,會落在 2022/12/05 失效:

$ date --date='Sep 1 2020 GMT+0000 +825days'
Mon Dec  5 08:00:00 CST 2022

這三家搞下去,就等於是強制性讓這些 CA 到九月就不能賣兩年的憑證了 (雖然還沒看到 Microsoft),這些 CA 一定是在心裡幹爆... XD

回頭來看一下 Limelight Networks

是因為看到「How Limelight Networks speeds up sales deals with Slack Connect」這篇,才想到 Limelight Networks 這家 CDN 之前也是這個產業很大的 vendor,在很多大型網站可以看到 llnw 的蹤跡 (當時 Microsoft 的 Windows Updates 與 Apple 的軟體下載還會用他的服務),但這十年看起來就被 CloudflareCloudFront 以及 Fastly 這些後起之秀超越過去了... (至少在聲量上面是這樣)

翻到 Global Private Network 這頁,意外發現現在有把節點列出來了,記得以前是不公開的...

在裡面可以看到台灣也有節點,不過拿 HiNet 與 APOL (家裡的 cable) 實際測官網 www.limelight.com,發現都是導去香港的點,可能是有需要的客戶才會導過去,之後有機會也許問問看...

Userscript 內對於 SPA 類的頁面的修改

目前的 userscript 支援這四種啟動時機 (用 @run-at 參數指定):

  • document-start (一開始就跑)
  • document-body (出現 body 後跑)
  • document-end (DOMContentLoaded 時,或是之後跑)
  • document-idle (DOMContentLoaded 後跑)

但對於 SPA 類的頁面來說,即使用到 document-idle,也不保證執行時頁面已經渲染完成,這時候可能是 framework 才正要開始處理頁面的時候。

如果我們的 userscript 想要「等」這些 framework 處理完後再開始跑,其中一種 workaround 是用 setTimeout() 等,但這樣很容易被 side effect 影響,像是電腦慢一點的時候還是會失敗,而如果 setTimeout() 時間拉太長體驗又不好:

setTimeout(() => {
    // ...
}, 1000);

比較好的方式是用 MutationObserver() 聽事件,在每次有新元素插入時判斷是否達成條件,處理完成後再停止聽事件 (避免持續影響效能):

let observer = new MutationObserver(() => {
    // ...
    // observer.disconnect();
});

observer.observe(document.documentElement, {
    attributes: false,
    childList: true,
    subtree: true,
});

有些 library 有把這段包起來,但看了使用方式覺得很複雜 (因為要支援比較多的情境),反而是自己把 MutationObserver() 的概念搞清楚後,用這幾行包起來還比較簡單...

WebP 的檔案大小未必比 JPEG 小...

在「Is WebP really better than JPEG?」這邊發現在差不多的條件需求下,WebP 壓出來的檔案大小未必會比 JPEG 小。

先講結論:提供服務的人可以先確認自家的 JPEG 壓縮是不是有先用 MozJPEG (壓縮率更好),然後再考慮要不要支援 WebP。

Google 在推 WebP 這個格式的時候,宣稱失真壓縮的部份可以比 JPEG 小 25%~34%:(出自「A new image format for the Web」)

WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.

但作者發現 Google 之所以可以達到 25%~34% 這個數字,是因為比較的對象是 Independent JPEG Group 所釋出的 cjpeg,而如果拿 MozJPEG 相比的話應該得不到這個結果,另外也把 AV1 的 AVIF 拉進來一起測試了:

I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed.

這邊作者測試用的圖集是 Kodak Lossless True Color Image Suite,測試的結果發現 WebP 的確比 libjpeg (cjpeg) 好一些,但沒有像 Google 講的那麼多 (這邊就不知道是不是現在的 libjpeg 又有改善),而 WebP 與 MozJPEG 相比的話就沒有明顯優勢了:

WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.

However, when compared to MozJPEG, WebP only performs better with small 500px images. With other image sizes the compression is equal or worse.

I think MozJPEG is the clear winner here with consistently about 10% better compression than libjpeg.

另外也提到了 AVIF 的壓縮率很好,不過要注意演算法會把非重點部位的細節吃掉:

I think AVIF is a really exciting development and compared to WebP it seems like a true next-generation codec with about 30% better compression ratio compared to libjpeg. Only concern I have is the excessive blurring of low detail areas. It remains to be seen if this can be improved when more advanced tooling becomes available.

對網頁的應用來說,WebP 另外一個痛點是在 Safari 上的支援度,在 caniuse.com 的「WebP image format」這邊可以看到目前各瀏覽器都支援了,就剩下 Safari 還不支援,所以目前在 iOS 上得降回 JPEG:

不過這點之後也改變了,在 iOS 14 beta 裡的 Safari 可以看到支援 WebP 了:「Safari 14 Beta Release Notes」。

Media
New Features
Added WebP image support.

所以這個狀況變得有點微妙了...

阻擋網站透過瀏覽器掃 localhost

五月的時候,DuckDuckGoCharlie Belmer 發了一篇關於網站透過瀏覽器掃 localhost 的文章,引起了不少重視:「Why is This Website Port Scanning me?」。

這個月陸陸續續看到一些反制方式了,比較簡單的是透過像 uBlock Origin 這類可以擋特定 url 的方式,像是 EasyPrivacy 裡面把一些大站台的 javascript script 擋下來:「uBlock Origin ad blocker now blocks port scans on most sites」。

在同一篇文章的 comment 處也有人提到 uBlock Origin 可以做的更廣泛:「Block access to 127.0.0.1/localhost and LAN address from the internet #4318」,裡面有人已經整理好丟出來了:「lan-block.txt」,看起來也可以擋一些...

要擋得比較完整的還得考慮 scan.example.com IN A 127.0.0.1 這種方式繞過去的情況?這可能需要用 extension 了...

提供社群網站 RSS feed 的服務

Hacker News Daily 上看到的服務:「RSS Box」,主要是有 open source,所以可以自己架起來跑 (只是得自己生 API key):「RSS Box」。

測了一下目前的站台,TwitterInstagram 的部份都已經撞到 rate limit,而 YouTube 的部份正常。

我自己也有寫類似的東西,不過就不是透過 API 了,像是先前 Instagram 對於沒有登入的人還可以看到頁面內容,所以有在 feedgen 上寫了一個 parse HTML 的版本出來,最近需要強制登入後也不行了,可能拔一拔收工...

Google Chrome 又要對 URL 搞事了...

上個禮拜鬧的頗兇的話題,Google Chrome 又要對 URL 搞事了:「Google resumes its senseless attack on the URL bar, hides full addresses on Chrome 85」。

這次是打算把整個 path 藏起來:

A few new feature flags have appeared in Chrome's Dev and Canary channels (V85), which modify the appearance and behavior of web addresses in the address bar. The main flag is called "Omnibox UI Hide Steady-State URL Path, Query, and Ref" which hides everything in the current web address except the domain name. For example, "https://www.androidpolice.com/2020/06/07/lenovo-ideapad-flex-5-chromebook-review/" is simply displayed as "androidpolice.com."

來繼續等 3rd-party browser 成熟...

Chrome Extension 的效能分析

在「2020 Chrome Extension Performance Report」這邊看到有人對 Chrome Extension 上前一千名的效能分析,作者有提到是在 GCP 上的虛擬機測試的,跑七次取中位數:

I ran these tests on an n2-standard-2 Google Cloud instance, the numbers in this report show the median of 7 runs.

在「Chrome Extension Performance Lookup」這頁可以直接互動查詢,像是丟入 block 找跟擋廣告有關的關鍵字可以看到:

只看一般性的 blocker (中間還有 VPN 與一些不是一般性的先跳過),沒什麼意外的 uBlock Origin 的表現很好。

文章內的說明也可以翻一下,看看有沒有哪些 extension 其實不是很必要,但卻榜上有名,可以考慮拔掉省時間與資源...

MIT 終止與 Elsevier 的合約

美國在今年有不少學校開始跟進,終止與 Elsevier 的合約了。

首先是去年 (2019) 三月加州大學系統宣佈不跟 Elsevier 續約 (參考當時寫的「加州大學宣佈不與 Elsevier 續約」這篇),今年四月則是北卡大學系統宣佈不續約:「Upcoming Elsevier Cancellations」,以及紐約大學系統也宣佈不續約:「State University of New York Steps Away From the “Big Deal” with Elsevier」。

到這邊看到的消息主要都是公立學校系統在開槍,直到前幾天 MIT 也放新聞稿開槍宣佈不續約了,這應該是第一個頂級的私校開槍的消息:「MIT, guided by open access principles, ends Elsevier negotiations」。

維基機百科上查資料的時候,發現台灣在 2016 年底 CONCERT 就宣佈放掉 Elsevier 了,當時有發稿出來:「關於 Elsevier 資料庫合約談判 CONCERT 聲明」。

In Taiwan more than 75% of universities, including the region's top 11 institutions, have joined a collective boycott against Elsevier. On 7 December 2016, the Taiwanese consortium, CONCERT, which represents more than 140 institutions, announced it would not renew its contract with Elsevier.