幹壞事是進步最大的原動力
這是在 Bazqux 使用時遇到的問題，我在 Bazqux 這邊看到想看的文章，會習慣用 c 鍵打開新的 tab，等下再一起看。在 Chrome 上面需要安裝 extension 才能開到背景，在 Firefox 上可以透過修改 about:config 裡的browser.tabs.loadDivertedInBackground，讓他預設開到背景 (雖然變成所有的行為都會到開到背景 tab，但我偏好這樣...)。
但在 Bazqux 用 c 鍵把連結打開到 tab 時，有時發現會跳出遇到開啟上限：
這其實很不方便... 所以故意連打測試發現是 20 個，找了一下資料發現是 dom.popup_maximum 這個值，改成 -1 就好了。這算是某種安全機制吧...
先繼續用看看 :o
最近幾天看到「Browsh is a fully-modern text-based browser.」這個專案，在 terminal 下跑的瀏覽器，而且宣稱支援現代網頁的各種標準：
不過實際上後端是接 Firefox，並不是他自己處理所有的內容：
Browsh is available as a small (~2.5MB) static binary on all major platforms. The only dependency is a recent 57+ version of Firefox.
這樣還是超吃資源的，是個好玩為主的專案...
找了一下應該是舊聞了 (參考 2017 年年初，在 Ptt 上的「[-GC-] 新版 Stylish 開始蒐集使用者資訊」這篇)，最近因為「"Stylish" browser extension steals all your internet history」這篇又被拿出來講。
目前的替代方案主要應該是 Stylus，在 Chrome 與 Firefox 都有套件可以裝：Stylus (Chrome)、Stylus (Firefox)。
剛剛看了一下，Firefox 與 Chrome 的 extension 都已經被下架了，而且 Firefox 這邊直接設為黑名單：「Blocklist Stylish add-on - sends full page urls to remote server」。
Mozilla 旗下的產品 (包括 Firefox) 將在今年十月對 Symantec 簽出的 SSL Certificate 終止信任：「Distrust of Symantec TLS Certificates」。
Mozilla 有把發生的事情都整理出來：「CA:Symantec Issues」，另外 Firefox 的動作分成三個階段，目前 stable 是 58，但 nightly 是 60 了：
去年 Google Chrome 就有先丟出對 Symantec CA 的計畫 (參考「Google Chrome 對 Symantec 全系列憑證的不信任計畫」這篇)，看起來 Mozilla 的計畫也差不多，但時間有些差異...
Firefox 從 59 之後，在開啟 Private Browsing 的情況下，不會送出完整的 Referer：「Preventing data leaks by stripping path information in HTTP Referrers」。
這篇吸引到我的是 EFF 的研究員發現的事情：
EFF researchers discovered this leak of personal health data from healthcare.gov to DoubleClick.
其中 EFF 研究員的文章是「HealthCare.gov Sends Personal Data to Dozens of Tracking Websites」這篇。
更好的作法應該是平常就完全阻擋，像是 Firefox 可以用 Referrer Control 設定，或是 Chrome 裡用 Referer Control 設定。
在 Hacker News Daily 上看到的專案，拿 IPFS 來放 Status Page 真的超適合的，靜態為主，然後又可以避開 SPoF：「Decentralized StatusPage」。程式碼放在 GitHub 的 paulogr/dstatuspage，以 JavaScript 撰寫。
在 Hacker News 上的討論也蠻有趣的：「Show HN: A Decentralized StatusPage on IPFS | Hacker News」。
IPFS 提供的特性與 Status Page 需要的特性其實還蠻契合的，也許不是 killer application，但應該會是個 IPFS 的出發點...
而且最近 Firefox 在他們的 blog 上發表了 Firefox 59 會將一些分散式協定加進去 (不是實做，而是提供接口)：「Extensions in Firefox 59」(參考 Support for Decentralization Protocols 這段)，這感覺讓 IPFS 之類的協定有更寬廣的舞台...
在上一篇提到的「控制瀏覽器裡的 Web API」，用了一兩天後有遇到一些問題，大概整理一下...
mail.google.com 列入白名單 (一個阻擋條件都不能設)，這是因為遇到瀏覽器的 bug，在「General breakage on specific site · Issue #55 · snyderp/web-api-manager」這邊作者有找到問題，他判斷是瀏覽器的問題後開了 ticket 給 Firefox 與 Chrome，不知道什麼時候會好...www.facebook.com 列入白名單。www.google.com (或是 www.google.com.tw，看你用的網域) 另外開一組設定管理，另外一個是直接把 WebGL Specification 的阻擋關掉。目前遇到的大概就是這些了...
在「阻止网站调用不必要的你的浏览器 API」這篇裡面看到的，論文的作者發展了 Chrome 與 Firefox 的延伸套件，可以控制瀏覽器內的 Web API。套件原始程式碼在 GitHub 的 snyderp/web-api-manager，頁面上有 Chrome 與 Firefox 延伸套件的連結可以直接安裝。
套件本身預設不會擋任何 Web API，但提供了三種不同的 Preset 讓你選 (Lite、Conservative 與 Aggressive)，一般情況下用 Lite (擋掉 17 種 Web API) 就有不錯的效果了。另外也可以針對某些網域做另外的調整... (雖然還沒用過 XD)
直接抓 Google Chrome 上給的截圖：
這是個好東西啊，有些 API 出來擺明就是來追蹤使用者的... 關掉省麻煩 XD
Mozilla 先前終止與 Yahoo! 的合作後 (在 Firefox 內預設使用 Yahoo! 的搜尋引擎)，Yahoo! 提告以及 Mozilla 還手的消息在最近被 Mozilla 揭露：「Mozilla Files Cross-Complaint Against Yahoo Holdings and Oath」。
Yahoo! 提告的檔案 (PDF) 在「2017-12-01-Yahoo-Redacted-Complaint.pdf」，Mozilla 還手的檔案 (PDF) 則是在「2017-12-05-Mozilla-Redacted-X-Complaint-with-Exhibits-and-POS.pdf」這邊。
在 Firefox 57 釋出時，Mozilla 就把預設的搜尋引擎改回 Google (參考「Mozilla terminates its deal with Yahoo and makes Google the default in Firefox again」)，不過當時 Firefox 57 更大的消息是推出了 Quantum，讓瀏覽器的速度拉到可以跟目前的霸主 Google Chrome 競爭的程度，所以就沒有太多人注意到這件事情...
過了幾個禮拜消息比較退燒後，被告以及反過來告的消息出來後，才注意到原來換了搜尋引擎... XD
旁邊搖旗吶喊沒什麼用，就拉板凳出來看吧...
在「PChome 24h 連線會慢的原因...」這篇的 comment 有讀者提到了 Happy Eyeballs 應該可以解決這個問題：
除了可以在維基百科上面看到外，比較正式的說明可以參考 RFC 6555：「Happy Eyeballs: Success with Dual-Stack Hosts」，其中在「6. Example Algorithm」就有提到 Google Chrome 與 Mozilla Firefox 怎麼實做 Happy Eyeballs：
What follows is the algorithm implemented in Google Chrome and Mozilla Firefox.
- Call getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy.
- Initiate a connection attempt with the first address in that list (e.g., IPv6).
- If that connection does not complete within a short period of time (Firefox and Chrome use 300 ms), initiate a connection attempt with the first address belonging to the other address family (e.g., IPv4).
- The first connection that is established is used. The other connection is discarded.
If an algorithm were to cache connection success/failure, the caching would occur after step 4 determined which connection was successful.
Other example algorithms include [Perreault] and [Andrews].
可以看到 Happy Eyeballs 的演算法是要避免 IPv6 network 不通的情況卡住很慢 (如果在 300ms 內連線沒有建起來，就會儘快往另外一個 address family 嘗試)，而不是在 DNS 層避免問題 (也就是 getaddinfo() 觸發的 DNS query)。
這次的情況是 DNS query 很慢，就會導致還是一開始就很慢，Happy Eyeballs 沒辦法解決這個問題。
不過話說回來，我是有印象知道有這個演算法，但不知道有「Happy Eyeballs」這個這麼逗趣的名字... (掩面)