Home » 2016 » September (Page 3)

Google Allo 減弱本來的安全設計

Google Allo 減弱了本來的安全設計:「Google backs off on previously announced Allo privacy feature」。

藉由修改預設行為減弱:

The version of Allo rolling out today will store all non-incognito messages by default — a clear change from Google’s earlier statements that the app would only store messages transiently and in non-identifiable form.

本來的預設值不會記錄身份,現在會了。而 The Verge 的猜設是這樣可以減少其他類似的情況,藉以討好政府:

That leaves Google with much less danger of the kind of legal showdown Apple faced in San Bernardino and WhatsApp currently faces in Brazil.

PostgreSQL 上,直接將 SSD 的內容送到 GPU 上,加速讀取速度

PostgreSQL 上針對讀取檔案到 GPU 上的成果:「GpuScan + SSD-to-GPU Direct DMA」(日文版)、「(EN) GpuScan + SSD-to-GPU Direct DMA」(英文版)。

主要的原因在於雖然已經有 PGStorm 讓 PostgreSQL 把運算丟到 GPU 上加速,但從 disk 讀到 GPU 這段還是有改善的空間:

PG-Strom that is an extension of PostgreSQL to off-load multiple SQL workloads on GPU devices, transparently. It has been developed for four years, and now supports simple scan, tables join, aggregation and projection.
Its prime focus is CPU intensive workloads, on the other hands, it didn't touch storage subsystem of PostgreSQL because the earlier version of PG-Strom assumes all the data set shall be pre-loaded onto physical memory. No need to say, we had a problem when we want to process a data-set larger than physical RAM.

這是成果,可以看到速度快了一倍以上:

這對資料量超過 RAM 大小時的處理會非常有幫助 (因為會有大量的 disk i/o 發生)。

Dropbox 儲存密碼的方式

記得 Dropbox 前陣子才強迫所有使用者重設密碼:「The Dropbox hack is real」,官方的報告在這:「Resetting passwords to keep your files safe」,當時洩漏出來的資訊可以知道 2012 年的時候 Dropbox 用的是 SHA1:

What we've got here is two files with email address and bcrypt hashes then another two with email addresses and SHA1 hashes.

三個多禮拜候,Dropbox 說明了現在的密碼儲存策略:「How Dropbox securely stores your passwords」,現在是先 SHA512,再 bcrypt,然後存在資料庫裡時使用 AES256 保護:

比較特別一點的是先 SHA512 的部份,除了 72bytes 常見限制外,另外一個原因是為了避免 DoS,不過還是覺得有點怪就是了:

Other implementations don’t truncate the input and are therefore vulnerable to DoS attacks because they allow the input of arbitrarily long passwords.

而 AES256 的部份則是確保就算 SQL injection 或是其他方式將儲存的密碼撈出去後,也還有相當程度的保護能力。

ING Bank 在羅馬尼亞的機房出事...

ING Bank 在羅馬尼亞的機房發生資料損毀:「A Loud Sound Just Shut Down a Bank's Data Center for 10 Hours」。

不過原因是因為火災測試時噴發的音量太大,導致硬碟故障 XDDD

ING Bank’s main data center in Bucharest, Romania, was severely damaged over the weekend during a fire extinguishing test. In what is a very rare but known phenomenon, it was the loud sound of inert gas being released that destroyed dozens of hard drives. The site is currently offline and the bank relies solely on its backup data center, located within a couple of miles’ proximity.

報導給了個測試影片,示範超大的音量會對硬碟有什麼影響:

OpenType Font Variations

AdobeAppleGoogle,以及 Microsoft 聯手推出新的 OpenType 規格,讓字型變得更小:(沒有找到 Apple 的新聞稿...)

Google 給了兩個範例:

Adobe 也給了範例:

藉由額外的定義來描述字的各種變化,而不是直接設計多個字型塞進檔案裡。這樣可以減少字型的大小。

Google 研發出的 BBR: Congestion-Based Congestion Control

Google 針對 TCP 的 congestion control 研究出了新的方法,是個純 sender-side 的演匴法,可以讓現有的 internet 直接換上去使用:「[net-next,14/14] tcp_bbr: add BBR congestion control」。

在 long-lived TCP connection 愈來愈普及後 (像是 HTTP/2),TCP 連線的最佳化可以用統計模型來計算,這也就是 BBR 的想法:

In a nutshell, BBR creates an explicit model of the network pipe by sequentially probing the bottleneck bandwidth and RTT. On the arrival of each ACK, BBR derives the current delivery rate of the last round trip, and feeds it through a windowed max-filter to estimate the bottleneck bandwidth. Conversely it uses a windowed min-filter to estimate the round trip propagation delay. The max-filtered bandwidth and min-filtered RTT estimates form BBR's model of the network pipe.

不過 QUIC 不是也開始有進展了嗎?(參考「Google Chrome 52 預設開啟了更快的 QUIC (被戲稱為 TCP/2)」這篇)

感覺 QUIC 解決的比較徹底,不過 443/udp 的 firewall 問題的確也是個需要時間解決的課題...

關於 Sully (薩利機長:哈德遜奇蹟) 的資料

薩利機長:哈德遜奇蹟》講的是「全美航空1549號班機事故」,有不少資料可以先看過再去看電影。(這部片要整個劇透透光後,去電影院刷個兩次會特別有感覺)

特別推薦看 IMAX 版,螢幕大感覺就是不一樣... 另外結尾的彩蛋有兩則,請不要看完第一則就跑掉了。(話說回來,上上星期五去長春國賓看的時候居然沒看到第二則就被工作人員告知已經結束,不知道是怎麼一回事...)

首先是維基百科的資料 (當作入口點):

中文版會容易看一些,不過英文版的資料比較豐富。

另外維基百科上面也有人從 FAA 所公開的資料中截出 New York TRACON 的錄音抓出對應的部份,並且將對話過程抄寫出來:「File:Flight 1549 FAA New York TRACON audio extract.ogg」,電影的確照實將這些對話演出來:

在「Flight 1549 3D Reconstruction, Hudson River Ditching Jan 15, 2009」這邊依照公開的錄音 (從在機場起飛開始) 以及所有公開的對話記錄 (黑盒子的記錄),配上模擬機上的畫面,也可以看一看:

包括機長對著哈德遜河樹旗的「uh what a view of the Hudson today」... 然後是另外一個角度,混入 LGA 的錄音記錄以及雷達記錄:

再來是在電影裡面提到的 35 秒延遲實驗,這可以在 NTSB 的官方報告裡面看到對應的說明 (取自「Loss of Thrust in Both Engines After Encountering a Flock of Birds and Subsequent Ditching on the Hudson River - US Airways Flight 1549 - Airbus A320‐214, N106US - Weehawken, New Jersey - January 15, 2009」這份 PDF):

Regarding the second flight scenario, 20 runs were performed in the engineering simulator from a preprogrammed point shortly before the loss of engine thrust in which pilots attempted to return to either runway 13 or 22 at LGA or runway 19 at TEB. Five of the 20 runs were discarded because of poor data or simulator malfunctions. Of the 15 remaining runs, in 6, the pilot attempted to land on runway 22 at LGA; in 7, the pilot attempted to land on runway 13 at LGA; and in 2, the pilot attempted to land on runway 19 at TEB. In eight of the 15 runs (53 percent), the pilot successfully landed after making an immediate turn to an airport after the loss of engine thrust. Specifically, two of the six runs to land on runway 22 at LGA, five of the seven runs to land on runway 13 at LGA, and one of the two runs to land on runway 19 at TEB immediately after the loss of engine thrust were successful. One run was made to return to an airport (runway 13 at LGA) after a 35-second delay, and the landing was not successful.

也就是做了 20 次的模擬,而有效的模擬有 15 次,其中 8 次成功降落回機場 (成功次數分別是 LGA 22 跑道 2/6、LGA 13 跑道 5/7,以及 TEB 19 跑道 1/2),這些都是鳥擊後馬上選擇回機場迫降。

而加上 35 秒的反應時間後的 LGA 13 跑道則做了一次,那次降落則是不成功。

在 NTSB 報告上,加上 35 秒後的測試只有一次有點怪,但電影裡機長 Sully 臨時要求把「人性」加進去的劇情剛好符合這個解釋。所以有可能就如同電影所演出的,是現場追加的測試?

最後,有幾部記錄片則是透過不同的角度來看這次事故,都很值得看:

  • TLC,特別節目,Brace For Impact。
  • 空中浩劫,第十季第五集,Hudson River Runway。
  • 國家地理頻道,特別節目,Miracle Landing On The Hudson。

這些在網路上找一下都有,這邊就不提供連結了。

Archives