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.

最近很熱鬧的 New York Times 退訂截圖

最近很熱鬧的 New York Times 的退訂過程截圖在這邊,可以看到滿滿的 Dark pattern 想辦法讓使用者難以退訂:「Before buying a NYT subscription, here's what it will take you to cancel it.」,這點在 Hacker News 上的討論也可以看一下:「Before buying a NYT subscription, here's what it'll take to cancel it (imgur.com)」。

我在看的時候想到美國好像有通過法律,要求租用與退訂流程的對等性,查了一下資料發現理解不正確,之前看到的新聞應該是加州州政府通過的法令:「SB-313 Advertising: automatic renewal and continuous service offers.(2017-2018)」。

2018 年法令生效當時也有報導,裡面講的比較白話:「Companies must let customers cancel subscriptions online, California law says」,結果看到這則報導裡面給的範例時馬上笑出來,因為又是 New York Times,看起來是就是慣犯 XDDD

One person tweeted about trying to cancel a New York Times subscription on the phone and being put on hold for 15 minutes -- twice.

在 Hacker News 的討論裡有提到,美國的使用者可以考慮用 Privacy 這個虛擬信用卡服務,對於這種很搞事的 subscription 直接關閉對應的信用卡帳號就好。

台灣之前有遠東銀行提供 Mastercard InControl 方案,但看起來到去年年底也不提供了:「MasterCard inControl 網路交易虛擬卡號申請服務110年1月1日起終止公告」。

NordVPN 綁架使用者的方式...

Hacker News Daily 上看到「NordVpn disables features when you turn off auto-renew」這個,這也太厲害了:

NordVPN 設計成只要關掉 auto-renewal 就直接拔掉一些功能,一臉 WTF...

Hacker News 的「NordVPN disables features when you turn off auto-renew (reddit.com)」看到這段提出來的論點蠻有趣的,當作一個參考觀點:

By now these VPN providers are like toothpaste, diapers or soft drinks: completely undifferentiated between competitors, and so only able to maintain their market share by spending loads on marketing. Of course the company with most egregious dark patterns and aggressive churn dampening wins.

Thankfully a tube of toothpaste doesn't allow implementing dark patterns like this... yet.

SQL Antipatterns: Avoiding the Pitfalls of Database Programming

標題裡是說這本書:「SQL Antipatterns: Avoiding the Pitfalls of Database Programming」,在 2010 年出版的書。

我是在 Hacker News Daily 上看到「Ask HN: What are some examples of good database schema designs?」這篇,裡面提到了這本書,看了一下章節看到只有 USD$25 就馬上先買起來丟到 Kindle 裡面...

這不是給資料庫初學者看的書,主要的讀者是對於「標準」夠熟 (學校教的那些理論基礎,像是各種 index 的底層結構,正規化的方法,以及正規化的原因),然後也有一些實務經驗後的開發者。

因為裡面把常遇到的問題,與可能的解決方式 (通常都違反當初在學校學的理論基礎) 整理成這本書,在底子還沒打穩前跑來看這本書並不是個好主意...

另外裡面雖然不一定有提到,但有蠻多技巧其實是用在「為了效能而不則手段」的情境下,所以這些內容對於想要調校比較大的網站應該也是很有幫助。

讓手機上瀏覽器自動帶出數字鍵盤的方式

在「HTML attributes to improve your users' two factor authentication experience」這邊看到關於讓使用者輸入 2FA (通常是數字) 比較流暢的設定。

原始是上面這張這樣,目標是希望下面這張這樣,當透過 SMS 2FA 時可以提供選項直接貼上,而且也自動帶出數字鍵盤:

給出的幾個重點在於 inputmodepattern 以及 autocomplete

<input
  type="text"
  name="token"
  id="token"
  inputmode="numeric"
  pattern="[0-9]*"
  autocomplete="one-time-code"
/>

查了一下 caniuse.com 上面的支援度,pattern 基本上都支援了,autocomplete 在這邊用到的 one-time-code 基本上也沒問題,只有 inputmode 這邊支援度比較差,IE11 (基本上不會更新了)、FirefoxSafari 沒支援。

Amazon Redshift 會自動在背景重新排序資料以增加效能

Amazon Redshift 的新功能,會自動在背景重新排序資料以增加效能:「Amazon Redshift introduces Automatic Table Sort, an automated alternative to Vacuum Sort」。

版本要到更新到 1.0.11118,然後預設就會打開:

This feature is available in Redshift 1.0.11118 and later.

Automatic table sort is now enabled by default on Redshift tables where a sort key is specified.

重新排序的運算會在背景處理,另外帶一些行為學習分析:

Redshift runs the sorting in the background and re-organizes the data in tables to maintain sort order and provide optimal performance. This operation does not interrupt query processing and reduces the compute resources required by operating only on frequently accessed blocks of data. It prioritizes which blocks of table to sort by analyzing query patterns using machine learning.

算是丟著讓他跑就好的東西,升級上去後可以看一下 CloudWatch 的報告,這邊沒有特別講應該是還好... XD

EC2 推出用 machine learning 協助 auto scaling 控制的功能...

AWSEC2 上推出了用 machine learning 協助 auto scaling 控制的功能:「New – Predictive Scaling for EC2, Powered by Machine Learning」。

最少給他一天的資料 (然後他會每天重新分析一次),接著會預測接下來的 48 小時的使用行為:

The model needs at least one day’s of historical data to start making predictions; it is re-evaluated every 24 hours to create a forecast for the next 48 hours.

所以是個學 pattern 然後預先開好機制等著的概念...

透過預測增加服務穩定性的概念... 如果本來就跑得好好的 (也就是靠 resource-based metric 觸發機器數量的方式跑得很好),就未必需要考慮這個方案了。

目前支援的區域中,東京不在列表內,不過其他常見的區域都支援了:

Predictive scaling is available now and you can starting using it today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Singapore) Regions.

Netflix 的 FrameScope,將效能資料轉成 2D 圖片

Netflix 丟出了 FlameScope,另外一種顯示效能的工具,將效能資料轉成 2D 圖片:「Netflix FlameScope」。

We’re excited to release FlameScope: a new performance visualization tool for analyzing variance, perturbations, single-threaded execution, application startup, and other time-based issues.

然後這個工具同樣是發明火焰圖的 Brendan Gregg 與他的同事 Martin Spier 的作品:

FlameScope was developed by Martin Spier and Brendan Gregg, Netflix cloud performance engineering team. Blog post by Brendan Gregg.

火焰圖 (flame graph) 就是這個:

這次推出的是這樣的圖:

其實是每秒切一次 offset 做出來的圖:

就可以很簡單的看出來哪些區塊以及 pattern 是熱點:

利用 CloudFlare 的 reCAPTCHA 反向找出真正的 Tor 使用者

Cryptome 這邊看到可能可以被拿來用的技巧:「Cloudflare reCAPTCHA De-anonymizes Tor Users」。

Tor 使用者連到 CloudFlare 上時,常常會出現 reCAPTCHA 的提示,要求你驗證,而這個驗證過程的 traffic pattern 太龐大而且很明顯,當情治單位同時可以監控 CloudFlare 的上游 (像是「Airtel is sniffing and censoring CloudFlare’s traffic in India and CloudFlare doesn’t even know it.」這篇提到的問題) 或是監控 Tor 的 exit node 的上游,再加上同時監測使用者可能的 ISP,就可以對照湊出使用者:

Each click on one of the images in the puzzle generates a total of about 50 packets between Tor user's computer and the Cloudflare's server (about half are requests and half are real-time responses from the server.) All this happens in less than a second, so eventual jitter introduced in onion mixing is immaterial. The packet group has predictable sizes and patterns, so all the adversary has to do is note the easily detectable signature of the "image click" event, and correlate it with the same on the Cloudflare side. Again, no decryption required.

短短的一秒鐘內會產生 50 個封包,而且 pattern 很清楚...