Chrome 打算要終止支援 FTP 協定

從「Google plans to deprecate FTP URL support in Chrome」這邊看到的,狀態資訊可以在「Deprecate FTP support」這邊看到。

以目前的 timeline 資訊,看起來是 M82 版本會完全拔掉:

M78 (2019Q4)
Finch controlled flag and enterprise policy for controlling overall FTP support.

Support disabled on pre-release channels.

M80 (2020Q1)
Gradual turndown of FTP support on stable.

M82 (2020Q2)
Removal of FTP related code and resources.

不過這樣就沒有方便的 FTP downloader 了 (雖然不常見),得另外再找軟體下載...

即時將動畫 Upscale 到 4K 畫質的演算法

看到「Anime4K」這個專案:

Anime4K is a state-of-the-art*, open-source, high-quality real-time anime upscaling algorithm that can be implemented in any programming language.

State of the art* as of August 2019 in the real time anime upscaling category, the fastest at acheiving reasonable quality. We do not claim this is a superior quality general purpose SISR algorithm compared to machine learning approaches.

他們提供的數據顯示 1080p -> 2160p (4K) 只要 3ms,對於 60fps 來說是相當足夠,而品質看起來也還不錯。

其中一個蠻有趣的問答是 1080p -> 2160p 反而比 480p -> 720p 簡單,因為 1080p 裡面因為有更多資料量,所以處理起來比較簡單:

Why not do PSNR/SSIM on 480p->720p upscaling
Story Time

Comparing PSNR/SSIM on 480p->720p upscales does not prove and is not a good indicator of 1080p->2160p upscaling quality. (Eg. poor performance of waifu2x on 1080p anime) 480p anime images have a lot of high frequency information (lines might be thinner than 1 pixel), while 1080p anime images have a lot of redundant information. 1080p->2160p upscaling on anime is thus objectively easier than 480p->720p.

Apple 對 Tracking 機制的宣言 (宣戰)

Apple 透過 WebKit 的 blog 公佈了對 tracking 技術的宣言 (或者說「宣戰」):「Announcing the WebKit Tracking Prevention Policy」,完整的文件在「WebKit Tracking Prevention Policy」可以看到。

相關的報導可以參考「Apple will soon treat online web tracking the same as a security vulnerability」。這篇會這樣下標題主要是這點:

We treat circumvention of shipping anti-tracking measures with the same seriousness as exploitation of security vulnerabilities.

不過技術上還是很困難,現在在瀏覽氣上有太多方式可以被拿來追蹤分析。

另外也不用認為蘋果是什麼善類,他只是不太靠廣告賺錢,所以會決定站出來把隱私保護當產品在推銷,哪天有什麼奇怪的特例跑出來的時候也不用太意外...

操作 S3 Command Line 的工具

在朋友的 Facebook 上看的東西:「S5cmd for High Performance Object Storage」。會想要寫這篇是因為看到 s4cmds5cmd 這兩個工具的命名而笑出來:

不過這篇也可以看到差異,s3cmd 是自己用 Python 刻所有東西,s4cmd 還是用 Python,但是因為 boto3 而快了不少,而 s5cmd 則是改用 Golang 寫,並且採用多個 TCP connection 操作而讓效能大幅提昇。

在 Windows 10 下面執行 Wine

試著在 Windows 10 下跑 Wine,結果文章作者發現意外的簡單:「Wine on Windows 10. It works.」。

實際上大多數的事情是透過 Windows 10 的 WSL (Windows Subsystem for Linux) 所疊出來的,可以從這步看到:

3. Open the Microsoft Store, install Ubuntu. (This is basically what WSL was created to run.) I installed "Ubuntu 18.04 LTS". Open Ubuntu, and you'll see a bash terminal.

這是作者的成果:

還是有些限制 (像是目前還 32 bits 程式還要等之後的 WSL 支援),但比起早年得自己從頭搞起來簡單不少 (而且問題不少),算是完成作者的悲怨?

透過把 .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 時檢查的問題)

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

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

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.

在 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 當理由,看起來是有人離職了所以就加回來...