在 Android 上的 NewPipe (YouTube 播放器)

會看到「NewPipe」這個軟體,是因為之前有抹黑 NewPipe 的事情而看到的 (可以參考「My Google account got suspended because of NewPipe #2723」這邊),這個軟體的目標是在 Android 上不使用 Google 在 Android 上的專屬 API,以及 YouTube 的 API,純粹爬頁面提供對應的影音服務:

NewPipe does not use any Google framework libraries, nor the YouTube API. Websites are only parsed to fetch required info, so this app can be used on devices without Google services installed. Also, you don't need a YouTube account to use NewPipe, which is copylefted libre software.

除了 YouTube 以外,目前還支援兩個服務:

  • YouTube
  • SoundCloud [beta]
  • media.ccc.de [beta]

然後分析頁面內容這種方式提供 YouTube 服務當然無法上 Google 自家的 Google Play Store,需要先安裝 F-Droid,然後再用 F-Droid 搜尋並下載。

用起來其實還不錯,一樣有播放記錄但是是存在本機,而且看起來可以匯出匯入;有書籤功能可以管理影片。整體的自主性高不少...

然後測到現在還沒看到廣告,這應該也是好用的地方...

Google Chrome 78 又要搞事把 www 開頭拿掉了...

剛剛改回用 beta channel 的 Google Chrome (78 版),結果發現網址列裡的 www 被拿掉,而且本來可以關掉的方式 (omnibox-ui 系列的設定) 從 chrome://flags 裡面也拔掉了,代表你現在關不掉了...

搜了一下資料,發現在 Reddit 上有人討論過 78 版的這個問題 (當時還在 dev channel):「Chrome 78 dev hide 'www' again」。

裡面有人提到可以安裝 Suspicious Site Reporterwww 重現,當初看到還半信半疑,結果裝了發現真的會動,WTF...

看了一下 extension 的 source code 發現好大一包,以後應該會有人生一個小的 extension 出來專門做這件事情?

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

Syncthing 發行 1.0.0 版

Syncthing 是一個檔案分享軟體,如果要說類型的話,可以看作是 Dropbox 的 open source 版本,找台便宜的 VPS 主機就可以架起來丟著 (挑個空間夠大的 OpenVZ instance)。

官方在前幾天宣佈推出 1.0.0 了:「Syncthing graduation day」。會推出主要的原因是現在的版本其實夠穩定,就不要因為 0.x 版而造成使用者誤解了 (這邊應該是在講因為 Semantic Versioning 的流行,0.x 版會給人不穩定的印象):

As much as a version number means anything at all, a “major zero” version number means that you can expect breakage. This is not what we want to communicate. Especially, it’s not the mindset that we should have towards our users. Hence Syncthing is now graduating from being in perpetual beta to being actual release software, yet the journey of development continues.

來把手上的機器都升級上去...

Chrome 72+ (目前在 Beta 的版本) 對延伸套件的影響

我的桌機平常都是跑 beta channel 的 Chrome,所以前陣子已經升級到 72,然後發現兩個問題:

從 dev console 可以看到問題都是 Referer 沒被送出,導致有檢查 Referer 的網站拒絕存取,後來在「chrome.webRequest」這邊發現是 Chrome 72+ 改了規則,裡面提到了:

Starting from Chrome 72, the following request headers are not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

Accept-Language
Accept-Encoding
Referer
Cookie

Starting from Chrome 72, the Set-Cookie response header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec.

不確定這個設計的目的是什麼,但反正已經中獎了,總是得回報給各 extension 的維護者讓他們修正 (用 beta channel 的重要任務之一?)。

所以就先去 Tampermonkey 開 ticket,也很迅速的在 beta 版修正了 (所以只能先改裝 beta 版):「GM_xmlhttpRequest unable to set referer in Chrome 72+ #629」。

另外跟 Referer Control 的開發者回報這個問題,也修正出新版上架了,更新就生效了:「refererControlDisqus.html」。

目前看起來還有「Spoofs Lang」得修,不過這個軟體好久沒更新了,不知道有沒有機會...

關閉新版 Google Chrome 網址列雞婆省略 www 的行為...

因為平常用的 Google Chrome 是 beta channel,前陣子出新版後網址遇到 wwwm 時就會不見,像是網址輸入 https://www.google.com,在連上後會變成這樣:

這樣讓人很不習慣,當時在網路上找了一些資料都沒找到,結果剛剛找資料時意外發現找到解法了:「Chrome address bar no longer shows protocol or www subdomain」。

把這個選項改成 Disabled 後,重開瀏覽器就恢復原來的行為了...

Cloudflare Worker 進入 Open Beta 讓大家玩了...

去年 Cloudflare 宣佈了 Cloudflare Worker,讓使用者可以在 Edge 端跑 JavaScript (參考「Cloudflare 也能在各端點跑 JavaScript 了」),也就是可以在 Cloudflare 節點上面對 HTTP request 與 HTTP response 做更多事情,類似於 AWSLambda@Edge

不過去年公佈的當時需要申請才有機會用,算是 Private Beta。現在則是開放讓大家玩 (Open Beta) 讓大家幫忙測試了:「Cloudflare Workers is now on Open Beta」。

文件在「Cloudflare Workers Docs」這邊可以取得,就如同去年 Cloudflare 所提到的,程式的撰寫上是透過 Service Worker 的界面,這樣就不用再學一套:

Cloudflare Workers are modeled on the Service Workers available in modern web browsers, and use the same API whenever possible.

現階段 Cloudflare Worker 是免費的,看起來是用這段時間的用量與用法來看要怎麼設計收費機制:

Cloudflare Workers is completely free during the open beta. We do intend on charging for Workers, but we will notify you of our plans at least thirty days before any changes are made.

Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443

Cloudflare 推出了 Wrap 服務:「Want to try Warp? We just enabled the beta for you」。

本地端的 web server 可以只開 127.0.0.1:{80,443},然後 Wrap 的程式會連到 Cloudflare 上面接 web request 回來打到你本地端的電腦上,官方舉的例子用 port 8080:

$ cloudflare-warp --hostname warp.example.com http://localhost:8080

然後也支援多台機器接同一個 hostname (load balancing,順便做 high availability):

$ cloudflare-warp --hostname warp.example.com --lb-pool origin-pool-1 http://localhost:8080

對於安全架構多了一些選擇可以用...

Cloudflare 也能在各端點跑 JavaScript 了

類似於 AWS 先前推出的 Using CloudFront with Lambda@Edge (參考「在 CloudFront 的 edge 上跑 Lambda」以及「Lambda@Edge 的 GA」),Cloudflare 也推出了類似的功能:「Introducing Cloudflare Workers: Run Javascript Service Workers at the Edge」、「Code Everywhere: Why We Built Cloudflare Workers」。

整個系統是架構在 Chrome V8 上,尤其是安全性的部分是 Cloudflare 的人頗讚賞的重點:

Security: The V8 JavaScript engine is arguably the most scrutinized code sandbox in the history of computing, and the Chrome security team is one of the best in the world. Moreover, Google pays massive bug bounties to anyone who can find a vulnerability. (That said, we have added additional layers of our own sandboxing on top of V8.)

比較不一樣的地方在於 Cloudflare 拿 Service Worker API 來設計他們的架構,AWS 則是自己幹了一套出來...

然後現在還沒給出價錢,也還沒完全開放使用... 想要玩的人需要申請 beta。

Google Chrome 對 Symantec 全系列憑證的不信任計畫

Google Chrome 前陣子整理了一份對 Symantec 憑證的不信任計畫:「Chrome’s Plan to Distrust Symantec Certificates」。

這包括了一卡車的品牌,像是 ThawteVeriSignGeoTrustRapidSSL,不過 Equifax 跟 Symantec 的關係我沒查到...:

Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements.

反正整個計畫會在 Google Chrome 70 推出時告一段落 (變成完全不信任),會是 2018/09/13 (預定時間) 與 2018/10/23 (預定時間) 在 beta channel 與 stable channel 上推出。

中間比較重要的時間點是 2018/03/15 (預定時間) 與 2018/04/17 (預定時間),Google Chrome 66 在 beta channel 與 stable channel 上推出,這個版本不會信任 2016/06/01 前發出的憑證:

Chrome 66 released to beta, which will remove trust in Symantec-issued certificates with a not-before date prior to June 1, 2016. As of this date Site Operators must be using either a Symantec-issued TLS server certificate issued on or after June 1, 2016 or a currently valid certificate issued from any other trusted CA as of Chrome 66.
Site Operators that obtained a certificate from Symantec’s old infrastructure after June 1, 2016 are unaffected by Chrome 66 but will need to obtain a new certificate by the Chrome 70 dates described below.

整個計畫的時間軸清楚多了...