OpenSSH 加入了 noise (keystroke timing obfuscation) 功能

Hacker News 上看到在 OpenSSH 裡加入 keystroke timing obfuscation 的功能:「Keystroke timing obfuscation added to ssh(1) (undeadly.org)」。

如同 commit log 裡面提到的,這個功能會想要故意沒事就送一些沒用的資料 (增加一些噪音),降低從 side channel 被判讀的資訊量:

This attempts to hide inter-keystroke timings by sending interactive traffic at fixed intervals (default: every 20ms) when there is only a small amount of data being sent. It also sends fake "chaff" keystrokes for a random interval after the last real keystroke. These are controlled by a new ssh_config ObscureKeystrokeTiming keyword/

基於 OpenSSH 算是 SSH 這塊的 de-factor standard 了,接下來看其他家像是 Dropbear 會不會也實作?

風扇的出風孔的遮罩,不同形狀產生噪音的差異

前幾天在 Hacker News Daily 上看的文章:「Effects of grill patterns on fan performance/noise (2011) (pugetsystems.com)」,原文在「Effects of Grill Patterns on Fan Performance/Noise」。文章在講電腦風扇的出風口擋板的樣式對噪音的影響。這是一篇 2011 的老文章,但看了一下好像沒有什麼新資料...

出風口的遮罩在有些地區似乎是法律要求,主要是怕小朋友手指戳進去,以及成年人不小心碰到,所以就會有專門的測試項目在跑:

I remember back in 2000 ish I worked in R&D of a PC manufacturer and had to check the new PSUs and cases with a 'Test Finger' to make sure all the holes were small enough. The test finger was really expensive IIRC.

但回到這篇的重點,噪音與風量的差異,所以基準值是拔掉遮罩的部份先測試 (所以可以知道最低的噪音與最大的風量),然後上各種遮罩測差異。

Mesh 增加的噪音是最少,但風量有點差:

Wire 增加的噪音也很少,風量也達到最高:

從倒數的方向來看,Turbine 是最吵風量也最少的:

發現比較差的遮罩增加的噪音不算少,把很多風的動能變成聲音的能量了...

利用 Sensor 校正資訊產生 Device Fingerprint 的隱私攻擊

看到「Fingerprinting iPhones」這篇提出的攻擊,標題雖然是提到 iPhone,但實際上攻擊包括了 Android 的手機:

You are affected by this fingerprinting attack if you are using any iOS devices with the iOS version below 12.2, including the latest iPhone XS, iPhone XS Max, and iPhone XR. You are also likely to be affected if you are using a Pixel 2/3 device, although we hypothesise the generated fingerprint has less entropy and is unlikely to be globally unique. A SensorID can be generated by both apps and mobile websites and requires no user interaction.

目前 iPhone 升級到 12.2 之後可以緩解這個問題,Android 看起來還不清楚...

攻擊的方式是透過手機在出場前會使用外部的校正工具,找出手機內 sensor 所偵測到的值與實際值的差異,然後把這些資訊燒到韌體裡,當呼叫 API 時就可以修正給出比較正確的值。

而因為這些校正資訊幾乎每一隻手機都不一樣,而且不會因為重裝而變更 (即使 factory reset),加上還可以跨 app 與 web 追蹤,就成為這次攻擊的目標:

In the context of mobile devices, the main benefit of per-device calibration is that it allows more accurate attitude estimation.

資訊量其實相當大,透過 app 分析可以得到 67 bits entropy,透過網頁也有 42 bits entropy,而且不怎麼會變:

In general, it is difficult to create a unique fingerprint for iOS devices due to strict sandboxing and device homogeneity. However, we demonstrated that our approach can produce globally unique fingerprints for iOS devices from an installed app -- around 67 bits of entropy for the iPhone 6S. Calibration fingerprints generated by a website are less unique (~42 bits of entropy for the iPhone 6S), but they are orthogonal to existing fingerprinting techniques and together they are likely to form a globally unique fingerprint for iOS devices.

We have not observed any change in the SensorID of our test devices in the past half year. Our dataset includes devices running iOS 9/10/11/12. We have tested compass calibration, factory reset, and updating iOS (up until iOS 12.1); the SensorID always stays the same. We have also tried measuring the sensor data at different locations and under different temperatures; we confirm that these factors do not change the SensorID either.

目前提出來的解法是加入隨機值的噪音 (iOS 的作法),不過作者有建議預設應該要關閉 js 存取 sensor 的權限:

To mitigate this calibration fingerprint attack, vendors can add uniformly distributed random noise to ADC outputs before calibration is applied. Alternatively, vendors could round the sensor outputs to the nearest multiple of the nominal gain. Please refer to our paper for more details. In addition, we recommend privacy-focused mobile browsers add an option to disable the access to motion sensors via JavaScript. This could help protect Android devices and iOS devices that no longer receive updates from Apple.

不過當初這群人怎麼會注意到的...

懷舊技術系列...

在「Stopping The Internet Of Noise - A Useful Internet Back Again」這邊看到作者在思考現在的工具有很多干擾 (像是 Social Network 這樣的網站),反倒是傳統的一些技術與工具更專注在解決問題本身。

像是 Usenet

IRC:

RSS reader:

有種考古懷舊系列的感覺...

題外化,看到他用的是 BazQux 這個 RSS reader,來測試看看感覺如何,如果可以的話就從 Feedly 換過去好了...

辦公室採用開放式空間的問題

這幾年對於開放式空間有不少反面意見出來,像是這幾天 BBC 登的「Why open offices are bad for us」。

這是目前的主流,大量的公司採用開放式空間:

Numerous companies have embraced the open office — about 70% of US offices are open concept — and by most accounts, very few have moved back into traditional spaces with offices and doors.

但人的效率會因為開放式空間大約掉 15%:

But research that we’re 15% less productive, we have immense trouble concentrating and we’re twice as likely to get sick in open working spaces, has contributed to a growing backlash against open offices.

採用開放式空間最常見的理由包括辦公室成本 (每個人平均分到的空間大小會比較低),另外一個是藉由開放式空間讓互相討論合作的成本降低,但因為開放式空間,反而是影響到別人的情況比討論合作的情況多,甚至是與工作無關的事情也會影響到期他人:

Beside the cheaper cost, one main argument for the open workspace is that it increases collaboration. However, it’s well documented that we rarely brainstorm brilliant ideas when we’re just shooting the breeze in a crowd. Instead, as many of us know, we’re more likely to hear about the Christmas gift a colleague is buying for a family member, or problems with your deskmate’s spouse.

其實科技的進步讓遠端溝通的成本降低了不少,像是 SlackZoom,現在未必要靠 open office 的架構讓大家溝通了。

資料庫在 EC2 上選擇 Instance Type 的方向

ScyllaDBCassandra 的 C++ 相容版本,效能比起 Java 版本的好不少 (尤其是與 CPU 與記憶體有關的部份)。

ScyllaDB 的人上個月給了一份指南,主要是在講在 Amazon EC2 上怎麼選 instance type 跑 NoSQL (主要還是針對 ScyllaDB 的情境下分析)。不過道理是通的:「Choosing EC2 instances for NoSQL」。

不同於 Cassandra 比較容易吃到 CPU bound,ScyllaDB 比較容易吃到 i/o bound,所以 i/o 的效能對於選擇 instance type 重要許多。

後面也有提到 instance size 的問題 (八台 xlarge 還是一台 8xlarge),不過感覺沒有給很清楚的方向。一般來說,分散式資料庫之間溝通還是有不少成本在,另外文章裡也提到同一台實體機器的鄰居造成 i/o noise 的問題,看起來在經濟規模夠大的情況下,開到最大台才是王道啊?

新版的 Google Chrome 將會在 Tab 上 Icon 標示發出聲音...

開了一堆頁面,卻找不到放音樂的 tab 是哪個?在新版的 Google Chrome 裡會將正在放音樂的 tab 用動畫標示在 tab 上的 icon:「Chrome Shows Which Tab Is Making a Noise」,像是這樣的提示:

目前在 Canary channel 裡才有,等個幾個月就會在正式版本出現了... (canary -> dev -> beta -> stable)