Popover API

看到「Popover API (developer.mozilla.org)」這個討論,引用的資料是 MDN 上面的「Popover API」,從名字也可以看出來與 pop over 有關 (話說查單字發現 popover 這個詞在字典裡居然是泡芙,英文維基百科上的 Popover 也可以看到...)。

Anyway,馬上有想到的是 modal 類的操作,在 MDN 上面的文件裡面有範例,可以用純 HTML 的方式操作:

<button popovertarget="mypopover">Toggle the popover</button>
<div id="mypopover" popover>Popover content</div>

效果就是在畫面正中央出現,預設有 border。

另外也可以透過 JavaScript 的方式操作:

HTMLElement.togglePopover()

MDN 文件把這個功能標成 Baseline 2024:

Since April 2024, this feature works across the latest devices and browser versions. This feature might not work in older devices or browsers.

因為是很新的東西 (就支援度來說),要注意如果使用者是舊版瀏覽器的 fallback 行為。

翻文件底部的支援情況,可以看到最後支援的主流瀏覽器是 Firefox 125 (2024/04/16),而 Firefox 還是有人會用 ESR 版本,目前還是 115,但照著 Firefox ESR 的節奏,應該是暑假會出下一版,但如果是現在要用的話,應該得考慮用 polyfill 去支援不原生支援的瀏覽器。

HTML 上的注音標示

Fediverse 上面看到 itszero 提到 HTML 的注音標示:

翻了「HTML Ruby Markup Extensions」這邊的資料,從 GitHub 上面看起來是三月的時候加進去的 commit:「
Import new Draft」,不過目前測了 stable 版的 Brave (Chromium-based) 與 Firefox 都還沒支援。

我把測試丟在 https://jsfiddle.net/5sedmoLu/ 這邊,後續有新消息的時候可以直接看看效果...

Dillo 瀏覽器重新啟動

前幾天看到「Show HN: Dillo 3.1.0 released after 9 years (dillo-browser.github.io)」這個消息,Dillo 瀏覽器的重啟,將過去九年的 patch 整理起來出了 3.1.0:「Dillo release 3.1.0」。

從記憶裡面勉強挖出對 Dillo 的印象,翻了維基百科確認了不支援 js 的部分:

Dillo does not support JavaScript, Java, Flash, right-to-left text, or complex text layout.

目標是只用極少的資源 (以維基百科的說法是 i486 這樣的電腦),所以 Dillo 只能顯示基本的網頁。剛剛抓 3.1.0 下來自己編,測了一下連 Acid1 都不會過。不過可以看看後續會發展到什麼程度...

OpenSSL 決定把 release site 改到 GitHub 上

OpenSSL 宣佈了之後會以 GitHub 為主要發佈平台:「Releases Distribution Changes」。

舊的 ftp & rsync 以及 git protocol (9418/tcp 的協定) 都打算淘汰掉:

We’re no longer using our old ftp, rsync, and git links for distributing OpenSSL. These were great in their day, but it’s time to move on to something better and safer.

其中 FTP 與 rsync 都已經停掉了,接下來是今年六月要停掉 ftp.openssl.org 的 HTTPS 介面以及 git.openssl.org 的 git protocol:

ftp://ftp.openssl.org and rsync://rsync.openssl.org are not available anymore. As of June 1, 2024, we’re also going to shut down https://ftp.openssl.org and git://git.openssl.org/openssl.git mirrors.

然後主力轉戰到 GitHub 上面:

GitHub is becoming the main distributor of the OpenSSL releases.

算是省事的作法,畢竟自己弄 infrastructure 不算太輕鬆

另外 OpenSSL 畢竟是個歷史頗久的軟體了,有「遵循古法」所以 release 都會有 PGP/GPG sign,這部分如果還是獨立於 GitHub 平台的話就沒什麼問題,代表還是有非 HTTPS 的 integrity 方法可以確認檔案沒被抽換過。

(但如果綁進 CI/CD 流程的話就廢了?)

Chrome 124 啟用了 X25519Kyber768

在「Google Chrome's new post-quantum cryptography may break TLS connections」這邊看到的,出自「Q1 2024 Summary from Chrome Security」這邊的公告。

Chrome 124 預設啟用 X25519Kyber768 了:

After several months of experimentation for compatibility and performance impacts, we’re launching a hybrid postquantum TLS key exchange to desktop platforms in Chrome 124. This protects users’ traffic from so-called “store now decrypt later” attacks, in which a future quantum computer could decrypt encrypted traffic recorded today.

如果遇到問題的話可以在 chrome://flags 裡面的 #enable-tls13-kyber 關閉後重開瀏覽器... 不過應該是還好,大多數的 HTTPS server 應該都沒有實作 X25519Kyber768,就算是 Cloudflare 應該預設也是關的。

LinkedIn 決定要在平台上面弄出遊戲...

也是清連結的消息,三月中的消息,LinkedIn 想要在平台上面弄出遊戲:「LinkedIn plans to add gaming to its platform」。

會是 puzzle 類型的遊戲,而且看起來有東西了:

It will be doing so by tapping into the same wave of puzzle-mania that helped simple games like Wordle find viral success and millions of players. Three early efforts are games called “Queens”, “Inference” and “Crossclimb.”

然後當時跟 LinkedIn 發言人確認也證實了這點:

“We’re playing with adding puzzle-based games within the LinkedIn experience to unlock a bit of fun, deepen relationships, and hopefully spark the opportunity for conversations,” the spokesperson said in a message to TechCrunch. “Stay tuned for more!”

試著走向更一般性的 social network?目前 LinkedIn 上面應該都是雞湯文與 clickbait,這個變化好像有點大...

Reddit 當初對 Google 搜尋引擎的客製化設計

Hacker News 上看到的討論,裡面剛好有 Reddit 第一個雇用的工程師,Jeremy Edberg 的留言:「Reddit is taking over Google (businessinsider.com)」。

id=40068381 這邊提到了不少東西,首先是把 title 放進 url 裡面的作法:

To this day, my most public contribution to reddit is that I wrote the code to put the title of the post in the URL. That was done specifically for SEO purposes.

這個在 Google Webmasters (現在叫做 Google Search Console) 也針對 Reddit 處理,將速率強制設為 Custom,不讓 Reddit 的人改:

It was pretty much the only SEO optimization we ever did (along with a few DOM changes), because shortly after that, Google basically dedicated engineering effort specifically to crawling reddit. So much so that we lost the "crawl rate" button in our SEO admin page on Google, it was just set to "Custom".

後續還要針對 Google 的抓取在 load balancer 上把流量拆開處理,不然 crawling pattern 與一般使用情境很不一樣,會造成 cache 的效率極度低落:

I had to stand up a fleet of app servers and caches and databases, and change the load balancers so that Google basically had their own infrastructure (although we would shunt all crawlers there). Crawler traffic was very different than regular traffic -- it looked at pages more than two days old, something humans rarely did at the time. It would blow out every cache (memory, database, disk, etc.). So we put them on their own infra to keep them from killing the rest of the site.

這些算是頗有趣的經驗?

Firefox 的 UI 修正方案

在「Firefox Proton UI userChrome.css fixes. (2021) (github.com/black7375)」這邊看到的,GitHub 上的專案頁面在「Lepton (old name: Proton Fix)」這邊。

作者先前有寫過,我在「Firefox 的 UI/UX 歷史」這篇,同一個 repository 裡面就包含了「修正方案」,補上了一些 icon,並且改了 css 效果。

不過我已經沒什麼在用 Firefox 了,而且目前看起來也不會回去了,看起來只有在交叉找問題的時候會用到...

UUID 的 UX

在「The UX of UUIDs (unkey.dev)」這邊看到的紋章,原文在「The UX of UUIDs」。

裡面有不少是有幫助的建議,像是第一個建議是把 UUID 裡面的 - 拿掉,這樣對於 copy 比較方便 (畢竟大多數人應該是 copy UUID,不會是念出來?)。

第二個建議是加上 prefix,這點不一定侷限在 UUID,只要是 token 上面都很適合。這個在不少系統上應該都有看過,像是 GitHub 的 token,或是 AWS 的 token 都算是這類。

文章裡面沒有提到,但這個建議也可以幫助你在 CI 上設定 regex,擋下把 secret token 寫進去的行為。

第三個提到用 base58,一方面是減少長度,另外一方面是想要避免 1IiLl0Oo 的問題,這點我覺得還好... 既然都是 copy & paste 了,我覺得拿 base62 (i.e. 大小寫加上數字) 不錯,這避免特殊字元無法選擇到,也就是文章裡面第一個建議。

第四個建議是建議重新思考 range,因為 UUID 的 128-bit range 很大,但不是所有應用都需要用到這麼大的範圍確保 collision-free (於是可以當 primary key)。

這點讓我想到 X (Twitter) 當初發表的 Snowflake ID,在 Twitter 這種規模下 64-bit range 也已經夠用。

後面的文章內容就是在推銷自家東西,我就... 跳過了。

利用信件裡面的 CSS,讓文字只在轉寄後才出現

在「Kobold letters: HTML emails are a risk (lutrasecurity.com)」這邊看到的 security advisory (算... 是吧?),原文在「Kobold Letters」這邊,如同標題寫的,方法其實意外的簡單...

Thunderbird 是透過 .moz-text-html>div> 指定就可以達到效果:

Outlook on the web (i.e. 雲端版本) 則是有在 id 上面增加隨機的 prefix 避免,但可以用 body>div> 避開,另外有些眉眉角角的地方會稍微複雜一點,但還是可行的:

Gmail 則是直接用個簡單的 css selector 掛上 display: none; 就 OK 了:在 sender 端 (轉寄者) 看不到,在 receiver 端則可以 (效果更好?):

比較慘的是目前大家都沒有想到比較好的解法,就算這次提到的方法被補上了,應該還是很容易被繞過去:

Unfortunately, for the foreseeable future, it is sadly not realistic to expect email clients to implement robust mitigation. This means that it is up to the users to be aware of the dangers of HTML emails and to take the necessary precautions.

另外文章裡面提到了 Can I email 這個網站,看起來如果要自己處理 email 內容的話是個不錯的資源...