幹壞事是進步最大的原動力
之前寫過「RFC 定義的 application/problem+json (或是 xml)」，最近在找資料發現 2016 年的 RFC 7807 被 2023 年的 RFC 9457 取代了，兩份的標題都是「Problem Details for HTTP APIs」。
在「Appendix D. Changes from RFC 7807」這邊有提到做了什麼修改，看起來有三點：
Section 4.2 introduces a registry of common problem type URIs
Section 3 clarifies how multiple problems should be treated
Section 3.1.1 provides guidance for using type URIs that cannot be dereferenced
看起來大骨架沒有變，主要是補充了一些不足而已...
OpenAI 在「Introducing Structured Outputs in the API」這邊提到目前的 JSON mode 不能保證 schema 的正確性：
While JSON mode improves model reliability for generating valid JSON outputs, it does not guarantee that the model’s response will conform to a particular schema.
而現在新的 model 可以了：
Today we’re introducing Structured Outputs in the API, a new feature designed to ensure model-generated outputs will exactly match JSON Schemas provided by developers.
新的 model 代碼是 gpt-4o-2024-08-06 這組，而且又降價了：
By switching to the new
gpt-4o-2024-08-06, developers save 50% on inputs ($2.50/1M input tokens) and 33% on outputs ($10.00/1M output tokens) compared togpt-4o-2024-05-13.
這個功能可以解掉不少 workaround...
在「Show HN: Drop-in SQS replacement based on SQLite (github.com/poundifdef)」這邊看到的，就如同標題所提到的，是個 Amazon SQS 的相容 API 實作，專案在 GitHub 上的「SmoothMQ」這邊。
底層是 SQLite，實作語言是用 Go，然後有 web interface 可以觀察與管理。
不過 Amazon SQS 的 API 層有特別優秀嗎...？而且大多數的情況都不是直接呼叫，應該是透過 message queue sdk 處理，像是作者自己寫的 sample code 用 Celery？如果是 Celery 的話後面應該有很多 backend 可以抽換...
也許在測試的角度用的到？
前幾天很熱門的「An Anonymous Source Shared Thousands of Leaked Google Search API Documents with Me; Everyone in SEO Should See Them」消息，裡面提到有拿到一份疑似 Google 搜尋引擎的內部 API 文件， 可以證實有很多 Google 搜尋引擎的運作與 Google 對外宣稱的不符。
作者找了業內人士幫忙分析 (他自己說他先前也在碰 SEO 這塊，但是已經離開這個行業六年了)：
Next, I needed help analyzing and deciphering the naming conventions and more technical aspects of the documentation. I’ve worked with APIs a bit, but it’s been 20 years since I wrote code and 6 years since I practiced SEO professionally.
包括作者的一些 Google 朋友，或是 ex-Googler 都確認這份文件符合 Google 內部的文件規範要求，另外裡面的元素編排也都很像是 Google 的文件。
本來以為事情大概就這樣，後續應該就是會有很多人從這份文件分析 Google 有哪些 SEO 的偏好，找出哪些東西與 Google 宣稱的不符。
不過事情突然有個意外的轉折，Google 本來一直是「拒絕評論」的態度，但突然承認這份文件的確是他們內部文件：「Google confirms the leaked Search documents are real」。
"We would caution against making inaccurate assumptions about Search based on out-of-context, outdated, or incomplete information," Google spokesperson Davis Thompson told The Verge in an email. "We’ve shared extensive information about how Search works and the types of factors that our systems weigh, while also working to protect the integrity of our results from manipulation."
反正也沒有人會相信 outdated 了，但可以預想的是 Google 的搜尋結果應該又會變差，因為會有更多 SEO 垃圾開始想辦法衝排名上去...
在「API Shouldn't Redirect HTTP to HTTPS (jviide.iki.fi)」這邊看到的，原始文章在「Your API Shouldn't Redirect HTTP to HTTPS」這邊。
仔細想一下沒錯，API 應該要一開始就被正確設定，所以要 fail fast。
另外在 id=40505525 這邊還提到了透過 HTTP 的 token 會自動被 revoke 掉，這個作法也很漂亮：
The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.
另外一個想法是直接不聽 port 80，不過這點在 Endpoint 的 IP 不是自己專用的情況下不一定能做到 (像是大多數的 CDN 環境)。
的確有戳中我手上預先準備好的 nginx config，來想看看怎麼改會比較好... 也許改成整個傳回 403，只開 /.well-known/acme-challenge/ 讓 ACME (Let's Encrypt) 的 HTTP-01 認證可以過。
看到「Popover API (developer.mozilla.org)」這個討論，引用的資料是 MDN 上面的「Popover API」，從名字也可以看出來與 pop over 有關 (話說查單字發現 popover 這個詞在字典裡居然是泡芙，英文維基百科上的 Popover 也可以看到...)。
Anyway，馬上有想到的是 modal 類的操作，在 MDN 上面的文件裡面有範例，可以用純 HTML 的方式操作：
<button popovertarget="mypopover">Toggle the popover</button> <div id="mypopover" popover>Popover content</div>
效果就是在畫面正中央出現，預設有 border。
另外也可以透過 JavaScript 的方式操作：
HTMLElement.togglePopover()
MDN 文件把這個功能標成 Baseline 2024：
Since April 2024, this feature works across the latest devices and browser versions. This feature might not work in older devices or browsers.
因為是很新的東西 (就支援度來說)，要注意如果使用者是舊版瀏覽器的 fallback 行為。
翻文件底部的支援情況，可以看到最後支援的主流瀏覽器是 Firefox 125 (2024/04/16)，而 Firefox 還是有人會用 ESR 版本，目前還是 115，但照著 Firefox ESR 的節奏，應該是暑假會出下一版，但如果是現在要用的話，應該得考慮用 polyfill 去支援不原生支援的瀏覽器。
三年前的文章「How the Web Audio API is used for audio fingerprinting」講解了 AudioContext 是怎麼被拿來 fingerprint 的，最近在「How We Bypassed Safari 17's Advanced Audio Fingerprinting Protection」這篇看到的。
AudioContext 可以完全跟錄音設備無關，單純計算，然後因為不同瀏覽器實作上面有差異，就被拿來當作 fingerprint 了。
文章裡介紹的方法是透過 Oscillator 產生 440Hz 的正弦波，然後過 Compressor 降低音量 (運算)：
The Web Audio API provides a DynamicsCompressorNode, which lowers the volume of the loudest parts of the signal and helps prevent distortion or clipping.
降低音量的運算再這塊各家的實作不同，就能夠區分不同的瀏覽器 (甚至是版本)：
Historically, all major browser engines (Blink, WebKit, and Gecko) based their Web Audio API implementations on code originally developed by Google in 2011 and 2012 for the WebKit project.
Since then browser developers have made a lot of small changes. These changes, compounded by the large number of mathematical operations involved, lead to fingerprinting differences. Audio signal processing uses floating point arithmetic, which also contributes to discrepancies in calculations.
Additionally, browsers use different implementations for different CPU architectures and OSes to leverage features like SIMD. For example, Chrome uses a separate fast Fourier transform implementation on macOS (producing a different oscillator signal) and other vector operation implementations on different CPU architectures (used in the DynamicsCompressor implementation). These platform-specific changes also contribute to differences in the final audio fingerprint.
而這東西平常也不會用到，所以對 Tor Browser 這種特別重視 privacy 的瀏覽器就直接關掉他了：
Tor
In the case of the Tor browser, everything is simple. But unfortunately, web Audio API is disabled there, so audio fingerprinting is impossible.
在 Hacker News 上看到「How to find the AWS account ID of any S3 bucket (tracebit.com)」這篇，作者利用不同的額外條件，讓 S3 bucket 產生不同的 response，進而取得 AWS 的 Account ID。
首先是先確定 S3 bucket 在哪一區，這個部分比較簡單，即使是 denied response 也會附上 x-amz-bucket-region 這個資訊。
接下來是在對應的區域建立 VPC 以及 VPC Endpoint for S3，接著準備一台 EC2 instance 確認是否透過 VPC Endpoint for S3 存取 Amazon S3 的資料。
接下來的重點就在「Modify the VPC Endpoint policy to determine whether the account ID of the target bucket starts with "0"」這段了，建立一個 policy，限制只能存取 Account ID 是 0* 的 S3 bucket：
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "s3:*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*",
"Condition": {
"StringLike": {
"s3:ResourceAccount": "0*"
}
}
}
]
}
然後發 request 去要檔案，理論上在 command line 這邊都會收到 denied 的訊息，但在 CloudTrail 裡面會有兩種不同的情境，如果 CloudTrail 裡面有這筆記錄，表示 Account ID 是 0*；如果沒有的話，表示 Account ID 不是 0*：
If we find our request in CloudTrail, it means that the VPC Endpoint policy permitted the request - i.e. the Account ID of the bucket starts with 0. If we don't find the request, then the VPC Endpoint policy blocked the request - i.e. the Account ID of the bucket does not start with 0.
有了這個破口後，後續的事情就可以自動化了，平行測試以及二分搜尋法拿出來用就可以加速進行。
而 AWS 的 Account ID 雖然不是敏感資訊，但能挖出來還是頗... 有趣的？
在 Mastodon 上面看到有 bridge service 可以接 X (Twitter) 的內容：
像是 elonmusk 的 X (Twitter) 可以用 @elonmusk@bird.makeup 這個位置訂閱。
程式本身是 AGPLv3，但是是用 .NET Core 寫的，如果要 self-hosted 的話得研究一下了：「bird.makeup」。
然後從 README.md 看起來是用 X (Twitter) 自家的 undocumented API，避免了正式 API 的 rate limit 問題：
Twitter API calls are not rate-limited
首先是「Mixtral of experts」這個公告，Mistral 推出了新的 model，叫做 Mixtral 8x7B。這是一個 46.7B 的 model，但計算每個 token 時只需要計算 12.9B 的值：
Concretely, Mixtral has 46.7B total parameters but only uses 12.9B parameters per token. It, therefore, processes input and generates output at the same speed and for the same cost as a 12.9B model.
這就可以大幅降低計算需要的量，卻可以達到與 Llama 2 70B 或是 GPT-3.5 同一個等級的品質：
另外在「Mistral: Our first AI endpoints are available in early access (mistral.ai)」這邊看到官方推出了 API，正式的公告在「La plateforme」這邊，同時價錢也已經出來了：「Pricing」。
依照官方的說明，Mistral Small 用的是上面提到的 Mixtral 8x7B，所以表現的數字是一樣的。另外一個 Mistral Medium 沒有提到太多細節，只丟出簡單的說明：
然後 API 看起來會相容 OpenAI 家的 API：
Our API follows the specifications of the popular chat interface initially proposed by our dearest competitor.
Hacker News 上面的 id=38599156 有整理出重點，把價格數字都換算成 1m output 的費用，可以看到表現相近的 Mistral Small (Mixtral 8x7B) 與 GPT-3.5 在價錢上也差不多：
Per 1 million output tokens:
Mistral-medium $8
Mistral-small $1.94
gpt-3.5-turbo-1106 $2
gpt-4-1106-preview $30
gpt-4 $60
gpt-4-32k $120
沒有拿 GPT-4 的數字來比，代表 Mistral Medium 與 GPT-4 有一定的差距，這點也可以從價錢上面看出來。
不過我更在意的是 Mistral Medium 的 model 會不會放出來？