棄用 Keybase (Zoom 買下 Keybase 的新聞)

前幾天的新聞,Zoom 的新聞稿:「Zoom Acquires Keybase and Announces Goal of Developing the Most Broadly Used Enterprise End-to-End Encryption Offering」,Keybase 的新聞稿:「Keybase joins Zoom」,看到後就把本來的服務刪一刪了...

這篇屬名由 Zoom 創辦人發出的公告,裡面多到讓人不知道怎麼吐槽的部份,我們就把唯一的粗體字拉出來討論好了:

We are excited to integrate Keybase’s team into the Zoom family to help us build end-to-end encryption that can reach current Zoom scalability.

先不講先前被戳破根本就不是 end-to-end encryption 的問題,影音上面因為 transcoding 的問題,如果要在 video stream 上做 end-to-end encryption 的話分成兩種方式可以做:

a) 一種是發送端直接產生出多個不同 bitrate 的 video stream,這種方式其他家都已經很熟悉了,缺點也很明顯,就是吃各種資源,包括發送端的壓縮能力與頻寬。

b) 另外一種方式是產生出可以疊加的 video stream,有點像是 progressive image 的方式,第一個 stream1 的畫質最低,第二個 stream2 則是「補強」第一個 stream1,這樣子可以降低資源的需求。

另外有想到 Homomorphic encryption 的方式,直接可以疊加加密後的 stream1 + stream2,不過 bitrate 應該不會降低,就算真的設計的出來應該也沒用...

如果是 a) 的方式,業界對於 key 的交換都已經解的還不錯了,但這個方式沒什麼競爭性 (因為其他家也都已經做完了)。

如果是 b) 的方式,很明顯該找的是 codec 的公司 (要做出可以疊加的 codec),而不是搞密碼學的公司。

回到原來的問題,現有的團隊有 2500 人,裡面的技術團隊沒辦法搞定 end-to-end encryption,ok 沒關係,那現在的 CTO Brendan Ittelson 應該可以建一個團隊吧?所以我翻了一下他的 LinkedIn 看了一下他的經歷,對不起我錯了,我瞬間不知道怎麼寫下去了,我豆頁痛...

AWS Direct Connect 在台北又增加可以接的機房了...

先前 AWS Direct Connect 在今年二月的時候公佈了台北第一個開放的接點,是方的麗源機房 (Chief Telecom LY, Taipei, Taiwan,參考「AWS 公開了在台北的 Direct Connect 接口」),現在公佈第二個點了:「New AWS Direct Connect locations in Paris and Taipei」。

第二個點在中華電信的機房 (Chunghwa Telecom, Taipei, Taiwan),但這樣只這樣標,不知道實際上是哪個,會不會是愛國東路的國分機房?那邊有不少非中華電信網路的客戶,只是租那邊的機房在用...

不過有需求的可以問一下 AWS,應該就會有答案了,畢竟總是得讓客戶知道要接到哪邊...

AWS 公開了在台北的 Direct Connect 接口

也是個很久前就聽到傳言的消息... AWS 剛剛公佈了在台北的 Direct Connect 接口,用戶可以在台北內租用線路進機房就連上 Direct Connect:「New AWS Direct Connect sites land in Paris and Taipei」。

AWS Direct Connect also launched its first site in Taiwan at Chief Telecom LY, Taipei. In the Management Console, Taipei is located in the Asia Pacific (Tokyo) Region. With global access enabled for AWS Direct Connect, these sites can reach AWS resources in any global AWS region using global public VIFs and Direct Connect Gateway.

以往需要透過像 GCX 這樣的公司租用國際頻寬,再從 GCX 在台北的機房拉到自家機房 (通常是市內專線),現在只需要在台北對接的這段就可以了。

台北的接點在 AWS 上寫的是 Chief Telecom LY, Taipei, Taiwan,查了一下是是方電訊的「是方麗源大樓 (台北市內湖區陽光街250號)」,也就是之前有發生過火災而大斷線的那棟。對接的 AWS Home Region 是 Asia Pacific (Tokyo),所以使用 ap-northeast-1 的人可以規劃...

Cloudflare 看這次 815 斷電的網路使用變化

Cloudflare 分析了這次 815 停電對網路造成的影響:「Power outage hits the island of Taiwan. Here’s what we learned.」。

以 Cloudflare 在是方機房的 QPS 來看,停電後反而沒有太大變化:

把裝置種類拆開來看,可以看到桌機的使用量下降,但手機的使用量上升:

這點從 HiNet 的使用頻寬也可以看出來,頻寬使用量降了 25% (從光世代與 ADSL/VDSL 換到行動網路上?):

Oracle 的 CSO (Chief Security Officer) 對資安的想法

這應該是昨天很熱鬧的新聞,也不難看出 Oracle 對資安的心態。

參考「Oracle to 'sinner' customers: Reverse engineering is a sin and we know best」這篇報導,Oracle CSO Mary Ann Davidson 發表的原文已經被刪除,但這是 internet 時代,當然有完整的備份下來:「No, You Really Can’t (Mary Ann Davidson Blog)」。

提供給 ZDNet 報導的補充是:

The security of our products and services has always been critically important to Oracle. Oracle has a robust program of product security assurance and works with third party researchers and customers to jointly ensure that applications built with Oracle technology are secure. We removed the post as it does not reflect our beliefs or our relationship with our customers.

Oracle 的公關能力一如往常的優秀!

CloudFront 有台灣機房了...

這是從 HiNet 機房連到 AWS 官方 d36cz9buwru1tt.cloudfront.net 的 SmokePing 資料:

從中華 HiNet 機房到 test.gslin.org:

  3.|-- 211.22.229.2               0.0%    10    0.2   0.2   0.2   0.6   0.0
  4.|-- 220.128.5.226              0.0%    10    0.4   2.6   0.4  11.9   4.4
  5.|-- 220.128.2.174              0.0%    10    2.7   5.4   2.6  12.5   3.3
  6.|-- 220.128.4.177              0.0%    10    0.4   2.0   0.4  16.2   5.0
  7.|-- 203.75.228.29              0.0%    10    1.3   1.3   1.1   1.6   0.0
  8.|-- 223.26.66.19               0.0%    10    1.7   1.4   1.3   1.7   0.0
  9.|-- 202.133.255.122            0.0%    10    1.1   6.8   1.0  38.8  12.2
 10.|-- 54.230.215.52              0.0%    10    1.2   1.2   1.1   1.3   0.0

從台灣固網 TFN 機房到 test.gslin.org:

  3.|-- 60.199.236.110             0.0%    10    0.3   0.3   0.3   0.5   0.0
  4.|-- 60.199.255.3               0.0%    10    0.3   0.3   0.3   0.3   0.0
  5.|-- 60.199.20.149              0.0%    10    0.2   0.2   0.2   0.2   0.0
  6.|-- 60.199.3.161               0.0%    10   37.9   4.1   0.2  37.9  11.9
  7.|-- 60.199.17.194              0.0%    10    0.7   3.0   0.5  14.1   4.7
  8.|-- 210.62.255.28              0.0%    10   11.0  18.1   1.9 139.9  42.9
  9.|-- 223.26.66.19               0.0%    10    1.5   1.6   1.4   1.8   0.0
 10.|-- 202.133.255.122            0.0%    10    1.9   1.8   1.6   2.4   0.0
 11.|-- 54.230.215.131             0.0%    10    3.8   3.5   1.2   5.4   1.4

雖然官方還沒公佈,但已經上線了,代碼是 tpe50

就路徑與反解資訊看起來是在是方的網路裡,不過不是很確定... 另外 Route53 看起來還沒有導過去,所以是還在 setup?

Anyway,在台灣有 PoP 的 CDN 又多了一家:

所以什麼時候會正式公佈呢...

網路陸陸續續恢復了...

據說是改接線路跳過 UPS 後直接上市電供應,然後逐層恢復:(出自公開社團「225 內湖機房斷線八卦區」)

然後中華也恢復對 ajax.googleapis.com 該有的 packet loss 了:(參考上篇「HiNet 到 Google 改走國際線路,packet loss rate 反而降下來...」)

現在連的到 www.chief.com.tw 了,也看得到官方公告「是方電訊IDC大樓復電 客戶服務陸續恢復正常」了...

Windows Azure CDN 的台灣 PoP...

自九月開始,微軟的 Windows Azure CDN 增加了兩個 PoP:「20 Nodes Available Globally for the Windows Azure CDN」,參考文章最後的「UPDATE - 9/1/10」部份。

  • Seoul, KR
  • Taipei, TW

這樣又多了一個 CDN 在台灣有 PoP... 其他幾家是 AkamaiCDNetworks

在台灣放的點是是方電訊,以微軟自家的 hp.msn.com 測試 (目前是 CNAME 指到 msnimstore.vo.msecnd.net),從 HiNetSEEDNet台灣學術網路 (透過 SEEDNet 轉過去) 都會被導到台灣的點,而台灣固網則是被導到美西,看起來是因為台固與是方是走 TWIX...

是該跳下去玩看看的時候了...