社群維護的 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,考慮到那堆架構的成本與麻煩度,好像還可以...

心情不好時自動送貓貓圖推播的專案

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 搜出來的品質還是好不少...

NLB 接 ALB?

AWS API Changes 上看到這個修改:「2021/09/27 - Elastic Load Balancing - 3 updated api methods」。

說明是這樣:

Adds new ALB-type target group to facilitate forwarding traffic from NLB to ALB

所以是 NLB 可以接到 ALB 嗎,這看起來讓彈性變大不少...

Google 與 Oracle 對 Java API 爭議的案子

前幾天應該很多媒體都有報導了,這邊算是整理一下看到的資料。

美國最高法院公佈的全文在「18-956_d18f.pdf」這邊可以看到,算是最重要的資料。

另外很多地方也有更新,像是維基百科上面的條目「Google LLC v. Oracle America, Inc.」。

這次的案件在軟體產業也很關注,難得可以在 Hacker News 上看到 upvote 超過四千的新聞:「Google’s copying of the Java SE API was fair use [pdf] (supremecourt.gov)」,不過裡面的討論我覺得就是鄉民拿著爆米花的感覺...

第一個重要的消息當然是 6-2 認定 fair use,並且讓聯邦法院重審 (但最高法院已經把最重要的部份拍板定案了),不過要注意的是,對於更基本的問題「API 是否有著作權」並沒有定案:

In April 2021, the Supreme Court ruled in a 6–2 decision that Google's use of the Java APIs fell within the four factors of fair use, bypassing the question on the copyrightability of the APIs. The decision reversed the Federal Circuit ruling and remanded the case for further review.

判決全文 PDF 的前面三頁多算是簡介說明這次的重點,Page 44 到 Page 62 則是反對的兩位大法官 (Clarence ThomasSamuel Alito) 所提出的異議,可以看到兩位大法官批評了 copyrightability 與 fair-use analysis 的問題。

這次的結果對軟體與網路產業影響超級大,舉個例子來說,一堆公司都有推出與 Amazon S3 相容 API 的產品 (這邊是 Network-based API)。另外 Firefox 直接拿 Chromium 的 Manifest 格式來相容降低開發者開發 extension 的成本。

之後應該可以看到大家用的更爽了...

GitHub 的 API Token 換格式

GitHub 前幾天宣佈更換 API token 的格式:「Authentication token format updates are generally available」,在今年三月初的時候有先公告要換:「Authentication token format updates」。

另外昨天也解釋了換成這樣的優點:「Behind GitHub’s new authentication token formats」。

首先是 token 的字元集合變大了:

The character set changed from [a-f0-9] to [A-Za-z0-9_]

另外是增加了 prefix 直接指出是什麼種類的 token:

The format now includes a prefix for each token type:

  • ghp_ for Personal Access Tokens
  • gho_ for OAuth Access tokens
  • ghu_ for GitHub App user-to-server tokens
  • ghs_ for GitHub App server-to-server tokens
  • ghr_ for GitHub App refresh tokens

另外官方目前先不會改變 token 長度 (透過字元變多增加 entropy),但未來有打算要增加:

The length of our tokens is remaining the same for now. However, GitHub tokens will likely increase in length in future updates, so integrators should plan to support tokens up to 255 characters after June 1, 2021.

看起來當初當作 hex string 而轉成 binary 會有問題,不過就算這樣做應該也是轉的回來的。

回到好處的部份,這個作法跟 SlackStripe 類似,讓開發者或是管理者更容易辨識 token 的類型:

As we see across the industry from companies like Slack and Stripe, token prefixes are a clear way to make tokens identifiable. We are including specific 3 letter prefixes to represent each token, starting with a company signifier, gh, and the first letter of the token type.

另外這也讓 secret scanning 的準確度更高,本來是 40 bytes 的 hex string,有機會撞到程式碼內的 SHA-1 string:

Many of our old authentication token formats are hex-encoded 40 character strings that are indistinguishable from other encoded data like SHA hashes. These have several limitations, such as inefficient or even inaccurate detection of compromised tokens for our secret scanning feature.

另外官方也建議現有的 token 換成新的格式,這樣如果真的發生洩漏,可以透過 secret scanning 偵測並通知:

We strongly encourage you to reset any personal access tokens and OAuth tokens you have. These improvements help secret scanning detection and will help you mitigate any risk to compromised tokens.