在 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 搜尋並下載。

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

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

Safari 上 uBlock Origin 的情況

uBlock Origin 在 2016 的時候 porting 到 Safari 上,但在 2018 後就沒有再更新了,維護者在「Explanation of the state of uBlock Origin (and other blockers) for Safari #158」這邊說明了目前的情況。

主要就是蘋果要廢掉本來的 Extension API,而替代的框架裡沒有對應的 content filtering 能力,所以在新的框架內無法實做 uBlock Origin 的功能...

維護者的建議是換瀏覽器,但其實可以選擇的瀏覽器愈來愈少了 (因為 Google Chrome 這邊也在搞),所以維護者的建議就是換成 Firefox

另外我自己會建議用看看 Brave,因為 Brave 已經決定,如果 Google Chrome 修改 webRequest 的阻擋能力 (也就是這次的 Manifest V3),他們會繼續維持本來的相容性,所以可以預期 uBlock Origin 應該還是會動 (參考之前寫的「Brave 試用」這篇)。

iOS 上的 Yubikey

在「Yubico iOS Authentication Expands to Include NFC」這邊看到 iOS 13 上對於 NFC 類的 MFA 會有的進展。

主要是因為之前的 NFC 只有讀取能力,所以 U2F/FIDO2/WebAuthn 之類的應用沒有辦法套用上去:

Previously, NFC on iOS was read-only, which meant that it couldn’t support modern authentication protocols like FIDO U2F, FIDO2/WebAuthn that require both read and write capabilities – but now that has changed.

iOS 13 後開放了 API 可以讀寫,所以有辦法支援這些協定了:

With these recent updates, iPhone users (running iOS 13+) can experience mobile NFC authentication with a YubiKey 5 NFC or Security Key NFC by Yubico on apps and browsers that have added support.

對於主力放在 Apple Ecosystem 的人,總算是等到了...

Backblaze B2 的 Copy File API 終於開放

BackblazeB2 算是我還蠻愛用來丟一些東西的地方 (配合他們與 Cloudflare 合作的免費頻寬)。

先前 B2 一直沒有複製檔案的功能,如果要有同樣檔案,變成得自己再上傳一次,這對於網路沒有很快的使用者會很痛苦,現在總算是提供 API 可以直接複製了:「B2 Copy File is Now Public」。

這個功能主要的文件在「b2_copy_file」。

另外這次也推出了「b2_copy_part」,針對檔案的合併所提供的 API。

AWS 的 EBS 預設型態改為 GP2 (SSD)

AWS 宣佈 EBS 的預設型態從 Standard 變成 GP2:「EBS default volume type updated to GP2」。

包括 web console 與 API 的預設值都改成 GP2:

The AWS console defaults to GP2 in all regions. On July 29th the default EBS volume type was updated in thirteen regions from Standard to GP2. Now AWS API calls for volume, image, and instance creation also default to GP2 in all regions.

GP2 是 SSD,所以可以提供比較低的 latency,而另外一個用 GP2 的好處是 i/o 的費用已經含在內了 (Standard 會另外收取費用),對於成本估算會比較簡單一些,尤其是 i/o 量比較大的時候。

在 Chrome 的 FileSystem API 的漏洞被補上後,偵測私密瀏覽模式的方式

Google Chrome 74 版修掉了一般模式與私密瀏覽模式下 FileSystem API 明顯的不同處後,自然就會有人研究其他的偵測方式:「Bypassing anti-incognito detection in Google Chrome」。

作者提出來的方式是透過 Quota Management API,一般模式與私密瀏覽模式下會得到不同的值,尤其是硬碟夠大的時候上限是不一樣的:

不過這個看起來應該比較好修?

破 reCAPTCHA 的 Buster

在「用 Google 的 Speech Recognition API 破 Google 的 reCAPTCHA」與「reCAPTCHA 與語音辨識:以子之矛,攻子之盾」都提過用語音辨識功能破 reCAPTCHA,現在又有一套了,而且直接在各瀏覽器的 extension 平台上架:「Buster: Captcha Solver for Humans」。

說明可以看到一樣是透過聲音的部份辨識:

Buster is a browser extension which helps you to solve difficult captchas by completing reCAPTCHA audio challenges using speech recognition. Challenges are solved by clicking on the extension button at the bottom of the reCAPTCHA widget.

除了安裝很簡單以外,設定也弄得很簡單,這個套件支援多種不同語音辨識 API,包括 GoogleMicrosoft 以及 IBM 的服務,只要在套件的設定頁輸入 API key 就可以了...

另外剛好也跟 reCAPTCHA 有關,在 Hacker News 上的「Google's Captcha in Firefox vs. in Chrome (grumpy.website)」看到 Google Chrome 與 Mozilla Firefox 在跑 reCAPTCHA 的不同之處 (Chrome 的流程順很多,Firefox 卡很多),不過我覺得證據還有點弱,需要再看其他的測試...

另外裡面有提到一些奇怪的東西,像是 W3C 的替代方案 (這個組織提的東西...):「Inaccessibility of CAPTCHA」,找時間來研究一下...

Let's Encrypt 的 ACMEv1 將在今年十一月進入日落階段

Let's Encrypt 推出 ACMEv2 後要終止 ACMEv1 的計畫,是今年三月發的消息,但一直沒注意到,剛剛翻到「acme-client(1) moves to Let's Encrypt v02 API」時才看到的:「End of Life Plan for ACMEv1」。

日落分成幾個階段,第一個階段是今年十一月終止透過 ACMEv1 註冊新帳號:

In November of 2019 we will stop allowing new account registrations through our ACMEv1 API endpoint. Existing accounts will continue to function normally.

第二個階段是明年六月終止透過 ACMEv1 申請新的 certificate:

In June of 2020 we will stop allowing new domains to validate via ACMEv1.

第三個階段是 2021 年會開始測試關閉 ACMEv1 的 renew 功能,一個月不會超過一次,每次大約 24 小時,這是讓 client 有機會丟出錯誤訊息:

Starting at the beginning of 2021 we will occasionally disable ACMEv1 issuance and renewal for periods of 24 hours, no more than once per month (OCSP service will not be affected).

最後的階段是 2021 年的六月,會完全關閉 ACMEv1 所有的服務:

In June of 2021 we will entirely disable ACMEv1 as a viable way to get a Let’s Encrypt certificate.

目前在用的都支援 ACMEv2 了,應該是 ok...

在 AWS 強制使用 MFA 的情況下,透過 CLI 操作

AWS 可以設定 IAM 使用者強制使用 MFA (包括 API 的操作),在這種情況下如果要使用 AWS Command Line Interface 就得透過 AWS STS (AWS Security Token Service) 產生另外一組 key + secret + session key,然後這組通行時間預設是 12 小時。

相關的文章可以參考「How do I use an MFA token to authenticate access to my AWS resources through the AWS CLI?」這篇,然後我就寫了一段 shell script 來做這件事情。

首先是在 ~/.aws/config 內放入 MFA 的 ARN,像是這樣:

[profile mycompany]
mfa = arn:aws:iam::012345678901:mfa/gslin
region = us-east-1

然後就可以用 aws.mfa mycompany 指令產生出一個會把 key + secret + session key 包進去的 shell:

function aws.mfa() {
    local MFA_ARN
    local MFA_TOKEN
    local PROFILE="$1"
    local STSDATA

    MFA_ARN="$(python3 -c "import configparser; import os; c=configparser.ConfigParser(); c.read('{}/.aws/config'.format(os.environ['HOME'])); print(c['profile ${PROFILE}']['mfa'])")
"
    echo "Reading ${PROFILE} and going for token ${MFA_ARN} ..."

    echo -n 'MFA Password: '
    read -r MFA_TOKEN

    STSDATA="$(aws --profile "${PROFILE}" sts get-session-token --serial-number "${MFA_ARN}" --token-code "${MFA_TOKEN}")"
    export AWS_ACCESS_KEY_ID="$(echo "${STSDATA}" | jq -r .Credentials.AccessKeyId)"
    export AWS_SECRET_ACCESS_KEY="$(echo "${STSDATA}" | jq -r .Credentials.SecretAccessKey)"
    export AWS_SESSION_TOKEN="$(echo "${STSDATA}" | jq -r .Credentials.SessionToken)"

    echo 'Running an independant shell...'
    ${SHELL}
}

很明顯的裡面用到了 Python 3 與 jq,這兩個應該都可以直接裝系統的版本就可以了。

後續的操作就跟原來的用法都一樣,像是 aws --region=us-east-1 s3 ls 這樣的指令。

Amazon S3 淘汰 Path-style 存取方式的新計畫

先前在「Amazon S3 要拿掉 Path-style 存取方式」提到 Amazon S3 淘汰 Path-style 存取方式的計畫,經過幾天後有改變了。

Jeff Barr 發表了一篇「Amazon S3 Path Deprecation Plan – The Rest of the Story」,裡面提到本來的計畫是 Path-style model 只支援到 2020/09/30,被大幅修改為只有在 2020/09/30 後建立的 bucket 才會禁止使用 Path-style:

In response to feedback on the original deprecation plan that we announced last week, we are making an important change. Here’s the executive summary:

Original Plan – Support for the path-style model ends on September 30, 2020.

Revised Plan – Support for the path-style model continues for buckets created on or before September 30, 2020. Buckets created after that date must be referenced using the virtual-hosted model.

這樣大幅降低本來會預期的衝擊,但 S3 團隊希望償還的技術債又得繼續下去了... 也許再過個幾年後才會再被提出來?