透過把 .git/safe/../../bin 加到 $PATH 執行程式

在「.git/safe」這邊看到的方式,想要方便執行 $GITROOT/bin 想法是:

  • .git/safe/../../bin 放到 $PATH,如果可以順利解出來的話就是 repository 本身的 $GITROOT/bin
  • 但一般是解不出來的 (因為 .git/ 裡面不會有 safe/ 這個目錄,所以預設是解不出東西的。而對於信任的 repository 則可以 mkdir .git/safe 讓 shell 可以搜尋到。

之所以可以這樣做的是因為:

  • .git 是保留字,從 command line 上你沒辦法塞 .git 目錄進到 repository 內,但不確定直接從 blob layer 塞會怎樣... (也就是得確認 checkout 時檢查的問題)

先寫起來看看好了,不過暫時應該也用不到...

維基百科的 Vital articles

Hacker News Daily 這邊看到,英文版維基百科有一套列表,整理出「重要」的條目:「Wikipedia:Vital articles」。

目前的列表有五個層級,從 Level 1 到 Level 5,後面的 Level 包含了前面 Level 的文章:

  • Level 1 只有 10 篇。
  • Level 2 有 100 篇 (包含 Level 1 的 10 篇,以下類推)。
  • Level 3 有 1000 篇。
  • Level 4 有 10000 篇。
  • Level 5 有 50000 篇。

看到的第一個問題就是這些列表怎麼產生的,這點在 Wikipedia talk:Vital articles/Frequently Asked Questions 裡面有提到列表的歷史:這是 2004 年由 David Gerard 發起,之後擴大到社群並且分不同等級。而這也說明了這些列表示人工選擇的,而不是透過演算法推薦的:

The English Wikipedia Vital Articles list was originally created in August 2004 by David Gerard as an adaptation of the metawiki List of articles every Wikipedia should have. Since then, the Vital Articles list has undergone numerous revisions by multiple editors, and has expanded to include 5 different levels of vitalness.

然後選擇的標準是「要了解這個領域不可或缺的條目」:

A vital article is one considered essential to the subjects listed. For example, it would be difficult to discuss Science without the scientific method, History without World War II, Language without Grammar, Earth science without Geology, or Civics without Democracy. Individuals within the People section represent the pinnacles of their field, such as Albert Einstein in "Inventors and scientists" or William Shakespeare in "Authors". In sections such as those pertaining to People, History or Geography, weight is given to some articles to produce a more diverse, global list.

這些列表其中一種用法是「想要了解某個領域」,但剛剛翻了一下 Level 1 與 Level 2 可以發現似乎太少,看起來 Level 3 的資料算是個還不錯的起點...

摸進俄羅斯的外包廠商,意外發現的專案:降低 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