讓使用者可以自己選擇 Push notification service 的 UnifiedPush

前幾天 Hacker News Daily 上看到的,F-Droid 寫了一篇文章介紹可以讓使用者自己選擇 Push notification service 的 UnifiedPush:「UnifiedPush: A decentralized, open-source push notification protocol (f-droid.org)」。

一般在 Android 平台上是透過 Google 自家提供的 FCM 傳遞 push notification 訊息:

A modern Android smartphone relies on a lot of services, from app stores and calendars to messaging and push notifications. Most of them have open alternatives, but until now, the only option for push notifications was Google’s proprietary service, Firebase Cloud Messaging (FCM).

但這樣很明顯會遇到隱私問題 (i.e. Google 可以知道所有的 push notification),所以一直都有要怎麼解決的討論。

而看起來 UnifiedPush 給了一個方案:使用者在 Android 手機上安裝一隻程式 (ntfy),這隻程式可以連到使用者指定的伺服器接收 push notification (可以是自架或是用現有的服務),另外一方面,當然也會跟 app 說要把 push notification 送到哪邊。

另外也考慮到使用者如果極度在意電池的問題,還是可以 fallback 回去使用 Google 的 FCM,也就是不影響現有使用者的體驗。

這樣就可以做到還是單一連線 (降低電力使用),但是是分散式的架構,而且使用者有一定的控制權。

目前支援的 app 看起來不多,但可以以預期後續 F-Droid 上面的 app 應該會有不少 app 會支援:「Apps using UnifiedPush」。

AS112 計畫

在「Cloudflare is joining the AS112 project to help the Internet deal with misdirected DNS queries」這邊看到的東西:「AS112 Project」,在維基百科上面也有條目:「Blackhole server」。

Cloudflare 宣佈 2022/12/15 參與 AS112 Project:

We are going to announce the AS112 prefixes starting December 15, 2022.

針對 private network 的反解 (像是 192.168.x.x 這些網段),目前的 NS RR 會丟到 IANA 的 blackhole server 上:

10.in-addr.arpa.        86400   IN      NS      blackhole-1.iana.org.
10.in-addr.arpa.        86400   IN      NS      blackhole-2.iana.org.

這兩的 domain name 分別是 與。

而 IANA 的 blackhole server 的負荷愈來愈重,所以就有了透過 anycast 打散負荷的想法,也因為在發 anycast 時的 ASN 是 112,後來也就變成了 AS112 計畫,在 RFC 7534 裡面解釋了要怎麼做:「AS112 Nameserver Operations」。

另外在 AS112 Project 的網站上也有提到 anycast 的範圍:

The address blocks are and 2620:4f:8000::/48 and its origin AS is 112.

昨天 HiNet 線路連到 AS112 的 192.175.48.x 網段會丟到日本的 WIDE,剛剛看發現已經是 Cloudflare 在台灣的點了:

hostname.as112.arpa.    604800  IN      TXT     "Cloudflare DNS, TPE"
hostname.as112.arpa.    604800  IN      TXT     "See http://www.as112.net/ for more information."

但如果是用 Google Public DNS 查詢的話則是會到 STUIX,先前也有在其他地方看到這個有趣的組織:

hostname.as112.arpa.    300     IN      TXT     "Taiwan Digital Streaming Co. with STUIX"
hostname.as112.arpa.    300     IN      TXT     "Taipei, TW"
hostname.as112.arpa.    300     IN      TXT     "Unicast IP:"
hostname.as112.arpa.    300     IN      TXT     "See http://as112.net/ for more information."

回過頭來看這次 Cloudflare 的加入,他們手上的機房與點都很多,這次跳進去看起來會分擔掉不少其他節點的 loading。

但另外隱憂 privacy 的考量,他們手上等於是可以看到一堆 invalid DNS query log...

Mozilla 推出在本地端直接翻譯的 Firefox Translations

Mozilla 推出了「Firefox Translations」這個 Firefox 上的套件。

主打的就是 offline 這件事情,保有隱私性:

Firefox Translations provides automated translation of web content. Unlike cloud-based alternatives, translation is done locally, on the client-side, so that the text being translated does not leave your machine.

Hacker News 上的討論「Firefox Translations: Translate websites in your browser without using the cloud (addons.mozilla.org)」可以看到有些人有提到效果,雖然沒有像雲端服務的準確,但算是可用:

I've just installed it, and I'm impressed so far. I've only run it against some sample German Wikipedia articles (https://de.wikipedia.org/wiki/Clan_of_Xymox), but it produces surprisingly readable text. I also particularly like the "highlight potential errors" option to flag stuff that even the translation service thinks might be a bit off.

It's not nearly as speedy as Google Translate, but I'll take that happily if it means keeping it local.


Firefox Translations was developed with The Bergamot Project Consortium, coordinated by the University of Edinburgh with partners Charles University in Prague, the University of Sheffield, University of Tartu, and Mozilla. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 825303.

不過比較好奇的是在頁面上有提到 CPU 需要 SSE4.1 能力... 這樣就有兩個問題了,第一個是 browser extension 可以直接跑 SSE4.1 指令集?另外一個疑問就是,AppleARM 架構就無法支援嗎 (應該也有類似的加速指令集),現在是 x86 限定?

A CPU that supports SSE4.1 extensions is required for this addon to function properly. If it doesn't, an error will be displayed when the translation is being started.


cURL 的 TLS fingerprint

看到「curl's TLS fingerprint」這篇,cURL 的作者 Daniel Stenberg 提到 TLS fingerprint。

先前在「修正 Curl 的 TLS handshake,避開 bot 偵測機制」與「curl 的 TLS fingerprint 偽裝專案 curl-impersonate 支援 Chrome 了」這邊有提到 curl-impersonate 這個專案,試著在 cURL 裡模擬市面上常見的瀏覽器的 TLS fingerprint。

在 Daniel Stenberg 的文章裡面也有提到這件事情,另外也提到了對 curl-impersonate 的態度:

I cannot say right now if any of the changes done for curl-impersonate will get merged into the upstream curl project, but it will also depend on what users want and how the use of TLS fingerprinting spread or changes going forward.

看起來短期內他是沒打算整,跟當初 curl-impersonate 的預期差不多...

Tor 的 Rust 計畫 Arti 推進到 1.0.0 版

在「Arti 1.0.0 is released: Our Rust Tor implementation is ready for production use.」這邊看到 TorRust 計畫進入了 1.0.0 版。

不過每次編 Rust 的東西都會發現 Rust 版本不夠新,這次也不例外,就不知道是 Rust community 的特性還是真的太少用 Rust...

    Updating crates.io index
  Downloaded arti v1.0.0
error: failed to parse manifest at `/home/gslin/.cargo/registry/src/github.com-1ecc6299db9ec823/arti-1.0.0/Cargo.toml`

Caused by:
  feature `edition2021` is required

  this Cargo does not support nightly features, but if you
  switch to nightly channel you can add
  `cargo-features = ["edition2021"]` to enable this feature

rustup update 更新後就能編了,然後跑起來看起來沒什麼問題:

$ arti proxy -p 9150
2022-09-03T17:13:30.234032Z  INFO arti: Starting Arti 1.0.0 in SOCKS proxy mode on port 9150...
2022-09-03T17:13:30.238606Z  INFO tor_circmgr: We now own the lock on our state files.
2022-09-03T17:13:30.238652Z  INFO tor_dirmgr: Didn't get usable directory from cache.
2022-09-03T17:13:30.238674Z  INFO arti::socks: Listening on
2022-09-03T17:13:30.238686Z  INFO arti::socks: Listening on [::1]:9150.
2022-09-03T17:13:30.238713Z  INFO tor_dirmgr::bootstrap: 1: Looking for a consensus.
2022-09-03T17:13:33.833304Z  INFO tor_dirmgr::bootstrap: 1: Downloading certificates for consensus (we are missing 9/9).
2022-09-03T17:13:34.335754Z  INFO tor_dirmgr::bootstrap: 1: Downloading microdescriptors (we are missing 6629).
2022-09-03T17:13:41.041683Z  INFO tor_dirmgr::state: The current consensus is fresh until 2022-09-03 17:00:00.0 +00:00:00, and valid until 2022-09-03 19:00:00.0 +00:00:00. I've picked 2022-09-03 18:35:38.290798754 +00:00:00 as the earliest time to replace it.
2022-09-03T17:13:41.061978Z  INFO tor_dirmgr: Marked consensus usable.
2022-09-03T17:13:41.065536Z  INFO tor_dirmgr: Directory is complete.
2022-09-03T17:13:41.065557Z  INFO tor_dirmgr: We have enough information to build circuits.
2022-09-03T17:13:41.065564Z  INFO arti: Sufficiently bootstrapped; system SOCKS now functional.

curl 測試也的確是 Tor 的 exit node 了:

$ curl -i --socks5 https://httpbin.org/ip
HTTP/2 200 
date: Sat, 03 Sep 2022 17:21:20 GMT
content-type: application/json
content-length: 32
server: gunicorn/19.9.0
access-control-allow-origin: *
access-control-allow-credentials: true

  "origin": ""

$ host domain name pointer tor.localhost.lu.

看起來 client 的功能能用了...

從 Android (AOSP) fork 出來的 /e/

上個禮拜在 Hacker News 看到的「Review of /e/ – An Android Alternative For Mobile Phones」,在講 /e/ 這個從 AOSP 改出來的作業系統,主力在於「unGoogled」這件事情,避免任何資料傳回給 Google。Hacker News 上對應的討論在「Review of /e/ – Android-based alternative for mobile phones (thenewleafjournal.com)」這邊。

先看了一下運作方式,/e/ 的後面是 e Foundation,以非營利組織的方式經營。

LineageOS 的經驗來看,看起來有蠻多東西預先包好了,像是預掛了 microG 來模擬 Google Play Services 的服務與 API,這樣可以讓一些需要 Google Play Services 的服務可以跑 (但可以預期不會是完全相容)。

另外也有一些商業合作,所以市場上可以買到出廠就已經安裝 /e/ 的手機,讓一般使用者更容易上手。另外一條可以預期的路是自己刷 /e/,從「Smartphone Selector」這邊可以看到 /e/ 支援很多型號。

文章裡另外題到了其他的 AOSP fork,走不同的路線:

In addition to LineageOS, there are two forks focused primarily on security – GrapheneOS and CalyxOS. There is also Replicant, which appears to mostly support older devices at this time.

看起來弄個 Pixel 5a 或是舊一點的 Pixel 4a 應該是個還可以的方向,Google 自家牌的手機通常都是這些 distribution 優先支援的機種...

iOS Safari 擋 "Open in App" 的付費套件 Banish

在「New iOS App Blocks Those Annoying 'Open in App' Pop-Ups in Safari」這邊看到 John Gruber 的介紹文章「Banish: New Safari Extension to Block 'Open in App' Dickpanels」,裡面提到的 extension 在「Banish for Safari」這邊,一次性的費用,在台灣是 NT$70。

裡面的 screenshot 給了還蠻清楚的說明:

設定上面因為會牽扯到 privacy 的關係,會有點麻煩,需要開好幾個地方。

順道一提,桌面上的話可以透過 Annoyances 系列的 list 在 uBlock Origin 上擋。

Let's Encrypt 更新了 ToS

在「Let's Encrypt’s subscriber agreement changes on Sept 21 (letsencrypt.org)」這邊看到的,Let's Encrypt 有提供 diff 的內容,在「LE-SA-v1.2-v1.3-diff.docx」這邊,你也可以用 Google Docs Viewer 看:「LE-SA-v1.2-v1.3-diff.docx」。

看起來主要是用語上的改變 (可能是律師的建議?),除了 revoke 的章節外看起來沒什麼大變化。而 revoke 的章節部份增加了這兩段文字:

You warrant to ISRG and the public-at-large, and You agree, that before providing a reason for revoking Your Certificate, you will have reviewed the revocation guidelines found in the “Revoking Certificates” section of the Let’s Encrypt documentation available at https://letsencrypt.org/docs/ , and that you will provide Your corresponding revocation reason code with awareness of such guidelines.

You acknowledge and accept that ISRG may modify any revocation reason code provided by You if ISRG determines, in its sole discretion, that a different reason code for revocation is more appropriate or is required by industry standards.

不確定自動化的 client 需不需要重新再 accept 一次?


Hacker News 上的「TeamViewer installs suspicious font only useful for web fingerprinting (ctrl.blog)」這邊看到的技巧,原文在「TeamViewer installs suspicious font only useful for web fingerprinting」這邊,但文章標題本身可以忽略。

這別提到的方法是,在安裝軟體時額外安裝一個特別的字型,然後網頁就可以透過 javascript 判斷這個字型存不存在,來得知使用者是否有安裝自己的軟體,接下來就可以走到不同的 flow:可以導引使用者下載軟體,或是透過 handler 拉起應用程式。

不過這也透漏出了隱私問題,代表廣告商可以利用這點取得 fingerprint,而不只是軟體自家的網站。

看討論串裡面說 Firefox 上可以用 privacy.resistFingerprinting 擋住:「Firefox's protection against fingerprinting」,但 Firefox 本身也沒有說明的太清楚到底會放行哪些字型:

Not all fonts installed on your computer are available to webpages


We only allow specific system fonts to be used, and we ship them to the user using kinto

直接試著找 Bugzilla 與 source code 的資料可以翻到「Restrict CSS font visibility to standard fonts only when privacy.resistFingerprinting is true」這個討論,裡面有提到「https://searchfox.org/mozilla-central/search?path=StandardFonts*.inc」這個,可以看到有 LinuxmacOSWindows 10 下的清單。

不過 Chromium-based browser 下目前好像沒看到方案...

微軟的 Outlook 系統會自動點擊信件內的連結

前幾天在 Hacker News Daily 上翻到的,微軟的 Outlook 系統 (雲端上的系統) 會自動點擊信件內的連結,導致一堆問題:「“Magic links” can end up in Bing search results — rendering them useless.」,在 Hacker News 上的討論也有很多受害者出來抱怨:「“Magic links” can end up in Bing search results, rendering them useless (medium.com/ryanbadger)」。

原文的標題寫的更批評,指控 Outlook 會把這些 link 丟到 Bing 裡面 index,這點還沒有看到確切的證據。

先回到連結被點擊的問題,照文章內引用的資料來看,看起來是 2017 年開始就有的情況:「Do any common email clients pre-fetch links rather than images?」。

As of Feb 2017 Outlook (https://outlook.live.com/) scans emails arriving in your inbox and it sends all found URLs to Bing, to be indexed by Bing crawler.

在 Hacker News 上的討論也提到了像是 one-time login email 的機制也會因此受到影響,被迫要用比較費工夫的方法讓使用者登入 (像是給使用者 one-time code 輸入,而不是點 link 就可以登入)。

先記起來,以後在設計時應該會遇到,要重新思考 threat model...