ARC (Authenticated Received Chain)

標題的 ARC 是指 Authenticated Received Chain,是前陣子在 Hacker News 上看到「Gmail accepts forged YouTube emails (john-millikin.com)」這篇才發現的東西,原文在「Gmail accepts forged YouTube emails」這邊。

作者發現 Gmail 收了從不是直接從 YouTube 發出來的信件:

主要的原因是,Gmail 除了使用標準的 SPFDKIM 判斷外,還吃上面提到的 ARC。

查了一下 ARC,標準是 RFC 8617,目前還是被標成 experimental,主打是解決 forwarding 的問題,看了一下作者群是 LinkedIn (Microsoft)、GoogleValimail

ARC 這東西與之前 Google 在強推的 AMP (然後被罰) 以及現在在推的 Signed HTTP Exchanges 都有相同的味道,無視 security & privacy concern 的東西...

Google 在歐盟的服務將提供 Reject All Cookies 的按鈕

看到「Google gives Europe a ‘reject all’ button for tracking cookies after fines from watchdogs」這篇,在講 Google 在歐盟的服務開始提供 Reject All Cookie 的按鈕,其中 Google 官方的公告可以在「New cookie choices in Europe」這邊看到。

Reject All Cookies 的按鈕是像這樣的設計:

照報導說的,今年初的時候法國罰了 Google 一億五千萬歐元,因為 Accept All Cookies 只要一個按鍵,但 Reject All Cookies 需要按很多選單才能達成,而法國認為這樣非對稱式的設計是違法的:

Earlier this year, France’s data protection agency CNIL fined Google €150 million ($170 million) for deploying confusing language in cookie banners. Previously, Google allowed users to accept all tracking cookies with a single click, but forced people to click through various menus to reject them all. This asymmetry was unlawful, said CNIL, steering users into accepting cookies to the ultimate benefit of Google’s advertising business.

Google 的說明裡面也有提到法國的事情,但當然沒有提到罰款:

Based on these conversations and specific direction from France’s Commission Nationale de l’Informatique et des Libertés (CNIL), we have now completed a full redesign of our approach, including changes to the infrastructure we use to handle cookies.

另外就是這個功能目前只在法國啟用,後續會放到整個歐盟區:

We’ve kicked off the launch in France and will be extending this experience across the rest of the European Economic Area, the U.K. and Switzerland.

美國人使用社群媒體的情況

在「Social Media Usage by Age」這邊看到的文章,把美國人使用社群媒體的情況做成圖,資料來源是 Pew Research Center 的「Social Media Fact Sheet」這裡。

很明顯的可以看到 Google (Alphabet) 基本上就是 YouTube 一個產品吃天下,而 Facebook (Meta) 有三個產品在滲透,包括 Facebook、InstagramWhatsapp

LinkedIn 在出社會後會開始用,另外 Pinterest 這麼多老人家在用到是很驚奇 XDDD

社群維護的 YouTube Private API 套件

一樣是今天的 Hacker News Daily 上看到的東西,透過 YouTube 的 Private API 操作 YouTube 的套件:「Youtube.js – full-featured wrapper around YouTube's private API (github.com/luanrt)」。

這些 Private API 就是 YouTube 自己在網站上用的:

A full-featured wrapper around the Innertube API, which is what YouTube itself uses.

也因為這不是 Public API,也就不需要申請 key:

Do I need an API key to use this?

No, YouTube.js does not use any official API so no API keys are required.

當然可以預期他會無預警壞掉,所以可以自己衡量一下要怎麼搞...

比較有趣的是 Hacker News 的討論裡面反而有人在問要怎麼偵測這種 library 或是 bot XDDD

If you’re YouTube or any site, and want to stop these sort of wrappers - what’s the easiest way to do so without breaking your own site?

I find this task to be an interesting engineering problem.

A related question is if there’s an unspoofable way to detect a client.

不過掃了一下好像還好...

用 uBlock Origin 的自訂條件把 YouTube 的 Shorts 都拔掉

先拔掉 YouTube 訂閱頁裡面的 shorts 連結:

www.youtube.com##:matches-path(/feed/subscriptions) ytd-grid-video-renderer:has(a[href^="/shorts"])

再來拔掉首頁左邊出現的 shorts 分類連結:

www.youtube.com##ytd-mini-guide-entry-renderer:has(a[title="Shorts"])

必須說 :has() 真的是很好用...

把 YouTube 的 Dislike 數字弄回來

最近 YouTube 也在搞事,把 Dislike 的數字拔掉了,後來在 Greasy Fork 上面找了一下,看到有兩套方法可以把數字補回來。

第一套是「Return YouTube Dislike」這個方法,從程式碼裡面可以看到是透過 API 拉出來的:

function setState() {
  cLog('Fetching votes...');
 
  doXHR({
    method: "GET",
    responseType: "json",
    url:
      "https://return-youtube-dislike-api.azurewebsites.net/votes?videoId=" +
      getVideoId(),
    onload: function (xhr) {
      if (xhr != undefined) {
        const { dislikes, likes } = xhr.response;
        cLog(`Received count: ${dislikes}`);
        setDislikes(numberFormat(dislikes));
        createRateBar(likes, dislikes);
      }
    },
  });
}

這個 API 後面應該是接 Videos: getRating 拉資料出來,但畢竟不是直接打 YouTube API (比較麻煩,需要每個使用者自己申請 API token),這樣就有隱私的疑慮了...

另外一套是「Show Youtube Dislike Count」,看了裡面程式碼發現他是用 averageRating 反推回來:

if (likeCount >= 0) {
    const r = data.playerResponse.videoDetails.averageRating;
    const dislikeCount = Math.round(likeCount * (5 - r) / (r - 1));

    ShowDislikes(likeCount, dislikeCount);
}

不過作者有點偷懶,這邊在等待頁面生成單純用 100ms 等頁面出現,有時候還是會有 race condition (就是後面還是讀不到 XDDD),如果懶的大修的話可以改成 1000ms 混過去,降低一些機率:

while (!isLoaded) {
    await Sleep(100);
}

另外數字很大的時候會稍微不準,但也算夠用了,先暫時用這套來頂著了...

歐盟對 Google 的 24.2 億歐元的罰款確定

從「Google loses challenge against EU antitrust ruling, $2.8-bln fine」這邊看到的,新聞的標題寫的是換算後的美金。

新聞裡提到歐盟主要有三個主題在跟 Google 訴訟,這次確定的是利用搜尋引擎偏好自家的購物比較服務,產生不公平競爭:

Competition Commissioner Margrethe Vestager fined the world's most popular internet search engine in 2017 over the use of its own price comparison shopping service to gain an unfair advantage over smaller European rivals.

另外兩個還在進行的是 AndroidAdSense

The company could face defeats in appeals against the other two rulings involving its Android mobile operating system and AdSense advertising service, where the EU has stronger arguments, antitrust specialists say.

應該是還有個 YouTube 才對,不過印象中主要是版權相關的問題,跟 antitrust 這邊的關係好像少了一些...

youtube-dl 的恢復與後續 GitHub 的處理模式

youtube-dl 被下架的事情後續又有不少進展了 (先前寫過「youtube-dl 被 RIAA 用 DMCA 打下來的事件」這篇),主要是 GitHub 恢復了 youtube-dl 的 Git Repository,然後丟出了一篇文章解釋過程,以及後續的作法:「Standing up for developers: youtube-dl is back」。

要注意這次的事件完全是法律戰,所以裡面發生的敘述都是各自的說法,大家可以自己解讀...

GitHub 的這篇文章是由 Abby Vollmer 發表的,從 LinkedIn 上的資料也可以看到他以前的經歷都是法律相關,現在在 GitHub 的頭銜是「Director of Platform Policy and Counsel」,而這篇的用字也可以看出來很小心。

首先 GitHub 認為下架的原因是 Section 1201:

Section 1201 dates back to the late 1990s and did not anticipate the various implications it has for software use today. As a result, Section 1201 makes it illegal to use or distribute technology (including source code) that bypasses technical measures that control access or copying of copyrighted works, even if that technology can be used in a way that would not be copyright infringement. Circumvention was the core claim in the youtube-dl takedown.

而 GitHub 後續恢復 youtube-dl 的原因是收到 EFF 代表 youtube-dl 開發者所做的 counter notice:「2020-11-16-RIAA-reversal-effletter.pdf」。

照以往這種把事情搞超大的慣例,RIAA 應該是不會有後續的動作,所以就 youtube-dl 這件事情來說應該是差不多告一段落。

GitHub 後續針對 Section 1201 提出了兩個改善措施,一個是重新設計 Section 1201 的處理方式,另外一個是 GitHub 自己投入資金,降低 developer 的負擔。

但整件事情背後的問題主要是在 DMCA 的設計,讓濫發 takedown notice 的人很難受罰,在這點沒有改善之前,同樣的劇碼應該都還是會繼續上演。

即使你不開營利,YouTube 也開始會顯示廣告了...

在「YouTube Will Now Show Ads On All Videos Even If Creators Don’t Want Them」這邊看到的消息,YouTube 現在會針對非營利的影片也開始放廣告了,而且不會分潤給創作者:

看到新聞當下馬上想到的是「NiceChord 好和弦」這個完全不開平台廣告的頻道,然後剛剛就看到他貼出來:(出自 https://www.facebook.com/nicechord/posts/2800689726883136 這邊,Facebook 的 embed 太麻煩了...)

他挑的是 LBRY 這個架構的平台,不過記得 LBRY 平台的頻寬部份需要自己打理,這點 lbry.tv 是有弄一組出來 (cdn.lbryplayer.xyz),但對於台灣這邊的連線品質就不太行... 不過這讓我想把 cdn.lbryplayer.xyz 放進 SmokePing 裡面監控看看。

不過就算自己要處理頻寬成本應該也還好,馬上想的到的方法是 Backblaze + Cloudflare 這種方式,不過我記得 Cloudflare 很明顯很不歡迎這種用法,量大的 YouTuber 切過去的瞬間大概就會被處理 XD

如果考慮自己付錢,像是 EGI Hosting 的美國頻寬對台港區還算堪用,Bare Metal Server Plans 這邊有看到 USD$60/month 提供 20TB/month 的頻寬,大約是 USD$0.003/GB。

更低的像是 OVH 的「Dedicated server prices - Discover our solutions | OVHcloud」,500Mbps 也差不多是 USD$60/month,只算 1/3 使用率的話大約是 50TB,成本會降到 USD$0.0012/GB

不過 LBRY 更大的問題是他還搞了 blockchain 出來,這滿滿 (逼~) 的味道,到底做不做的起來就不曉得了 XDDD

youtube-dl 被 RIAA 用 DMCA 打下來的事件

youtube-dl 的這件事情的後續影響意外的大 (引發了 Streisand effect),除了這算是 RIAA 的最新力作以外,還發生了好幾個首次出現的過程 (而且有些事情還在進行),值得花一些時間挑出幾個比較有趣的地方記錄。

在英文版維基百科的「youtube-dl」與中文版維基百科的「youtube-dl」上面也陸陸續續把發生的經過都記錄起來了,有興趣的人也可以去看看。

RIAA 的動作不算太意外,比較特別的是這次的 takedown notice 不是常見的 DMCA 512 侵權宣告,而是宣稱 youtube-dl 故意繞過 YouTube 的「保護機制」的工具:「The RIAA’s fraudulent attack on youtube-dl is not a DMCA §512 infringement/safe-harbour, and the reality is weird」,除了本身的文件以外,大家發現在 test case 裡面試著下載 YouTube 上的版權影片也可能是個明顯的問題。

另外是 GitHub 現在的 CEO,Nat Friedman,親自跑到 youtube-dl 的 IRC 上面「討論」後續可能的作法,這點也是讓大家愣住的地方:「RIAA’s YouTube-DL Takedown Ticks Off Developers and GitHub’s CEO」。

不過最近 GitHub 又警告了使用者不要重新上傳 youtube-dl 的程式碼,這有可能會被 ban XDDD:「GitHub Warns Users Reposting YouTube-DL They Could Be Banned」,對應的修改在「add statement about reposting and tos violating content」這邊。

這齣戲還在演...