【科技新聞】TabFS——一種瀏覽器擴展，將瀏覽器選項卡安裝為文件系統

如果你在 macOS 上，你可以在 Chrome 或 Safari 中使用 AppleScript（或任何可以發送蘋果事件的東西）本地做一小部分——也就是說，你可以遍歷窗口或選項卡，查看它們的源代碼，然後執行您傳遞的任意 javascript（您必須接受一次性安全選項）。如果您不想安裝任何東西，這對於快速自動化很方便。

（背景：我有 RSI，所以我一直在開發應用程序和 Talon Voice ( https://talonvoice.com/ ) 之間的一些集成。對於支持它的應用程序，AppleScript 最終具有驚人的價值/快速/可靠。我還構建了與 iTerm2 的 Python API 集成，然後才注意到它的 AppleScript 字典已經支持我嘗試做的所有事情，而且速度更快。在 Google Chrome 中，“遍歷選項卡並在其中執行 javascript”對於自動化 Google Meet 靜音非常有用/取消靜音。）

不過，沒有人反對這個優秀的項目；我是奧馬爾推特的忠實粉絲！而且我懷疑這裡的大多數人會欣賞文件系統方法比處理 AppleScript 的殘暴語法更容易編寫腳本。

我每天都使用經過深度修改的叉子。我的改變是：

1. 用 Go 重寫後端（我沒有資格審核 C 版本，讓 Web Stuff™ 直接與未經審核的 C 文件系統守護進程交互讓我毛骨悚然）

2. 對其進行模塊化，以便更容易添加端點，例如…

3. 基本的樹型選項卡支持

4. 拼命嘗試提高性能以適應相當大的會話（我還沒有成功）

儘管如此，我得出的結論是這種關係是倒退的：文件系統表示需要驅動瀏覽器，而不是相反。

我深思熟慮後認為，有些英雄需要加強並構建一個瀏覽器，該瀏覽器只呈現一個選項卡，而沒有其他任何東西，為比滾動更複雜的一切付出代價。然後高級用戶 cwn 使用他們喜歡的任何膠水提供他們自己的選項卡/書籤/窗口/文件系統方案，無論是 python、節點、shell 腳本、Windows 資源管理器……

我希望我可以訪問 about:tabs 並查看我打開的所有選項卡的純文本列表，每行一個 URL。

沒有深奧的攻擊向量，沒有主要的新功能或集成，只是一種快速簡便的方法，無論技術能力如何，任何用戶都可以在更新 Firefox 或重新啟動系統之前轉儲他們的標籤…

…因為每個人都被 FF 重啟燒毀了，由於未知原因，即使配置正確，也無法恢復選項卡。

就目前而言，您需要深入挖掘幾個目錄到 /Library（或其他目錄，具體取決於您的操作系統），然後使用 JSON 工具導出……我已經失去了大多數人。

FWIW，rsync.net 已為此功能懸賞 1500 美元 [1]。將此視為通貨膨脹調整後的漲幅至 2500 美元。

[1] https://news.ycombinator.com/item?id=24524923

Greasemonkey 是一個不錯的選擇，但後來發生了一些事情，它不再是最佳選擇。我不確定是什麼。

Tampermonkey 也是如此。它現在內置了遙測技術，但一度沒有隱私政策。

https://www.reddit.com/r/firefox/comments/6hs59w/tampermonke…

現在好的是Violentmonkey。已經有一段時間了。

Mozilla 是否有這些的白名單？如果是這樣我不喜歡它。

我不明白為什麼 Mozilla 人為地限制可以在 android 上使用的插件。

我多年來一直在 Android 上使用 Tampermonkey，它運行良好，就像其他尚未被祝福的插件一樣，因此用戶被授予能夠選擇安裝它們的特權。

作為參考，要解決 mozilla 的人為限制，您必須每晚使用。一旦激活調試菜單（關於 firefox > 點擊徽標 5 次），就會有設置“自定義附加組件集合”的選項。您可以使用 Firefox 帳戶在 addons.mozilla.org 上創建自定義集合。這兩個字段是自定義集合 URL 的最後兩部分。

這不僅非常麻煩（特別是如果你想在你的收藏中添加另一個插件並將其傳播到你的手機），而且它只能在夜間使用。 nightly 有打破習慣的壞習慣。當更新導致它在訪問某些網站時立即崩潰時，這並不是很有趣；更糟糕的是，重新啟動會導致它嘗試加載剛剛導致其崩潰的選項卡。

因此，它最終陷入了兩難境地：您可以擁有一個不會在每次更新時災難性地破壞的瀏覽器；或者您可以自由安裝您喜歡的任何插件。但不是兩者。

而這種困境完全是人為的和不必要的。 Mozilla 可能有一個驗證插件在 Android 上是否正常工作的過程，如果您嘗試安裝一個未經驗證的插件（例如 Valve 如何“Deck Verified”但不會阻止您安裝任何您喜歡的東西），則會發出警告。但這不是他們所做的，他們也沒有表現出任何改變主意的跡象。

如果有人需要一個不是用於網頁而是用於計算機系統上任何進程的“猴子”，我可以推薦 Frida：

https://frida.re

https://github.com/frida/frida

使用 Frida，你可以編寫 JavaScript 程序，然後將它們注入任意進程，以掛鉤、修改和調用任何你喜歡的東西。

它在逆向工程和漏洞研究社區中得到大量使用，但范圍也更廣。

例如，我最近用它來自動化 Windows 上視頻製作程序的 UI，方法是從注入的線程向主消息循環發送窗口消息，並連接到各種系統對話框函數以覆蓋它們。

如果您想學習任何東西，電子郵件是一個不錯的選擇。 30年來幾乎沒有變化，我懷疑很長一段時間內不會有太大變化。

我建立了自己的交易電子郵件提供商 ( https://mailpace.com )，我希望在開始之前找到此鏈接。

我還建議閱讀電子郵件 RFC，它們並不難理解，而且歷史解釋了很多。撇開電子郵件不談，我們將來可以從這種分佈式、去中心化的系統設計中學到很多東西。

我喜歡這樣詳盡的闡述，儘管它並不像我希望的那樣詳盡。在我閱讀的部分中，有兩個例子引起了我的注意：

1. 它沒有提到將顯示名稱寫為電子郵件地址的舊約定

 john.doe@example.net (John Doe)

代替：

 John Doe <john.doe@example.net>

2. 它聲明像“Re:”這樣的主題前綴沒有技術相關性。這並不完全正確，因為電子郵件客戶端在回复/轉發時會識別現有前綴，以免添加多餘的前綴。這裡有幾個問題：

– 本地化的電子郵件軟件有時會根據當地語言使用不同於“Re”的前綴。當無法識別彼此本地語言前綴的電子郵件客戶端之間存在電子郵件線程時，這是一個問題。 （可以說，無論語言如何，每個人都堅持使用“Re”會更好。）

– 一些電子郵件客戶端有在“Re”上添加計數的慣例，例如“Re[2]:”、“Re[3]:”等。當您編寫電子郵件客戶端時，您可能需要考慮識別這些。

由於主題前綴的多樣性，一些電子郵件客戶端允許用戶配置正則表達式。

我認為這個解釋很好地說明了電子郵件冰山底部有多大。當我第一次使用電子郵件時，處理所有變化所需的工作讓我不知所措。

我什至沒有嘗試運行自己的郵件服務器，我只是試圖以結構化形式解析和存儲電子郵件。我原以為一個晚上的工作很快就變成了整整一周。

在構建 Hypermail [0] 時，我實際上使用了 GPT-3 進行一些解析。它在處理電子郵件回复格式的變化方面做得非常好（電子郵件客戶端都有自己的處理方式）。

[0] – https://www.idiotlamborghini.com/articles/the_hypermail_expe…