44.1kHz 的由來...

在「Explanation of 44.1 kHz CD sampling rate」這邊看到 44.1kHz 的解釋...

這個數字反而是跟 video 有關而設計出來的:

In 60 Hz video, there are 35 blanked lines, leaving 490 lines per frame or 245 lines per field, so the sampling rate is given by :

60 X 245 X 3 = 44.1 KHz

In 50 Hz video, there are 37 lines of blanking, leaving 588 active lines per frame, or 294 per field, so the same sampling rate is given by

50 X 294 X3 = 44.1 Khz.

而後來 44.1kHz 被拿去 CD 規格裡使用而被廣泛應用...

WebScaleSQL

WebScaleSQLFacebookGoogleLinkedIn 以及 Twitter 四家公司對 MySQL 5.6 的 fork。

Percona 的人也針對 WebScaleSQL 與 Percona Server 5.6 的比較,寫了一篇技術分析的文章:「A technical WebScaleSQL review and comparison with Percona Server」。

Percona 那篇分析文章提到不少改善屬於比較激進類型,對於 Percona Server 以及 MySQL 官方版本的定位並不適合。

而在開發上,語法也換到 C99C++11,也就是打算拋棄很舊的系統 (沒有 C99/C++11 compiler)。不過就這點來說,使得這上面的 patch 要 backport 回 MySQL 又增加了一些狀況...

WebScaleSQL 的出現代表 MySQL fork 又多一家,而且因為背後是這四家公司搞出來的,看起來聲勢會很浩大。進入「合久必分」的階段...

Facebook 在對抗 BREACH Attack 的方法

在「Facebook Takes Tougher Stand Against BREACH Attack」這篇提到 Facebook 在 2012 年對抗 BREACH attack 的方法:

在文章最後面有提到當時一般建議的 migrate 方式 (關閉 TLS 的壓縮) 不適用於 Facebook:

Turning off compression is not an option for large dynamic sites such as Facebook because it would hinder performance dramatically.

而且就算關掉 TLS 的 compression,也還是有疑慮:

Even if TLS-level compression is disabled, it is very common to use gzip at the HTTP level. Furthermore, it is very common that secrets (such as CSRF tokens) and user input are included in the same HTTP response, and therefore (very likely) in the same compression context,

節錄幾段 migrate 的重點:

Facebook disclosed how it’s mitigating BREACH attacks by changing the frequency in which it rotates CSRF tokens from daily to each time a Facebook session is started.

本來 CSRF token 變更的頻率是好幾天一次,把頻率拉高...

After a new token is issued, the previous tokens still remain valid for a couple days, resulting in multiple tokens being permissible simultaneously.

然後舊的 token 還是會保持一段時間有效。

因為現實因素而沒辦法在 TLS 層關閉,後面在 application level 的 workaround 相當費功... (而且要多花不少資源?)

Small Characteristic DLP (Discrete Log Problem) 被解決

最近幾天在密碼學領域還蠻紅的話題 (雖然預印本在去年就發了),EUROCRYPT 2014 上發表對 DLP (Discrete Log Problem) 的重大進展。

論文在 arXiv 上可以取得:「A quasi-polynomial algorithm for discrete logarithm in finite fields of small characteristic」。

針對使用小特徵值的有限域 (finite field) 的 DLP 問題 (也就是 Zqk 上) 直接從 sub-exponential 降到 nO(logn) (quasi-polynomial)。最常見到的應該是 Z2n

雖然現有被廣泛使用的密碼系統在使用 DLP 建構時都是用 Zp,但這次的成果絕對寫下了 DLP cryptoanalysis 上的里程碑...

APT (Advanced Persistent Threat)

維基百科對 APT (Advanced Persistent Threat) 的定義是:

Advanced Persistent Threat (APT) APT is a set of stealthy and continuous computer hacking processes, often orchestrated by human(s) targeting a specific entity.

針對特定個人或團體進行攻擊,這邊的 entity 通常是指有權限存取系統,或是手上握有機敏資料的人,這些人的帳號密碼,或是系統權限是有價值的。

這幾年因為行動裝置普及,再加上行動裝置上驗證起來會比較麻煩,成為 APT 攻擊的首選。

下面就原文照登:

總算是搞定 Vagrant + Docker...

Docker 最大的好處就是啟動速度,比 VirtualBox 快非常多,但 Vagrant 官方對於 Docker provider 的範例還是太少,踹了老半天才踹出來:

ENV["VAGRANT_DEFAULT_PROVIDER"] = "docker"

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
    config.vm.provider "docker" do |docker, override|
        docker.image = "fgrehm/vagrant-ubuntu:precise"
        docker.has_ssh = true

        override.ssh.port = 22
    end
end

然後用 vagrant up 跑起來,接下來就可以用 vagrant ssh 連進去。

其中 override 是目前的 workaround,可以參考 GitHub 上的「Docker provider: cannot 'vagrant ssh' when not using a Docker host VM · Issue #3799 · mitchellh/vagrant」。

Docker 的 image 不透過 Vagrant 管理,而是 Docker 自己處理。可以用 docker images (列出) 與 docker rmi [repository] (刪除) 操作。

東京

有時候會被問到為什麼這麼喜歡把東京當後院在跑,當然是有很多理由啦... 其中一個理由是在享受細節。

上面這張圖是在東京站 (東京地下鐵丸之內線) 拍的指示牌,不只是這個指示牌,東京內的 JR 或是地鐵都可以感覺到裡面的魔鬼。

如果去忠孝新生走走就會知道差異了。

EFF 的 Privacy Badger

EFF 推出新的延伸套件 (有 Firefox 與 Google Chrome 版),透過演算法阻擋嘗試追蹤你的單位:「Privacy Badger」。

在官網上有比較技術面的說明:

At a more technical level, Privacy Badger keeps note of the "third party" domains that embed images, scripts and advertising in the pages you visit. If a third party server appears to be tracking you without permission, by using uniquely identifying cookies to collect a record of the pages you visit across multiple sites, Privacy Badger will automatically disallow content from that third party tracker. In some cases a third-party domain provides some important aspect of a page's functionality, such as embedded maps, images, or fonts. In those cases Privacy Badger will allow connections to the third party but will screen out its tracking cookies.

技術上的作法是分析 third party domain 的行為,用演算法阻擋可能的追蹤。與 Ghostery 這類工具使用人力建立清單的方法不太一樣。

裝起來跑看看,感覺還蠻有趣的...

關於 PHP 的 require 與 include (以及 *_once)

本來以為寫過了,後來找了找沒找到...

星期五的時候跟 Gasol 聊了一下,後來查資料後整理出來。(主要是 include 的文件說明)

requireinclude 的差異在於找不到檔案時,include 會產生 warning,而 require 會產生 fatal error:

The include construct will emit a warning if it cannot find a file; this is different behavior from require, which will emit a fatal error.

而對 include_path 的處理則是「遇到有指定 path 時就忽略 include_path」,而對 require './foo.php' 的解讀是「relative to the current directory」:

If a path is defined — whether absolute (starting with a drive letter or \ on Windows, or / on Unix/Linux systems) or relative to the current directory (starting with . or ..) — the include_path will be ignored altogether. For example, if a filename begins with ../, the parser will look in the parent directory to find the requested file.

由於不是「檔案所在的路徑」而是「current directory」,會受到 chdir() 的影響。一般在程式碼內的基準應該是「這個 script 所在的路徑」,而非「current directory」,所以寫法應該是:

<?php
require __DIR__ . PATH_SEPARATOR . 'foo.php';

<?php
# 直接假設在 Mac OS X & Linux & FreeBSD 上跑...
require __DIR__ . '/foo.php';

而這種寫法就得依靠 include_path 內有 .,而且還要祈禱不會在其他的目錄裡出現同樣檔名:

<?php
require 'foo.php';