Tag: api

Brave 宣佈 Brave Search 完全使用自己的資料，不用 Bing 的了

Brave 宣佈 Brave Search 獨立，不再使用 Bing 的資料了：「Brave Search removes last remnant of Bing from search results page, achieving 100% independence and providing real alternative to Big Tech search」。

依照 Brave 的說明，先前大約 7% 是來自 Bing 的 API：

Every Web search result seen in Brave Search is now served by our own index. We’ve removed all search API calls to Bing, which previously represented about 7% of query results.

但只要商業模式還是廣告，我應該不會去用... 但比起目前市場上一堆包其他家 search engine 的搜尋引擎來說，這的確是個好消息。

測試 GitHub 與 AWS 可以多快偵測出外洩的 token

前幾天在 Hacker News 上看到「What happens when you leak AWS credentials and how AWS minimizes the damage (xebia.com)」這篇，原文連結在「What happens when you leak AWS credentials and how AWS minimizes the damage」這邊。原文跟 Hacker News 上的寫到東西都頗有趣的，可以分開來講。

先是原文的部份，他抓了一些時間軸：

12:33:12 – Pushed the credentials to GitHub
12:34:19 – The AWSCompromisedKeyQuarantineV2 policy is attached to the IAM user test-user by AWS
12:34:32 – Various List and Describe calls are made using the leaked credentials
12:35:08 – Received an email from AWS with the subject ‘ACTION REQUIRED: Your AWS Access Key is Exposed for AWS Account 12345678’

可以看到推上 GitHub 後，AWS 在一分七秒後就自動加上 AWSCompromisedKeyQuarantineV2 以減少災害擴大，然後再發信件通知。

這個功能可以參考 GitHub 的文件說明：「About secret scanning - GitHub Docs」。

另外在 Hacker News 上面看到有人直接把 secret scanning 當作 API 串來用 (噗)，把在 PyPI 上面掃到的 AWS secret 丟上 GitHub 觸發後續的機制：

I set up a project[1] to automatically leak AWS secrets published to the Python package index, which then triggers the secret scanning process and quarantines the keys[2]

1. https://github.com/pypi-data/pypi-aws-secrets

2. https://github.com/pypi-data/pypi-aws-secrets/blob/main/keys...

用 Perl 把 log 丟上 Slack

因為想在 Raspberry Pi 上面把一些 log 丟上 Slack，本來看到「Stream Any Log File to Slack Using curl」這篇，但發現裡面在把字串包進 JSON object 的方法太髒 (直接把 " 換成 ')，另外一方面是 Slack 已經在宣導不要用舊版的 Incoming Webhooks，所以決定用其他方式來處理。

選擇 Perl 主要是因為有一陣子沒有用 Perl 寫東西了，倒不是什麼特別的原因 (如果考慮到 Raspberry Pi 上資源有限的話，應該用 C 或是 Rust 或是 Go，但我的 Raspberry Pi 還沒忙到這種程度...)，所以決定用 Perl 來實做這個程式，把 log 檔案丟上 Slack：

這邊有些比較不太常見的選擇：

  • 不用 File::Tail 而反而是用 pipe 的方式取得 tail -F 的輸出，是因為 File::Tail 非常舊了 (2015)，實做上沒有用到 inotify 類的界面監控檔案的變化，反而是系統的 tail 有做。
  • 用 JSON::PP (pure perl 版本) 而不是 JSON 是因為 JSON::PP 在 Perl 5.14+ 後內建了，我沒有太在意效能，這也是上面放 use v5.14 的原因。
  • 這邊的 API 呼叫還是選擇了 WWW::Mechanize 是因為沒有內建的套件可以處理 HTTPS 連線 (可以參考 Perl core modules 這邊)，既然要另外安裝，就裝個支援度比較完整的 libwww-mechanize-perl 來用。

然後查了一下 // 的用法在 Perl 5.10+ 就支援了，好早...

Twitter 的 API 收費方案出爐了

從 Twitter 上看到的公告：

然後這次的 prior notice 是 30 天：

而在「Use Cases, Tutorials, & Documentation」這頁上可以看到各種方案了：

可以看到付費方案對業餘開發者其實頗不友善，現在比較不確定的是這邊 free tier 提到的 write-only 是連自己的 timeline 都不能抓，還是指不能抓其他人的... 如果是前者的話就得用其他方法跑 twitter2facebook 與 twitter2plurk 了，或是乾脆跳船了？

ChatGPT 提供正式付費的 API

OpenAI 公佈了 ChatGPT 的付費 API 了：「Introducing ChatGPT and Whisper APIs」。

比較意外的是這次的 model 價錢直接比 text-davinci-003 (GPT-3.5) 少了 90%，也就是直接 1/10 的價錢：

Model: The ChatGPT model family we are releasing today, gpt-3.5-turbo, is the same model used in the ChatGPT product. It is priced at $0.002 per 1k tokens, which is 10x cheaper than our existing GPT-3.5 models. It’s also our best model for many non-chat use cases—we’ve seen early testers migrate from text-davinci-003 to gpt-3.5-turbo with only a small amount of adjustment needed to their prompts.

看起來基本的架構是相容的，現有的 text-davinci-003 轉到 gpt-3.5-turbo 看起來不用花太多功夫？不過 API 是不同隻，不能直接轉：

We’ve created a new endpoint to interact with our ChatGPT models[.]

從 Python bindings 可以看到新的用法：

import openai

completion = openai.ChatCompletion.create(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": "Tell the world about the ChatGPT API in the style of a pirate."}]
)

print(completion)

這樣就真的就可以想像得到很多 startup 的輪替了...

Twitter 砍免費 API 的時程延到 2/13

先前在「Twitter 宣佈要廢掉免費的 API 權限」這邊有提到在 2/9 要廢掉 API free tier 的事情延期了，延到 2/13：

據說跟老闆很在意 Super Bowl，然後丟了內部信件出來有關：

本來想說今天會爛掉，剛好可以來弄弄，看起來可以拖延到週末了...

Twitter 宣佈要廢掉免費的 API 權限

昨天下午的時候看到這則官方在 Twitter 上提到的消息，要廢掉 free tier 的 API access：

但這邊提到的 paid basic tier 的價錢還沒看到公告。以「API Pricing - It’s very dark out here」這邊看到的價格，目前的 premium plan 超級貴：

這下看起來是真的得搬了，目前有好幾隻程式在上面跑 :o

讓使用者可以自己選擇 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」。

Amazon EC2 AMI 的 root volume 可以直接抽換了

這個功能等了十年以上總算是出現了，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

南韓最高法院也對 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.

整體看起來是被告的大獲全勝？