Category: Browser

Mozilla 推出在本地端直接翻譯的 Firefox Translations

Mozilla 推出了「Firefox Translations」這個 Firefox 上的套件。

主打的就是 offline 這件事情，保有隱私性：

Firefox Translations provides automated translation of web content. Unlike cloud-based alternatives, translation is done locally, on the client-side, so that the text being translated does not leave your machine.

從 Hacker News 上的討論「Firefox Translations: Translate websites in your browser without using the cloud (addons.mozilla.org)」可以看到有些人有提到效果，雖然沒有像雲端服務的準確，但算是可用：

I've just installed it, and I'm impressed so far. I've only run it against some sample German Wikipedia articles (https://de.wikipedia.org/wiki/Clan_of_Xymox), but it produces surprisingly readable text. I also particularly like the "highlight potential errors" option to flag stuff that even the translation service thinks might be a bit off.

It's not nearly as speedy as Google Translate, but I'll take that happily if it means keeping it local.

從頁面上列出的支援語言可以看出還是以歐美用到的語系為主，然後下方也有說明這個專案是包括其他計畫的贊助累積出來的：

Firefox Translations was developed with The Bergamot Project Consortium, coordinated by the University of Edinburgh with partners Charles University in Prague, the University of Sheffield, University of Tartu, and Mozilla. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 825303.

不過比較好奇的是在頁面上有提到 CPU 需要 SSE4.1 能力... 這樣就有兩個問題了，第一個是 browser extension 可以直接跑 SSE4.1 指令集？另外一個疑問就是，Apple 的 ARM 架構就無法支援嗎 (應該也有類似的加速指令集)，現在是 x86 限定？

A CPU that supports SSE4.1 extensions is required for this addon to function properly. If it doesn't, an error will be displayed when the translation is being started.

就算現在限制很多，看起來還是個很有前途的計畫，也許有機會移植到其他瀏覽器上？

透過 CSS 達到可折疊的 tree view

在 Hacker News 上看到「Tree views in css」這篇，講怎麼用純 CSS 技巧達到可折疊的 tree view：

主要是用了 ul 與 li 的 html 結構來搭建 tree view 的意義，再透過 <summary> 與 <details> 這兩個本身就有 toggle 能力的元素來操作展開與收合，後面就是 visual effects 的設計了。

從 Can I use 這邊可以看到支援度沒什麼問題 (連 Android 4.4 的 WebView 都支援)，除非你還得跟 IE11 奮戰：「Details & Summary elements」。

SQLite 官方自己下來搞 WASM/JS 計畫

先前在「把 SQLite 的 VFS 掛上 WebTorrent 的 PoC Demo」有提過 sql.js 這個專案，把 SQLite 移植到網頁上，這些都算是非官方的社群弄出來的專案。

現在官方直接跳下來玩，宣佈自己也要搞 WASM/JS 了：「sqlite3 wasm docs: About the sqlite3 WASM/JS Subproject」。

Folks have been building sqlite3 for the web since as far back as 2012 but this subproject is the first effort "officially" associated with the SQLite project, created with the goal of making WASM builds of the library first-class members of the family of supported SQLite deliverables.

但不太確定 D. Richard Hipp 的想法，官方支援 WASM/JS 的目的會是什麼？放給社群繼續發展有什麼問題嗎...

uBO Lite：另外一個方向的嘗試

兩個禮拜前在 Hacker News 上看到的東西，算是 uBlock Origin 對 Manifest V3 (MV3) 的另外一種嘗試：「uBlock Origin Lite: Description (github.com/gorhill)」，專案的說明在「uBO Lite (uBOL), an experimental permission-less MV3 API-based content blocker.」這邊。

先前在「因應 Manifest V3 而推出的 uBlock Minus (MV3)」這邊提到的 uBlock Minus 是在 MV3 環境下的一個嘗試，但這個版本只是把 MV3 做不到的事情先拔掉，所以缺了很多重要的功能，像是 cosmetic filtering (主要是針對瀏覽器不支援的 css selector，像是最近才剛支援的 :has()，而這些 css selector 對於選擇要幹掉的 html 元素很好用)。

uBO Lite 則是一個妥協，另外讓使用者對特定站台點選授權，而在這些特定授權的站台可以恢復到原來 MV2 時可以過濾的能力 (包含 cosmetic filtering 等等的能力)：

但這個方案也是 Google 所樂見的，只要不方便就會讓使用者慢慢放棄。

目前的公告提到 MV2 只支援到明年一月，大概還有三四個月的時間，接下來 adblock 這塊應該會有很多新的方法陸陸續續冒出來...

因應 Manifest V3 而推出的 uBlock Minus (MV3)

前幾天在 Hacker News 上看到「“UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3 (github.com/gorhill)」這個，裡面是 uBlock Origin 的作者 Raymond Hill 針對 Manifest V3 的半殘版，取名為 uBO Minus (MV3)：「Add experimental mv3 version」。

在這個版本裡會有不少的功能失效，尤其是用的很多的 cosmetic filtering：

- No cosmetic filtering (##)
- No scriptlet injection (##+js)
- No redirect= filters
- No csp= filters
- No removeparam= filters

這個版本應該是打算要提供給 Manifest V2 被 Google 廢掉後還在用 Google 控制的瀏覽器的人，依照「Manifest V2 support timeline」這邊看起來是明年一月：

CSS 的 :has() 有新進展了

在「Using :has() as a CSS Parent Selector and much more」這邊看到 Safari 宣佈對 :has() 的支援，查了一下 Can I use... 上面的資料「:has() CSS relational pseudo-class」，看起來是從 15.4 (2022/05/14) 支援的。

隔壁 Google Chrome 將在下一個版本 105 (目前 stable channel 是 104) 支援 :has()，沒意外的話 Microsoft Edge 應該也會跟上去，看起來只剩下 Firefox 要開了。

先前在「Chromium 的 :has() 實做進展」這邊有翻一下進度，看起來 Chromium 這邊要進入收尾階段了。

等普及後一些延伸套件裡的寫法也可以用 :has() 來處理了，就不用自己在 javascript 裡面檢查半天...

在 Ubuntu 20.04/22.04 下使用 18.04 的 chromium-browser

Ubuntu 20.04 之後包的 chromium 都是基於 snap 的方案，是個除了 Canonical 的人以外沒人愛的東西，所以大家都在找方法改回 .deb 的版本。

剛剛因為需要測試東西所以才需要找這個方案，發現有個還蠻有趣的解法，是拿 18.04 的 chromium-browser 的套件來裝，因為官方至少會支援到 2023/04：「Is it still possible to install Chromium as a deb-package on 20.04 LTS using some third-party repository?」。

一個 /etc/apt/sources.list.d/bionic-update.list：

deb http://archive.ubuntu.com/ubuntu/ bionic-updates universe

另外一個 /etc/apt/preferences.d/chromium-deb-bionic-updates：

Package: chromium-browser chromium-browser-l10n chromium-codecs-ffmpeg-extra chromium-codecs-ffmpeg 
Pin: release a=bionic-updates
Pin-Priority: 900

完全還是使用官方套件的解法，唯一的缺點大概就是到明年四月而已，但對要測試來說夠用了...

iOS Safari 擋 "Open in App" 的付費套件 Banish

在「New iOS App Blocks Those Annoying 'Open in App' Pop-Ups in Safari」這邊看到 John Gruber 的介紹文章「Banish: New Safari Extension to Block 'Open in App' Dickpanels」，裡面提到的 extension 在「Banish for Safari」這邊，一次性的費用，在台灣是 NT$70。

裡面的 screenshot 給了還蠻清楚的說明：

設定上面因為會牽扯到 privacy 的關係，會有點麻煩，需要開好幾個地方。

順道一提，桌面上的話可以透過 Annoyances 系列的 list 在 uBlock Origin 上擋。

Mozilla 把對各種規格的態度整理成一個網頁

查資料的時候看到「Mozilla Specification Positions」這個，可以看到 Mozilla 對各種規格的態度，分成幾個不同的類型。

有「under consideration」、「important」、「worth prototyping」這幾個從名字上就大概猜的出來意思，接下來的幾個比較有趣的是「non-harmful」、「defer」與「harmful」。

官方的說明是：

  • under consideration: Mozilla's position on this specification is being discussed.
  • important: This specification is conceptually good and is important to Mozilla.
  • worth prototyping: Mozilla sees this specification as conceptually good, and worth prototyping, getting feedback on its value, and iterating.
  • non-harmful: Mozilla does not see this specification as harmful, but is not convinced that it is a good approach or worth working on.
  • defer: Mozilla does not intend to look at this specification at all in the near future.
  • harmful: Mozilla considers this specification to be harmful in its current state.

所以之後看到一些標準時可以過來這邊看看 Mozilla 的態度...

利用字型來判斷使用者是否有安裝特定軟體

在 Hacker News 上的「TeamViewer installs suspicious font only useful for web fingerprinting (ctrl.blog)」這邊看到的技巧，原文在「TeamViewer installs suspicious font only useful for web fingerprinting」這邊，但文章標題本身可以忽略。

這別提到的方法是，在安裝軟體時額外安裝一個特別的字型，然後網頁就可以透過 javascript 判斷這個字型存不存在，來得知使用者是否有安裝自己的軟體，接下來就可以走到不同的 flow：可以導引使用者下載軟體，或是透過 handler 拉起應用程式。

不過這也透漏出了隱私問題，代表廣告商可以利用這點取得 fingerprint，而不只是軟體自家的網站。

看討論串裡面說 Firefox 上可以用 privacy.resistFingerprinting 擋住：「Firefox's protection against fingerprinting」，但 Firefox 本身也沒有說明的太清楚到底會放行哪些字型：

Not all fonts installed on your computer are available to webpages

在「Security/Fingerprinting」這頁則是：

We only allow specific system fonts to be used, and we ship them to the user using kinto

直接試著找 Bugzilla 與 source code 的資料可以翻到「Restrict CSS font visibility to standard fonts only when privacy.resistFingerprinting is true」這個討論，裡面有提到「https://searchfox.org/mozilla-central/search?path=StandardFonts*.inc」這個，可以看到有 Linux、macOS 與 Windows 10 下的清單。

不過 Chromium-based browser 下目前好像沒看到方案...