Tag: api

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 的部份快，這邊還用到了幾個服務，像是 Pushover 與 The 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 搜出來的品質還是好不少...

把 YouTube 的 Dislike 數字弄回來

最近 YouTube 也在搞事，把 Dislike 的數字拔掉了，後來在 Greasy Fork 上面找了一下，看到有兩套方法可以把數字補回來。

第一套是「Return YouTube Dislike」這個方法，從程式碼裡面可以看到是透過 API 拉出來的：

function setState() {
  cLog('Fetching votes...');
 
  doXHR({
    method: "GET",
    responseType: "json",
    url:
      "https://return-youtube-dislike-api.azurewebsites.net/votes?videoId=" +
      getVideoId(),
    onload: function (xhr) {
      if (xhr != undefined) {
        const { dislikes, likes } = xhr.response;
        cLog(`Received count: ${dislikes}`);
        setDislikes(numberFormat(dislikes));
        createRateBar(likes, dislikes);
      }
    },
  });
}

這個 API 後面應該是接 Videos: getRating 拉資料出來，但畢竟不是直接打 YouTube API (比較麻煩，需要每個使用者自己申請 API token)，這樣就有隱私的疑慮了...

另外一套是「Show Youtube Dislike Count」，看了裡面程式碼發現他是用 averageRating 反推回來：

if (likeCount >= 0) {
    const r = data.playerResponse.videoDetails.averageRating;
    const dislikeCount = Math.round(likeCount * (5 - r) / (r - 1));

    ShowDislikes(likeCount, dislikeCount);
}

不過作者有點偷懶，這邊在等待頁面生成單純用 100ms 等頁面出現，有時候還是會有 race condition (就是後面還是讀不到 XDDD)，如果懶的大修的話可以改成 1000ms 混過去，降低一些機率：

while (!isLoaded) {
    await Sleep(100);
}

另外數字很大的時候會稍微不準，但也算夠用了，先暫時用這套來頂著了...

不使用 Google 服務的 Android 手機

一樣是在 Lobsters Daily 上翻到的，去 Google 服務的 Android 系統搞法：「Lineage with microG on a Sony XA2」。

主要是看關鍵字的部份，TWRP 換掉 recovery image，然後 LineageOS 是系統底，microG 是 open source 版本的 Google 專屬 API 的相容層，Magisk 則是負責 root 相關的事情，F-Droid 是 open source 軟體的 app store，可以用他來裝 Aurora Store，就可以裝 Play Store 裡的 app。

會這樣搞的人主要還是考慮到 privacy，可以預期有不少應用程式是不會動的...

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 嗎，這看起來讓彈性變大不少...

Cloudflare 推出 Cloudflare R2 Storage，相容於 S3 API，但沒有傳輸費用

Cloudflare 宣佈了 Cloudflare R2 Storage，相容於 S3 API，但是沒有傳輸費用：「Announcing Cloudflare R2 Storage: Rapid and Reliable Object Storage, minus the egress fees」，Hacker News 上的「Cloudflare R2 storage: Rapid and reliable object storage, minus the egress fees (cloudflare.com)」可以看一下討論，裡面有負責 R2 的 PM (帳號是 greg-m) 回答一些東西。

R2 的第一個特點就是剛剛提到的傳輸費用：一般的雲端都是傳進去不用錢，但傳出來會很貴，而 R2 其中一個主打的點就是傳出來不用錢：

R2 builds on Cloudflare’s commitment to the Bandwidth Alliance, providing zero-cost egress for stored objects — no matter your request rate. Egress bandwidth is often the largest charge for developers utilizing object storage and is also the hardest charge to predict. Eliminating it is a huge win for open-access to data stored in the cloud.

另外 storage cost 也算低，S3 目前的費用是 US$0.023/GB/month (拿 us-east-1 相比)，而 R2 目前的定價是 US$0.015/GB/month：

That doesn’t mean we are shifting bandwidth costs elsewhere. Cloudflare R2 will be priced at $0.015 per GB of data stored per month — significantly cheaper than major incumbent providers.

在 durability 的部份，與 S3 都是一年 11 個 9：

The core of what makes Object Storage great is reliability — we designed R2 for data durability and resilience at its core. R2 will provide 99.999999999% (eleven 9’s) of annual durability, which describes the likelihood of data loss.

目前還沒有公開，算是先對市場放話：

R2 is currently under development — you can sign up here to join the waitlist for access.

有幾個點還蠻有趣的，第一個是 Cloudflare 自己在推的 Bandwidth Alliance 裡有不少 VPS 跟 Cloudflare 之間的流量是不計頻寬費用的，所以等於是 VPS 到 R2 不計費，而 R2 到 VPS 也不計費，但要注意 VPS 自己也都有在推 object storage。

像是 Vultr 的 US$5 方案包括了 250GB 的空間與 1TB 的頻寬，扣掉頻寬的部份 (可以透過 Cloudflare 處理)，相當於是 US$0.02/GB。

而 Linode 也類似，US$5 的方案包括了 250GB 的空間與 500GB 的頻寬，算出來也是 US$0.02/GB。

而 Backblaze 也有類似的產品 B2，US$0.005/GB/month 的儲存費用以及 $0.01/GB 的傳輸費用，但頻寬的部份也可以透過 Cloudflare 處理。

這個產品出來以後可以再看看如何，但看起來是蠻有趣的。對目前的雲端商應該還好 (因為資料進 R2 還是有費用)，但對這些 VPS 來說應該是有蠻大的衝擊...

在 AWS Summit Taiwan 2021 上講的 HashiCorp Vault

今年的 AWS Summit Taiwan 2021 是線上的形式，早在前一個月前就先預錄好，但開始的時候就忘記要宣傳一下了... 結果是在找資料的時候發現其他人有提到：「AWS實作紀錄 #2：高可用性保管服務 (2021 AWS Summit Taiwan)」。

投影片與影片如果有興趣的人可以去 AWS 活動頁面上看，或者上面提到的那篇。

這次講的主題是想要在雲端上面搭建 Vault，但又不希望自己搞一堆 High Availability 的架構，最好是雲端服務本身就有提供... 而既然是在 AWS 的場子，主要都還是以 AWS 的服務來搭建。

在這次的設計裡，Vault 的資料是放在 DynamoDB 上，然後透過 KMS 管理加密用的，這兩個服務本身都有 High Availability，所以直接用就可以了。

接下來是跑 Vault 程式的部份，這部份得自己處理 High Availability 的架構，我是用兩台很小台的 EC2 instance (t4g.nano) 在跑，這邊也可以換成 ECS 或是 EKS 的 container。

接下來把這兩台 EC2 instance 掛起來的也都是 High Availability 服務：在 EC2 instance 前面用 ELB 擋住提供 HTTP API 服務，另外這邊即使是內部用，也可以上 HTTPS (透過 ACM 掛上 HTTPS 的憑證)。

在 ELB 上看到只有一台機器活著是正常的，因為兩台機器之間是 active-standby 架構，同時間只會有一台機器在運作，而 lock 的機制是 Vault 透過 DynamoDB 實做的，不需要另外處理。

其實裡面大多數的元件都可以抽換，像是 DynamoDB 也可以用其他的服務來當儲存層，馬上可以想到的是 RDS 的 MySQL 或是 PostgreSQL。

概念上不算困難，所以投影片上主要就是給設定檔，這樣方便大家抄，不用在自己摸指令摸半天...