Twitter 的 Tor Onion 位置

Hacker News 上看到「Twitter is now available on Tor (help.twitter.com)」這篇,講 Twitter 官方的說明裡面有提到 Tor 的 Onion 服務:「About twitter.com supported browsers」。

會用到的網址分別是:

看起來這些開頭為 twitter 的 domain 是撞出來的... 不過還是討問題,如果已經可以用 Tor 的話,exit node 應該夠用?

為資料庫提案新的 UUID 格式

前幾天在 Hacker News Daily 上看到的東西,今年四月的時候有人針對資料庫提案新的 UUID 格式:「New UUID Formats – IETF Draft (ietf.org)」。

在 draft 開頭有說明這個提案的目標:

This document presents new time-based UUID formats which are suited for use as a database key.

A common case for modern applications is to create a unique identifier for use as a primary key in a database table. This identifier usually implements an embedded timestamp that is sortable using the monotonic creation time in the most significant bits. In addition the identifier is highly collision resistant, difficult to guess, and provides minimal security attack surfaces. None of the existing UUID versions, including UUIDv1, fulfill each of these requirements in the most efficient possible way. This document is a proposal to update [RFC4122] with three new UUID versions that address these concerns, each with different trade-offs.

另外在 Hacker News 上有人整理出來,可以直接理解提案所提出的新格式是什麼:

A somewhat oversimplified summary of the new UUID formats:

UUID6: a timestamp with a weird epoch and 100 ns precision like in UUID1, but in a big-endian order that sorts naturally by time, plus some random bits instead of a predictable MAC address.

UUID7: like UUID6, but uses normal Unix timestamps and allows more timestamp precision.

UUID8: like UUID7, but relaxes requirements on where the timestamp is coming from. Want to use a custom epoch or NTP timestamps or something? UUID8 allows it for the sake of flexibility and future-proofing, but the downside is that there's no standard way to parse the time from one of these -- the time source could be anything monotonic.

這在不同的 storage engine 上面會有不同的討論,這邊先討論 MySQL 系列的 InnoDB,至於 PostgreSQL 的 engine 以及其他資料庫系統,就另外讓更熟悉的人討論了。

InnoDB 採用了 clustered index (可以參考「Database index」這邊的說明),也就是資料本體是以某種定義的大小順序存放。

在 InnoDB 裡面則是用 primary key 的順序來存放資料 (沒有指定 primary key 時會有 fallback 行為),其他的 unique key 與 index key 則是指到 primary key,所以你可以看到 primary key 的大小也會影響到其他的 index key。

所以 128 bits 的 UUID 在大型的 MySQL ecosystem 實在不怎麼受歡迎,在 2010 年的時候 FlickrTwitter 都有發表過 ticket system:「Ticket Servers: Distributed Unique Primary Keys on the Cheap」、「Announcing Snowflake」,兩個系統有不同的需求,但都是產生 64 bits 的 unique id。

其中 Flickr 的系統算是很簡單的,沒有要保證時間順序 (i.e. 先取的號碼一定比較小,以及後取的號碼一定比較大),就用兩台 MySQL 跑 active-active 架構,然後錯開產生的值:

TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1

TicketServer2:
auto-increment-increment = 2
auto-increment-offset = 2

到現在還是一個蠻簡單的解法...

Twitter 推出打賞功能

Twitter 推出了 Tip Jar,也就是打賞功能:「Introducing Tip Jar」。

支援多種支付方式,包括 BandcampPatreon 這種創作者平台,另外也支援 Cash AppPayPalVenmo 這些一般性的金流平台。也因為實際上的金流不通過 Twitter 本身,所以就只有金流平台會收取的手續費:

The services* you can add today include Bandcamp, Cash App, Patreon, PayPal and Venmo. Twitter takes no cut.

看起來像是帶去其他 app 而已,所以不會有 iOSAndroid 的 30% 或是 15% 的問題。

Twitter 的 MFA 可以加入多支 YubiKey 了

我手上有好幾隻 YubiKey,目前幾個有在用的服務都有支援同時綁定多組 U2F/WebAuthn 的能力 (像是 FacebookGitHub)。

Twitter 一開始推出的時候也可以支援多組,但在去年 2020 年八月的時候發現這個功能被拔掉,只能放一把進去。

我自己開了一張 ticket 定時回頭看一下有沒有修正,剛剛定期回顧發現這個功能被加回來了,而且官方的文件上也加上去了:「How to use two-factor authentication」。

翻了一下 Internet Archive 上的資料,看起來是 3/113/16 中間更新文件的...

手上有多把 security key 的人也可以處理一下。

印度威脅要逮捕 Facebook、WhatsApp 與 Twitter 的員工

The Wall Street Journal 上看到的,印度政府威脅 FacebookWhatsAppTwitter,如果不配合政府的要求提供資料並將內容下架,將會逮捕他們在印度的員工:「India Threatens Jail for Facebook, WhatsApp and Twitter Employees」。

這應該是透過上個月才剛過的法令:「Facebook, WhatsApp and Twitter Face New Rules in India」。

印度的市場太大,各家社群網站都想要進去,造就了政府的有足夠的能力跟這些大公司談判,而且是具有壓制性的力量。

在去年殺完 Tiktok 後,上個月擴權然後這個月反過來殺這些美國的企業。

美國政府不知道會幫到什麼程度...

Elon Musk 退訂美國總統的 Twitter 帳號

先前因為 cjin 的這則推,跑去追蹤了 @BigTechAlert 這個帳號:

@BigTechAlert 這個帳號會把名人以及大企業的 Twitter 帳號所追蹤與推追蹤的行為找出來,然後發表在 Twitter 上面。

平常 @BigTechAlert 所抓出來的追蹤與退追大家也都習以為常,你去看 @BigTechAlert 的帳號也可以發現沒什麼 retweet & like。

但前幾天這則退訂通知讓不少人 retweet & like,因為是 Elom Musk 退追了 @POTUS 帳號 (也就是 President of the United States):

退追的真實原因不知道,但看到純粹覺得很有趣...

AWS 提供程式,可以掃出有哪些 RDS 的憑證需要更新

先前在「AWS 的 CA 更新 (CA-2019),將會影響與資料庫相關的服務」這邊提到了 AWSRDS 因為 Root Certificate 快要過期,需要更新到 CA-2019。

剛剛在 Twitter 上看到 Jeff Barr 提到了一個可以直接列出有哪些機器需要更新的工具:

程式放在 GitHub 上的 aws-samples/rds-ssl-update,另外看到一個有趣的授權條款,叫做 MIT-0 License,是 AWS 自己改的一個授權版本,拿掉了 MIT License 裡面的這段:

subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

也就是要求要引用授權條款的部份被拿掉,不過我還是比較喜歡 BSD license,尤其是 3-clause 的版本...