Facebook 上貼的所有的連結都是公開的

tl;dr:Facebook 認為這個功能是 feature,不是 bug。

在「Why you shouldn’t share links on Facebook」這邊作者發現在 Facebook 上貼的「任何一個連結」都會產生 object id,而任何一個 object id 都可以直接取得 url,無論權限設定,像是這樣:

而 Facebook 認定這是 feature 而非 bug:

可以想像 NSA 之類的單位與地下組織開始狂掃...

PostgreSQL 對 Vacuum 效能的改善

在「No More Full-Table Vacuums」這邊提到了 PostgreSQL 在 vacuum 時效能的大幅改善,尤其是大型資料庫在 vacuum 時需要對整個表格從頭到尾掃一次以確保 transaction id 的正確性:

Current releases of PostgreSQL need to read every page in the database at least once every 2 billion write transactions (less, with default settings) to verify that there are no old transaction IDs on that page which require "freezing".

這動作在資料量大的機器上就會吃大量資源導致各種討厭的現象:

All of a sudden, when the number of transaction IDs that have been consumed crosses some threshold, autovacuum begins processing one or more tables, reading every page. This consumes much more I/O bandwidth, and exerts much more cache pressure on the system, than a standard vacuum, which reads only recently-modified page.

而作者送了 patch 改成只會讀還沒搞定的部份:

Instead of whole-table vacuums, we now have aggressive vacuums, which will read every page in the table that isn't already known to be entirely frozen.

要注意的是,agreesive vacuum 相較於 vacuum 會多吃很多資源,但可以打散掉 (有點像一次大 GC 導致 lag 與多次 minor GC 讓程式反應時間變得比較順暢的比較):

An aggressive vacuum still figures to read more data than a regular vacuum, possibly a lot more. But at least it won't read the data that hasn't been touched since the last aggressive vacuum, and that's a big improvement.

這個功能預定在 PostgreSQL 9.6 出現,不知道會不會變 default...

新的 AWS 帳號將會自動啟用 Long EC2 Resource ID

新的 AWS 帳號將會自動啟用長版的 Resource ID:「New accounts default to long EC2 resource IDs on March 7」。

還是可以 opt-out 改回來,不過官方還是建議儘量用長的 ID 測試,因為今年年底將全面強迫使用:

We recommend testing longer IDs before transitioning; however, if you have not yet tested your systems for compatibility with the longer format, you still have the option to opt out and receive shorter IDs until early December 2016.

EC2 與 ELB 將會有更長的 Resource ID

EC2ELB 將會有更長的 Resource ID:「Heads-Up – Longer EC2 & EBS Resource IDs Coming in 2016」。

重點在這段:

The new IDs will be the same format as existing IDs, but longer. The current ID format is a resource identifier followed by an 8-character string, and the new format will be the same resource identifier followed by a 17-character string.

本來是 8 chars,之後會變成 17 chars。而用 SDK 的人只要更新到新版就可以了:

The SDKs are already compatible with longer IDs and don’t require any updates.

預定在 2016 年發生:

My colleague Angela Chapman wrote the guest post below to make you aware of longer instance, reservation, volume, and snapshot IDs that we will be rolling out in 2016.

新的 HTTPS 攻擊:BREACH Compression Attack

也是一個禮拜前的消息,在 Slashdot 上看到對 HTTPS 的新攻擊,目前沒有好解法,NSA 應該開心到爆炸:「BREACH Compression Attack Steals SSL Secrets」。

說明可以參考「Vulnerability Note VU#987798 BREACH vulnerability in compressed HTTPS」這篇。

假設你的 ISP 想要抓出你的 Facebook (HTTPS) session id 或是 CSRF token (只要是有能力在中間攔截封包並修改資料的團體都可以,這邊以 ISP 為例),作法是針對 HTTP 頁面值入 script,讓你的瀏覽器對 https://www.facebook.com/ 發出大量 request,藉由觀察這些 HTTPS 的長度就有機會取得 session id (或 CSRF token)...

CERT 的 security advisory 上是寫:

With a token of length 32 and a character space of size 16 (e.g. hex), the attacker needs an average of approximately 1,000 request if no recovery mechanisms are needed. In practice, we have been able to recover CSRF tokens with fewer than 4,000 requests. A browser like Google Chrome or Internet Explorer is able to issue this number of requests in under 30 seconds, including callbacks to the attacker command & control center.

四千次就搞定了... 太!歡!樂!了!

John Carmack 加入 Oculus

上個禮拜的新聞,John Carmack 加入 Oculus:「John Carmack Joins Oculus as CTO」。

身為 id Software 創辦人 (以及電玩遊戲領域超重量級人物),另外也是 Open Source 的推廣者,近年來把心力放在 VR 技術上 (不論是軟體還是硬體),加入 Oculus VR 明顯是繼續往目前的理想邁進... (順便賺賺麵包錢),而這位大師能夠帶給 VR 領域什麼樣的刺激,接下來這幾年就很值得看看了...

喔對,每次提到 John Carmack,當然就要提 1995 年 28 吋 1920x1080 的螢幕:

蘋果的 Two-Factor Authentication...

在「Apple Adds Two-Factor Authentication to iTunes Accounts」看到蘋果支援 Two-Factor Authentication。蘋果官方的 KB 在「Apple ID: Frequently asked questions about two-step verification for Apple ID」這邊。

看說明是透過簡訊進行認證,類似於 Facebook 的方式。不過拿了自己的帳號測試發現還看不到這個選項,應該是全球逐步開放?

MySQL 5.6 的 GTID...

看到 Percona 的人在討論 MySQL 5.6 的 GTID (Global Transaction ID) 功能,剛剛就實際到 AWS 上開了兩台 m1.large 測試:「How to create/restore a slave using GTID replication in MySQL 5.6」。

要測試 GTID,因為剛出來沒多久,沒有多少文件可以看。MySQL 官方的「Replication with Global Transaction Identifiers」是必讀的文件。查 MySQL 官方文件時可以發現 5.6.9 (RC) 到 5.6.10 (GA) 其實還是改了不少變數名稱,如果在網路上找舊文章照抄是不會動的...

先提結論,Galera Cluster 畢竟出來很久了,成熟度比 GTID 高,建議現在先觀望一陣子,至少等 best practice 出來後再進場測試...

之前的 MySQL replication 有很多方法可以在不停機,或是停的時間很短的情況下把第一份 slave 資料與 replication 資訊生出來,舉例來說:

  • 系統如果用 InnoDB,可以用 Percona Xtrabackup 拉出。
  • 系統如果用 XFS + LVM,可以用 FLUSH TABLES WITH READ LOCK + XFS freeze + snapshot 功能拉出。
  • 甚至直接用空的 slave 跑 pt-table-sync...

但目前 MySQL 官方對 GTID 給的方式是 read only + mysqldump,這就算用 xtrabackup 也應該快不到哪吧... 這幾個月應該會一直有文章出現,裡面應該會有偷吃步的方法,看到再來測試看看 :o

John Carmack 在 1995 年的 28" 1920×1080 螢幕...

有點舊的消息,之前看到有人提但當時沒有寫 blog,最近又看到這張圖...

這是 John Carmack (id Software 創辦人) 在 1995 年所拍攝的 1920×1080 CRT 螢幕,吃電能力高達 180W:「John Carmack coded Quake on a 28-inch 16:9 1080p monitor in 1995」...

以時間點來算,這應該是開發 Quake 系列所用的螢幕...