HTTPS Everywhere 將在明年一月 (2023/01) 停止運作

在「Set Up HTTPS by Default in Your Browser」這頁看到的東西:

Note: HTTPS Everywhere will sunset in January 2023.

我把他 submit 到 Hacker News 上:「HTTPS Everywhere will sunset in January 2023 (eff.org)」,裡面有一些有趣的討論,像是這跟 Google 硬幹 Manifest v2 也有關:

It doesn't seem to be mentioned by the EFF, but coincidentally, January 2023 is when Manifest v2 extensions stop working in Google Chrome: https://developer.chrome.com/blog/mv2-transition/

但查了一下,目前好像沒有好的技術標準可以確保第一次的 HTTPS request。馬上想的到的是透過 DNS 的方式指定,這樣就可以透過 DNSSEC 保護不被竄改,但看起來沒有這個標準...

Starlink 推出 RV 版本

Starlink 推出了 RV 版本:「STARLINK FOR RVs」。

這塊市場看起來不賴,不是每個地區都有 4G network 可以用,但基本上沒有 4G network 的地區應該夠空曠可以收衛星訊號?看起來目前有 coverage 的地區都支援...

另外一個是 billing 的部份:

Starlink for RVs provides the ability to pause and un-pause service at any time and is billed in one-month increments, allowing users to customize their service to their individual travel needs.

不過本來好像就沒有綁約...

AWS 推出 c7g 機種

AWSAmazon EC2 產品線上推出了新一代的 ARM 產品,AWS Graviton3 架構,c7g 系列機種:「New – Amazon EC2 C7g Instances, Powered by AWS Graviton3 Processors」。

Graviton3 宣稱比 Graviton2 多 25% 的一般性效能,以及多了一倍的浮點效能,還有 DDR5 的頻寬優勢:

Our next generation, Graviton3 processors, deliver up to 25 percent higher performance, up to 2x higher floating-point performance, and 50 percent faster memory access based on leading-edge DDR5 memory technology compared with Graviton2 processors.

在「FreeBSD on the Graviton 3」這邊也可以看到一些效能數據 (雖然是跑在 FreeBSD 上),可以看到基本上符合 AWS 的宣稱。

目前只有 us-east-1us-west-2 有這個機種,不過 Graviton 系列一直都是 AWS 的強主打項目,其他區域應該很快就會看到:

C7g instances are initially available in US East (N. Virginia) and US West (Oregon) AWS Regions; other Regions will be added shortly after launch.

價位上比 c6g 貴了一些,在 us-east-1c7g.16xlarge (64 vCPU + 128 GB RAM) 是 US$2.32/hour,而 c6g.16xlarge 是 US$2.176/hour,大約貴了 6.6%,但如果是 CPU bounded 的應用來說,應該還是蠻划算的。

另外一方面是等後續的 m7gr7g 系列出現...

GitHub 可以在 Markdown 文件裡寫 TeX 語法了

Hacker News 首頁上看到 GitHub 上的「Render mathematical expressions in Markdown」這個公告:

You can now use LaTeX style syntax to render math expressions within Markdown inline (using $ delimiters) or in blocks (using $$ delimiters).

其中 TeX rendering 這塊是透過 MathJax 產生的:

GitHub's math rendering capability uses MathJax; an open source, JavaScript-based display engine.

我記得 MathJax 的效能好像不怎麼樣... 反正是跑在使用者端的 javascript?XD

GOV.UK 拔掉網頁上的 jQuery

英國政府的網站拔掉 jQuery 了:「GOV.UK drops jQuery from their front end.」,Hacker News 上的討論也可以看一下:「Gov.uk drops jQuery from their front end (web.dev)」。

當年會選擇用 jQuery 大概有幾個原因,第一個是當年 (很舊的 browser 版本) 對 DOM 的操作非常的混亂,像是:

而 jQuery 在那個年代就已經把這堆 DOM operation 都窮舉支援了 (可以直接看「Category: DOM Insertion, Around」、「Category: DOM Insertion, Inside」、「Category: DOM Insertion, Outside」這三個大分類),可以注意 jQuery 1.0 就已經把基本界面都弄出來了,而 jQuery 1.0 是 2006 年八月出的,另外 IE7 是在 2006 年十月出,也就是說在 IE6 的年代就提供一整套完整的方案。

另外 jQuery 幫忙處理了早期 IE 與 W3C 標準的不一致行為,像是經典的 attachEvent (出自 DOM events):

Microsoft Internet Explorer prior to version 8 does not follow the W3C model, as its own model was created prior to the ratification of the W3C standard. Internet Explorer 9 follows DOM level 3 events, and Internet Explorer 11 deletes its support for Microsoft-specific model.

就功能面上來說,jQuery 提供的 Sizzle engine 也提供了 CSS selector 的能力,這在早期還沒有 querySelectorAll() (IE9+) 的時候方便不少,而且就算有了 querySelectorAll(),Sizzle 支援的 CSS selector 更完整。

上面提到的解決 browser 早期的各種亂象,jQuery 其實也帶入了不少好用的 pattern,其中一個是 fluent interface 讓人寫起來很舒服:(這個範例只是要介紹 fluent interface,不要管實際上在亂搞什麼 XD)

$('#foo').html('<p>bar</p>').css('width: 100px;');

另外就是不需要對 null object 做太多處理:

$('#foo').css('width: 100px;');

與這樣比較:

let elem = document.querySelector('#foo');
if (elem) {
    // ...
}

不過在這些年,負面的部份已經大幅改善了,所以也陸陸續續可以看到很多人在討論要怎麼拔掉 jQuery。而這次英國的 GOV.UK 拔掉 jQuery 有看到一些效果:

  • Less front end processing time overall.
  • 11% less blocking time at the 75th percentile.
  • 10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.

但說實話,~10% 左右的 performance 改變比預期中少很多耶?可以看出來 John Resig 當年在上面為了效能花了多少功夫...

這次的結果反倒是讓我在思考,如果可以用 jQuery 降低開發的瓶頸,我還蠻偏好就拿 jQuery 進來用...

在 .gitignore 裡面忽略掉 .gitignore...

Hacker News 上看到「Git ignores .gitignore with .gitignore in .gitignore」這個搞事的功能,可以在 .gitignore 內把 .gitignore 忽略掉 XDDD

這真虧作者想的到這樣的玩法 XDDD

在 Hacker News 上也有看到一些有趣的東西,像是 globally ignore list 之類的:「Git ignores .gitignore with .gitignore in .gitignore (rubenerd.com)」。

Amazon Echo 會「聽」並且將資料送到第三方廣告平台

前陣子看到的研究報告,證實 Amazon Echo 會聽取資訊並且將這些資料送到第三方的廣告平台上 (會送到 Amazon 自家應該不算新聞):「Your Echos are Heard: Tracking, Profiling, and Ad Targeting in the Amazon Smart Speaker Ecosystem」。

先從 abstract 開始看,主要是目前這些 smart speaker 基本上沒有透明度,所以十位作者群們建立了一套評估用的 framework 用來測試各家 smart speaker 資訊蒐集已經影響的情況:

Smart speakers collect voice input that can be used to infer sensitive information about users. Given a number of egregious privacy breaches, there is a clear unmet need for greater transparency and control over data collection, sharing, and use by smart speaker platforms as well as third party skills supported on them. To bridge the gap, we build an auditing framework that leverages online advertising to measure data collection, its usage, and its sharing by the smart speaker platforms.

這次論文裡面提到的目標就是 Amazon Echo 會將聽到的東西分享給第三方的廣告平台,並且讓廣告平台可以調整競價 (賺更多的錢),而且這些資訊並沒有被揭露在 privacy policy 裡面:

We evaluate our framework on the Amazon smart speaker ecosystem. Our results show that Amazon and third parties (including advertising and tracking services) collect smart speaker interaction data. We find that Amazon processes voice data to infer user interests and uses it to serve targeted ads on-platform (Echo devices) as well as off-platform (web). Smart speaker interaction leads to as much as 30X higher ad bids from advertisers. Finally, we find that Amazon's and skills' operational practices are often not clearly disclosed in their privacy policies.

幾個比較重要的資訊,其中一個是「Network traffic distribution by persona, domain name, purpose, and organization」:

另外一個重點是哪些 3rd-party:

就心裡有個底,然後隔壁棚也有類似產品 (主業是做廣告的那家),大概要跑不掉...

Kagi 的搜尋引擎開放註冊,以及公佈付費方案

先前提過 Kagi 這個搜尋引擎 (「來測試 Kagi 這個搜尋引擎」與「用兩個禮拜 Kagi 的心得」),剛剛翻信箱時看到他們的信件,看起來現在任何人都可以註冊了:

If by any chance you do not have a Kagi account yet, you can make one at https://kagi.com/signup?invite_code=humaneweb (feel free to share with your friends)

另外有提到目前規劃的收費計畫是 US$10/mo:

Kagi will come as a free version with limited use; and an unlimited use, paid option at $10 a month, both versions having great search results with less spam and completely ad-free, tracking free, and with none of your search data being retained.

Kagi 已經是我目前預設的 search engine,而且品質其實相當滿意 (偶而會切到 DuckDuckGo 以及 Google 比較),之後就等付費機制上線...

實做 RSS/Atom feed 的最佳實踐

前陣子看到的文章,在講實做 RSS/Atom feed 的 best practice:「RSS Feed Best Practises」。

最簡單的當然還是丟個 Atom feed 就好,接下來就是一些延伸出來可以多做的事情。

首先有提到 discovery,可以讓 crawler 在抓到 HTML 頁面的時候知道 feed 在哪裡,這對於 user experience 來說蠻重要的,大多數的 feed reader 都可以透過這個方式抓到真正的 feed 位置。舉個例子來說,我丟 https://blog.gslin.org/ 進 feed reader,可以透過 discovery 的方式告訴 feed reader 我的 feed 位置在 https://blog.gslin.org/feed/

<link rel="alternate" type="application/rss+xml" title="Gea-Suan Lin&#039;s BLOG &raquo; Feed" href="https://blog.gslin.org/feed/" />

另外是常見的 cache 問題,這個設起來不算太難,主要是細節很多 XD

後面提到的 WebSub,以前叫做 PubSubHubbub,是一個在 feed 更新後主動通知讓 crawler 來抓的機制。不做的話也還好,現在的 crawler 現在都還蠻聰明的,會針對更新比較頻繁的 feed 常常去確認,但這樣總是會有一些時間差。

不過裡面好像沒提到 Update Services,這是比較早期的方法,走 XML-RPC,雖然也不知道現在有什麼用途了,大概就是這樣所以沒提...

FreeBSD 的 Amazon EC2 Image 打算自動使用本機空間當作 Swap

Twitter 上看到 Colin Percival 說計畫將 FreeBSD EC2 image (AMI) 自動偵測並使用 ephemeral disk 的空間當作 swap:

就算是使用 EBSgp2 或是 gp3,甚至是其他 VPS,我也很習慣開一點點的 swap 空間來用 (通常是用 file swap 的方式開 512MB,無論記憶體有多大),這算是我自己的 best practice 了,這可以把一些完全沒用到的 daemon 塞進 swap。

不過對於已經把 ephemeral disk 規劃拿來用的人可能會不太開心,需要去改設定...