摸進俄羅斯的外包廠商,意外發現的專案:降低 Tor 匿名性的工具

俄羅斯政府的外包廠商 SyTech 被摸進去後,被發現裡面有些「有趣」的軟體:「Hackers breach FSB contractor, expose Tor deanonymization project and more」。

這次被放在標題的軟體叫做 Nautilus-S,透過被加過料的 Tor server 與 ISP traffic 交叉分析,試著找出俄羅斯內的 Tor 使用者:

Nautilus-S - a project for deanonymizing Tor traffic with the help of rogue Tor servers.

這不是新東西,之前就有被提出來,但並沒有這次直接給整包軟體出來:

The first was Nautilus-S, the one for deanonymizing Tor traffic. BBC Russia pointed out that work on Nautilus-S started in 2012. Two years later, in 2014, academics from Karlstad University in Sweden, published a paper detailing the use of hostile Tor exit nodes that were attempting to decrypt Tor traffic.

而且看起來有不少節點正在運行:

Researchers identified 25 malicious servers, 18 of which were located in Russia, and running Tor version 0.2.2.37, the same one detailed in the leaked files.

不知道 Tor 會不會有行動...

AWS Client VPN 支援 Split-tunnel

VPN 的 Split-tunnel 指的是 partial routing,也就只針對部份 IP range 走進 VPN,其餘大多數的流量還是走原來的 Internet。

這個方式的安全性通常會比 full routing 低一些,因為這個方式會使得 internet 流量有機會穿進 VPN 內 (像是透過瀏覽器),但因為這可以讓使用者避免越洋的 VPN 導致速度下降過多,算是 VPN 常用的功能。

這次 AWS Client VPN 實做了這個功能:「AWS Client VPN now adds support for Split-tunnel」。

不過 AWS Client VPN 相較於自己架設貴不少,目前知道的單位大多也都還是自己架...

Google 公告了 Chrome Extension 對於權限的新規範

是收到信件通知 (因為之前有開發一些 extension),裡面提到的重點主要是出自「Developer Program Policies」裡的兩項。

第一項是要求權限最小化:

Request access to the narrowest permissions necessary to implement your Product’s features or services. If more than one permission could be used to implement a feature, you must request those with the least access to data or functionality.

第二個是你現在沒有實做的功能就不能要權限:

Don't attempt to "future proof" your Product by requesting a permission that might benefit services or features that have not yet been implemented.

這些新條文將會在 2019/10/15 生效:

Your extensions must be compliant with this policy by October 15th, 2019. You can learn more about these changes and how they may apply to you in our User Data FAQ.

用 Machine Learning 改善 Streaming 品質的服務與論文

Hacker News 上看到「Puffer」這個服務,裡面利用了 machine learning algorithm 動態調整 bitrate,以提昇傳輸品質。

測試得到的數據後來被整理起來一起放進論文:「Continual learning improves Internet video streaming」。

在開頭介紹了 Fugu 這個演算法:

We describe Fugu, a continual learning algorithm for bitrate selection in streaming video.

而 Puffer 就是實驗網站:

We evaluate Fugu with Puffer, a public website we built that streams live TV using Fugu and existing algorithms. Over a nine-day period in January 2019, Puffer streamed 8,131 hours of video to 3,719 unique users.

這個站台提供了許多真實的頻道進行測試:

Stream live TV in your browser. There's no charge. You can watch U.S. TV stations affiliated with the NBC, CBS, ABC, PBS, FOX, and Univision networks.

可以看到 Fugu 的結果很好,比起其他提出的方案是全面性的改善:

這邊是用 WebSocket 測試,並且配合了不同的 TCP congestion algorithm,沒有太考慮額外的計算成本...

拿 Git 記錄分析知名開發者的活動時間...

看到拿 git log 分析知名開發者的活動時間:「At what time of day do famous programmers work?」。

從列出來的人可以看出 Chris Lattner (LLVMSwift) 是個夜貓子,其他人大多都是正常的作息... 也看得出來有些人堅持睡覺時間不碰這些東西 XD

在 Chrome 的 FileSystem API 的漏洞被補上後,偵測私密瀏覽模式的方式

Google Chrome 74 版修掉了一般模式與私密瀏覽模式下 FileSystem API 明顯的不同處後,自然就會有人研究其他的偵測方式:「Bypassing anti-incognito detection in Google Chrome」。

作者提出來的方式是透過 Quota Management API,一般模式與私密瀏覽模式下會得到不同的值,尤其是硬碟夠大的時候上限是不一樣的:

不過這個看起來應該比較好修?

Dropbox 的 non-ext4 支援回鍋

Dropbox 去年的時候拔掉非 ext4 檔案系統的支援,被罵翻也不鳥 (參考「Linux 版的 Dropbox 在十一月後將只支援 ext4...」),結果現在又回來支援了:「Dropbox Brings Back Support For ZFS, XFS, Btrfs And eCryptFS On Linux」。

出自 beta 版的說明「Beta Build 77.3.127」這邊:

Add support for zfs (on 64-bit systems only), eCryptFS, xfs (on 64-bit systems only), and btrfs filesystems in Linux.

不過我不是因為這個而搬走 (因為我用 ext4),反而是在對免費版限制時跳走:「Dropbox 免費版限制三個裝置更新...」。

當初用 X-attrs 當理由,看起來是有人離職了所以就加回來...

Facebook 推出了 Hermes,為了 React Native 而生的 JS Engine

Facebook 提供了一個對 React Native 最佳化的 JS engine:「Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native」。

裡面有提到兩個比較重要的的部份是 No JIT 與 Garbage collector strategy,針對行動裝置的特性而設計:避免 JIT 產生的 overhead,以及降低記憶體使用量。

官方給的改善主要也都是偏這兩塊:

不過沒有提到 CPU usage 會上升多少,只是帶過去:

Notably, our primary metrics are relatively insensitive to the engine’s CPU usage when executing JavaScript code.

對於 Facebook 也許是可以接受的數量,但對於其他人就沒概念了... 要入坑的人自己衡量這部份的風險 XD

Slack 改善桌面應用程式的效能與記憶體用量

Slack 桌面版改版的消息,在「Slack’s new desktop app loads 33 percent faster and uses less RAM」與「Slack speeds up its web and desktop client」這邊都有提到這兩個數字,不過看了官方的「When a rewrite isn’t: rebuilding Slack on the desktop」這篇,好像沒提到這兩個數字... 但看引用的圖片似乎是官方的評估數字,不知道是從哪邊得到的。

這是一個堅持繼續使用 Electron 的前提下改善效能的過程。如果過個幾年他們決定寫 native application 也不意外就是了,要一直壓榨效能,最後大概都會走到這邊... 當然也有可能靠 Google 一直改善 V8 engine 的效能撐很久 (畢竟 Google 是真狂砸人改善),現在大家都在賭可以改善多少 XD

這一波最主要的記憶體用量改善是來自於現在使用的 workspace 當然要有完整資料,而其他 workspace 的頁面就只保留狀態 (透過 Redux):

從記憶體用量可以看出來:

也可以理解因為這樣就不需要在啟動時馬上處理所有 workspace 的資料,所以啟動時間也就下降了不少,但這邊的 trade-off 是切換時的速度就會變慢 (需要重新 render),不過大概是考慮到常見情境下的切換次數而決定這樣做,應該還算 ok...

RTorrent 0.9.8

RTorrent 算是我在 command line 下很喜歡用的 bittorrent client,前幾天釋出 0.9.8 版,距離上一個版本 0.9.7 一年多了:「RTorrent release version 0.9.8」。

從 changelog 可以看到目前主要都還是一些維護性質的修改,像是 bugfix 以及對新的 library 的更新,功能增加的不多...

另外一個是最近提供了 donate 的管道:「Donate to rTorrent development」。在 2017 年的時候有寫信問他有沒有 Patreon,他當時說他人在日本沒辦法處理,看起來後來解決了...