南韓最高法院也對 Web Scraping 給出了類似美國的判例

也是上個禮拜在 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.


原來有專有名詞:TOCTOU (Time-of-check to time-of-use)

看「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 日落期

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 的連線。

Google Docs 裡 Grammar Correction 的 bug

剛剛在 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 首頁的第一名...

社群維護的 YouTube Private API 套件

一樣是今天的 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.


V7Labs 提供的 Chrome Extension,偵測圖片是否為人工智慧生成的

寫完上一篇「可以看 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 怎麼打,大家可以自己研究...

掃 Instagram 資料的服務

Hacker News 首頁上看到「Scraping Instagram」這個掃 Instagram 資料的服務,討論在「Scraping Instagram (scrapingfish.com)」這邊。

文章裡面有提到一些 API 的技術細節,不過我覺得這塊倒不是重點,真正的重點應該是後端應該用了很多 IP 換來換去之類的技術在避開偵測...

另外這個服務讓我想到「HiQ Labs v. LinkedIn」這個案子 (之前寫過「hiQ 爬 LinkedIn 資料的無罪判決」),不確定 Instagram 這邊會不會提起訴訟,另外看起來這家公司好像也不在美國?

收費的部份是每千次 US$2,考慮到那堆架構的成本與麻煩度,好像還可以...


是一篇 2017 年的文章,前幾天在 Hacker News 上重新被提出來:「The Line of Death (2017) (textslashplain.com)」。

文章開頭在講瀏覽器 UI 的信任區,這條線以上是 native UI,以下是網站可以任意操控的內容:

所以 UI 上面有些小細節讓你區分,但這其實對不是專精 phishing 的人很不友善:

另外當然就會提到 browser-in-a-browser (以及 picture-in-picture) 類的 phishing 了:

另外提到了 Fullscreen API,這使得信任區間變成 0:

提到 Fullscreen API 所以就去翻資料,意外發現 IE11 居然支援這組 API,雖然是帶 ms 的 prefix,而且不支援一些輔助性的功能 (像是傳回 Promise object)。

這些 UI 與 security 類的問題,主要還是得考慮到使用者未必那麼熟悉,以及就算有經驗的人也很有可能不小心中獎...


Hacker News 上看到「I wrote a program that sends cats to my phone when I'm sad at the computer (healeycodes.com)」這個東西,居然是用 cam 判斷,當判斷心情不好的時候就推播貓貓的圖片,像是這樣:

除了 machine learning 的部份快,這邊還用到了幾個服務,像是 PushoverThe Cat API (居然有這種服務 XDDD)...

馬上想到前陣子看的 Don't Look Up (千萬別抬頭),裡面好像也有類似的產品 XDDD


Hacker News Daily 上看到「Show HN: API to query catalogs of 20 streaming services across 60 countries (movieofthenight.com)」這個,但這個服務反而不是重點,有許多人發現裡面錯誤率頗高,而且也沒有台灣的資料,反倒是裡面有人提到 JustWatch 這個服務看起來比較好用...

像是「Friends」(這邊用的是中國的翻譯片名) 可以看到在台灣是在 Netflix 上,美國的話則是在 HBO Max (串流) 與 Apple TV (購買) 上可以看到。不過查 MythBusters 在兩個平台上都沒看到資料...

但整體上來說 JustWatch 搜出來的品質還是好不少...