幹壞事是進步最大的原動力
昨天下午的時候看到這則官方在 Twitter 上提到的消息，要廢掉 free tier 的 API access：
Starting February 9, we will no longer support free access to the Twitter API, both v2 and v1.1. A paid basic tier will be available instead 🧵
— Twitter Dev (@TwitterDev) February 2, 2023
但這邊提到的 paid basic tier 的價錢還沒看到公告。以「API Pricing - It’s very dark out here」這邊看到的價格，目前的 premium plan 超級貴：
這下看起來是真的得搬了，目前有好幾隻程式在上面跑 :o
前幾天 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」。
這個功能等了十年以上總算是出現了，Amazon EC2 的 AMI 總算是能直接抽換 root volume，不用先停掉機器：「Amazon EC2 enables easier patching of guest operating system and applications with Replace Root Volume」。
Starting today, Amazon EC2 supports the replacement of instance root volume using an updated AMI without requiring customers to stop their instance. This allows customers to easily update their applications and guest operating system, while retaining the instance store data, networking and IAM configuration.
算是 pre-container 時代會遇到的問題，後來大家都把 workaround 變成 practice 了：每次需要時候都是直接整包重新打包 (像是 Packer 這類的工具)，然後用工具更新 AMI id 改開新的機器，這樣就能夠避開需要先停掉現有機器的問題...
怎麼會突然想到要回來支援這個功能 XD
也是上個禮拜在 Hacker News 上看到的新聞，南韓最高法院對於 web scraping 也做出了類似美國 HiQ Labs v. LinkedIn 案的判例：「Korean Supreme Court Provides Clarity on Web Scraping and Violation of the Relevant Korean Laws, including the Copyright Act and Information Protection Act (Supreme Court, 2021Do1533, May 12, 2022)」，原文似乎已經被 paywall，但可以從 Internet Archive 的「這邊」與 archive.today 的「這邊」讀到原全文。另外在 Hacker News 上的討論「The Supreme Korean court says that scraping publicly available data is legal (lexology.com)」。
hiQ 的案子之前有寫過，可以參考「hiQ 爬 LinkedIn 資料的無罪判決」這邊。
南韓最高法院認為這次的抓取公開資料不違反南韓的法令：
On May 12, 2022, the Korean Supreme Court held in Case No. 2021Do1533 that scraping publicly available data from a competitor’s website does not violate the asserted laws, including the Copyright Act and the Act on Promotion of Information and Communications Network Utilization and Information Protection (“Information Protection Act”).
比較特別的是在講刑事責任的第三點提到了 read only，不確定是不是反駁原告的立論：
The Supreme Court also found Defendants not guilty of violating the Criminal Code in light of the following findings: (i) the Defendants’ act of scraping did not interfere with information processing on Yanolja’s API server; (ii) the Defendants’ act of scraping did not interfere with Yanolja’s booking business; (iii) the Defendants did not interfere with Yanolja’s business, because its scraping did not modify data within Yanolja’s API server; and (iv) the Defendants lacked mens rea for criminal interference with business, as the Defendants merely intended to collect accommodation information from Yanolja’s API server.
整體看起來是被告的大獲全勝？
看「The trouble with symbolic links」這篇的時候看到的專有名詞：「TOCTOU (Time-of-check to time-of-use)」，直翻是「先檢查再使用」，算是一個常見的 security (hole) pattern，因為檢查完後有可能被其他人改變，接著使用的時候就有可能產生安全漏洞。
在資料庫這類環境下，有 isolation (ACID 裡的 I) 可以確保不會發生這類問題 (需要 REPEATABLE-READ 或是更高的 isolation level)。
但在檔案系統裡面看起來不太順利，2004 年的時候研究出來沒有 portable 的方式可以確保避免 TOCTOU 的問題發生：
In the context of file system TOCTOU race conditions, the fundamental challenge is ensuring that the file system cannot be changed between two system calls. In 2004, an impossibility result was published, showing that there was no portable, deterministic technique for avoiding TOCTOU race conditions.
其中一種 mitigation 是針對 fd 監控：
Since this impossibility result, libraries for tracking file descriptors and ensuring correctness have been proposed by researchers.
然後另外一種方式 (比較治本) 是檔案系統的 API 支援 transaction，但看起來不被主流接受？
An alternative solution proposed in the research community is for UNIX systems to adopt transactions in the file system or the OS kernel. Transactions provide a concurrency control abstraction for the OS, and can be used to prevent TOCTOU races. While no production UNIX kernel has yet adopted transactions, proof-of-concept research prototypes have been developed for Linux, including the Valor file system and the TxOS kernel. Microsoft Windows has added transactions to its NTFS file system, but Microsoft discourages their use, and has indicated that they may be removed in a future version of Windows.
目前看起來的問題是沒有一個讓 Linux community 能接受的 API 設計？
AWS 宣佈了 API 的 TLS 1.0/1.1 日落期：「TLS 1.2 to become the minimum TLS protocol level for all AWS API endpoints」。
公告裡提到是 2023/06/28：
This update means you will no longer be able to use TLS versions 1.0 and 1.1 with all AWS APIs in all AWS Regions by June 28, 2023.
TLS 1.0 目前還堪用的應該是 AES + CBC 類的 cipher，在正確實做 mitigation 下加減可以用：
對於像是 Java 6 環境這類很老舊的系統，如果真的無法升級的話，可以想到 workaround 的方法是透過 self-signed CA + TLS proxy 來幫忙把 TLS 1.0 的連線請求解開，重包成 TLS 1.2 的連線。
剛剛在 Hacker News 上看到有趣的 bug，在 Google Docs 上輸入 And. And. And. And. And. 會觸發 error：「Including “And. And. And. And. And.” in a Google doc causes it to crash (support.google.com)」，原始的 bug report 在「Including "And. And. And. And. And." in a Google doc causes it to crash.」這邊，錯誤訊息像是這樣：
Hacker News 上的討論有提到這需要開 grammar check 的功能，然後看起來只要有相同的五個字開頭都大寫就會發生，像是 Also, Therefore, And, Anyway, But, Who, Why. 這些：
Also, Therefore, And, Anyway, But, Who, Why.
Each in caps 5 times with the same word with a period and space after each word and newline at the end is what I have found so far.
Can anyone find others?
Edit: added words that work found in other comments
很有趣的 bug XDDD 然後目前在 Hacker News 首頁的第一名...
一樣是今天的 Hacker News Daily 上看到的東西，透過 YouTube 的 Private API 操作 YouTube 的套件：「Youtube.js – full-featured wrapper around YouTube's private API (github.com/luanrt)」。
這些 Private API 就是 YouTube 自己在網站上用的：
A full-featured wrapper around the Innertube API, which is what YouTube itself uses.
也因為這不是 Public API，也就不需要申請 key：
Do I need an API key to use this?
No, YouTube.js does not use any official API so no API keys are required.
當然可以預期他會無預警壞掉，所以可以自己衡量一下要怎麼搞...
比較有趣的是 Hacker News 的討論裡面反而有人在問要怎麼偵測這種 library 或是 bot XDDD
If you’re YouTube or any site, and want to stop these sort of wrappers - what’s the easiest way to do so without breaking your own site?
I find this task to be an interesting engineering problem.
A related question is if there’s an unspoofable way to detect a client.
不過掃了一下好像還好...
寫完上一篇「可以看 Chrome Extension 程式碼的 Chrome extension source viewer」後就可以來提「Fake Profile Detector tells you if people are real or fake online」這個了，文章裡面在介紹 V7Labs 所提供的 Chrome Extension：「Fake Profile Detector (Deepfake, GAN)」。
從套件的名字可以看出來他主要是偵測 GAN (Generative adversarial network) 類的類神經網路，這點在套件裡面說明也可以看到：
Right-click on a profile picture, our model will detect if that image contains a GAN generated or real person!
實際上測試時要注意要儘量抓夠大的圖片丟進去測，像是 Generative adversarial network 維基百科這頁裡面「Concerns about malicious applications」這個章節右邊兩張 GAN 生成的圖，如果你用維基百科預設的縮圖大小 (220x220)，上面這張會猜測是真人，下面那張會猜測是假人。
但如果到大一點的圖 (600x600) 的話就都會猜測是假人：「File:Woman 1.jpg」、「File:GAN deepfake white girl.jpg」，原圖 1024x1024 的話也可以偵測出來。
然後 source code 就在那邊可以看 API 怎麼打，大家可以自己研究...
在 Hacker News 首頁上看到「Scraping Instagram」這個掃 Instagram 資料的服務，討論在「Scraping Instagram (scrapingfish.com)」這邊。
文章裡面有提到一些 API 的技術細節，不過我覺得這塊倒不是重點，真正的重點應該是後端應該用了很多 IP 換來換去之類的技術在避開偵測...
另外這個服務讓我想到「HiQ Labs v. LinkedIn」這個案子 (之前寫過「hiQ 爬 LinkedIn 資料的無罪判決」)，不確定 Instagram 這邊會不會提起訴訟，另外看起來這家公司好像也不在美國？
收費的部份是每千次 US$2，考慮到那堆架構的成本與麻煩度，好像還可以...
