FTC 出手告 Adobe 的退租機制

在「FTC sues Adobe for hiding fees and inhibiting cancellations (ftc.gov)」這邊看到的,FTC 的稿子在這邊:「FTC Takes Action Against Adobe and Executives for Hiding Fees, Preventing Consumers from Easily Cancelling Software Subscriptions」。

FTC 的標題就講差不多了,然後第一段再更細節一點:

The Federal Trade Commission is taking action against software maker Adobe and two of its executives, Maninder Sawhney and David Wadhwani, for deceiving consumers by hiding the early termination fee for its most popular subscription plan and making it difficult for consumers to cancel their subscriptions.

後面有提到法源依據 Restore Online Shoppers' Confidence Act

The complaint charges that Adobe’s practices violate the Restore Online Shoppers’ Confidence Act.

然後 FTC 內是 3-0 通過,然後在加州北區聯邦地院打官司:

The Commission vote to refer the civil penalty complaint to the DOJ for filing was 3-0. The Department of Justice filed the complaint in the U.S. District Court for the Northern District of California.

這個也是值得期待的案子,會是 dark pattern 在法律上的攻防戰...

Google Public DNS 接受法國法院的阻擋要求

看到「Google, Cloudflare & Cisco Will Poison DNS to Stop Piracy Block Circumvention」這篇,法國在 2022 年通過的體育法律反過來干涉 ISP 或是服務提供商需要配合阻擋:

Tampering with public DNS is a step too far for many internet advocates but for major rightsholders, if the law can be shaped to allow it, that’s what will happen. In this case, Article L333-10 of the French Sports Code (active Jan 2022) seems capable of accommodating almost anything.

拿文章裡面提到的 footybite.cc 測試,實際在法國開一台 Vultr 的 VPS 測試各家 Public DNS 服務,看起來目前 Google Public DNS 已經實作了,而且傳回了 RFC 8914: Extended DNS Errors 內的 EDE 16:

$ dig footybite.cc @8.8.8.8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 16 (Censored): (The requested domain is on a court ordered copyright piracy blocklist for FR (ISO country code). To learn more about this specific removal, please visit https://lumendatabase.org/notices/41606068.)
;; QUESTION SECTION:
;footybite.cc.                  IN      A

目前拿 1.1.1.1 (Cloudflare)、9.9.9.9 (Quad9) 以及 208.67.222.222 (OpenDNS) 都還沒有看到被擋。

另外實際測試,自己架設 Unbound 看起來就可以繞過去了,不知道後續會不會要求更多,像是直接要求在 internet backbone 上面過濾 DNS?(當年推 DNS over TLSDNS over HTTPS 總算要派上用場了?)

另外就是看 Cloudflare 以及其他 Public DNS 服務有沒有反對的動作...

AWS 宣佈了台北區將在 2025 年初推出完整的 3-AZ Region

今天早上在 Facebook 上看到的,AWS 宣佈將在 2025 年年初在台北推出 3-AZ region:「AWS Asia Pacific (Taipei) Region coming soon」。

Amazon Web Services (AWS) announced plans to open a new AWS Region in Taiwan by early 2025. The AWS Asia Pacific (Taipei) Region will consist of three Availability Zones at launch.

剛好也看到有人在討論機房是不是都會在雙北,找了一下 AZ 的規範,發現現在有寫出來一些白紙黑字的東西 (記得以前沒有):「Availability Zones」。

Availability Zones in a Region are meaningfully distant from each other, up to 60 miles (~100 km) to prevent correlated failures, but close enough to use synchronous replication with single-digit millisecond latency.

所以要在一個直徑 100km 的圓蓋住的範圍裡面放機房。

拉了幾個地標,汐科火車站到苗栗火車站的直線距離差不多就剛好 100km,所以如果小道消息說桃園與新竹有 AWS 機房的話也不會太意外。

翻資料看到 CloudFront 是 2014 年進台灣的:「CloudFront 有台灣機房了...」,2018 年開了第二個點與第三個點:「CloudFront 在台北的第二個 PoP」、「CloudFront 在台北增加第三個點...」。

再來是 2022 年做為東京區的 AZ 有了 Local Zone:「AWS 的台北區 (Local Zone) 開了」。

然後現在宣佈在 2025 年開 region (會 delay 嗎?),看起來是有量慢慢拉起來?

幫你打理伺服器環境的 piku

但文件寫的很糟:「The tiniest PaaS you've ever seen. Piku allows you to do git push deployments to your own servers.」。

名字來自於 Dokku,另外應該是用到了 pico 這個數量級詞:

piku, inspired by dokku, allows you do git push deployments to your own servers, no matter how small they are.

這個工具是在「Piku: Allows git push deployments to your own servers (github.com/piku)」這邊看到的,就如同說明提到的,希望透過 git push 就可以發佈軟體。

不過在討論裡面也有人抱怨文件的問題,像是在 id=40625339 這邊就有人提到。

實際到 AWS 上開了一台 EC2 instance 測,看起來就是提供一包 script 把伺服器端設定好,包括了 Let's Encrypt + nginx 以及 SSHGit 相關的設定,接著你可以直接將這台 server 設為 git remote,然後就可以用 git push 推軟體上去了。

對於只是想要跑軟體,而且容易接 CI/CD 的方案來說還算 OK,但如果想要自己客製化 nginx 或是一些工具的情境就不是那麼適用了。

Google 停用了大量與中國與俄羅斯相關的帳號

在「Google Takes Down Influence Campaigns Tied to China, Indonesia, and Russia」這邊看到的,Google 的說明則是在「TAG Bulletin: Q2 2024」這邊,看起來像是例行性的更新?

與台灣有關的當然就是跟中國相關的影響,也是被停最多帳號的,在報告的最後提到 YouTubeBlogger 上面有掃到上千個與中國政府相關的宣傳帳號:

We terminated 1,320 YouTube channels and 1,177 Blogger blogs as part of our ongoing investigation into coordinated influence operations linked to the People’s Republic of China (PRC). The coordinated inauthentic network uploaded content in Chinese and English about China and U.S. foreign affairs. These findings are consistent with our previous reports.

第二多的則是俄羅斯:

We terminated 378 YouTube channels as part of our investigation into coordinated influence operations linked to Russia. The campaign was linked to a Russian consulting firm and was sharing content in Russian that was supportive of Russia and critical of Ukraine and the West.

其他的就比較零頭了...

合併 GitHub Actions 的 IP address

GitHub 官方文件「About GitHub's IP addresses」中,是有提到 https://api.github.com/meta 這組 API endpoint,可以取得當下的 GitHub Actions 所使用的連外 IP address,不過如果你實際掃下來後會發現量相當大,以現在的情況來說,IPv4 address 有 3708 筆,IPv6 address 則有 801 筆:

$ cat github-actions-ipv4.txt | wc
   3708    3708   58233
$ cat github-actions-ipv6.txt | wc
    801     801   17522

實際去看的時候會看到一些吐血的,像是這包 /31 的:

13.105.49.0/31
13.105.49.2/31
13.105.49.4/31
13.105.49.6/31
13.105.49.8/31
13.105.49.10/31
13.105.49.12/31
13.105.49.14/31
13.105.49.16/31

這包還真的就整整 128 筆,你就不能輸出個 13.105.49.0/24 嗎...

ChatGPT 問了要怎麼解決,被提示有 netmask 這個工具可以用,不需要另外自己編譯,可以直接用 apt 裝起來然後倒進去讓他跑就好,整包搭配 jqHTTPie 處理掉 (換 curl 基本上也沒問題):

netmask --cidr -- $(http https://api.github.com/meta | jq -r '.actions[]')

Update:看到資安的朋友按讚突然想到,這邊用了 $() 把資料丟到 command line 包裝,可能會有安全上的顧慮,請自己斟酌...

不過整包 (IPv4 + IPv6) 還是有 3187 行,但總是有個方法可以整理起來用,不用自己刻一堆程式處理...

Now-DNS 的服務

在翻 public_suffix_list.dat 的時候翻到的服務 (參考之前寫的「Mozilla 維護的 Public Suffix List」,或是維基百科上面 Public Suffix List)。

看了一下是 2017 年左右提供 Dynamic DNS 服務:「Creating a Free DDNS Service」服務,似乎沒有限制多少 record?

要說缺點的話,第一個是列出來的 domain 不算漂亮,不過如果是自己有 domain,掛 CNAME 上去的話也已經夠用了。

另外一個是看起來他的 DNS 伺服器都放在 OVH 的機房?雖然地域上是放不同位置,不過還是有滅掉的風險?

看起來可以把一些小東西掛上去用看看?

超長網域名稱會遇到的 TLS certificate 問題

在「L(O*62).ONG: Make your URL longer (looooooooooooooooooooooooooooooooooooooo...)」這邊看到的有趣東西,網站是「L(o*62).ong - Make your URL longer」,網站的主人還在搞事就被貼到 Hacker News 上,所以他就上來說明一下發生了什麼事情...

id=40543697 這邊提到網域名稱過長導致撞到 TLS certificate 中 commonName (CN) 欄位長度限制的問題:

The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.

This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.

Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.

不過後面有人提到 commonName 在網頁用的 TLS certificate 已經 deprecated 很久了,而 Let's Encrypt 在 2023 年的時候已經支援 commonName 留空,改用 Subject Alternative Name,可以到 255 chars。

留言裡面所連結的 Let's Encrypt 公告上面也提到了類似的事情:「Simplifying Issuance for Very Long Domain Names」。

Additionally, the CN is limited to at most 64 characters, while SANs can be significantly longer. This means that the CN is not only redundant, but actively restrictive: a certificate which has a Common Name cannot contain only very long domain names, because none of them would fit in the CN. For these reasons, the BRs state that for Domain Validated certificates, the Common Name field is "not recommended".

所以看起來是各家系統還沒有跟著改 (因為 Let's Encrypt 先前需要 CN 有值),但如果是自己申請的應該是可以自己避開了 (生 csr 的時候就改用 SAN)?

南極洲使用 Internet 的痛點

在「Engineering for Slow Internet (brr.fyi)」這邊看到的,這幾天還蠻紅的文章,在講網路受限的情況下要怎麼想辦法:「Engineering for Slow Internet」,作者是南極洲計畫 (USAP) 的 IT (目前已經回美國本土)。

主要的技術限制有幾個,第一個是對外網路的時間是有限的,因為受限於經過上空的衛星是有限的,這是 2023 年十月的一些資料:

可以看到主要是 DSCS (五顆服役中,但不是每科都有經過南極上空) 與 TDRS-6

這個是物理限制,沒有 workaround 可以做,所以所有人都得照著對應的時段安排傳輸。不過應該有其他的衛星可以隨時聯絡 (emergency channel),畢竟算是半個軍事計畫?

Hacker News 上也有人討論到 Starlink 好像還是有一些衛星會飛過南極洲,但不確定是否有 relay 的能力,如果有的話似乎也能考慮看看?(不過可能會需要客製天線,畢竟緯度的關係,設備需要的工作溫度區間不太一樣)

另外一個大問題是 latency,平均的 latency 是 750ms,而且 jitter 會到數秒:

Round-trip latency averaging around 750 milliseconds, with jitter between packets sometimes exceeding several seconds.

第三個是速度,一般使用者的平均網路速度大約是個位數的 kbps 到狀況好的時候大約是 2mbps,差不多是 1990 年代數據機的速度:

Available speeds, to the end-user device, that range from a couple kbps (yes, you read that right), up to 2 mbps on a really good day.

文章基本上就是圍繞這些問題在討論。

因為 latency 過高,而很多應用程式 (web 或是 app) 寫死 timeout,所以造成網路明明就有慢慢在傳輸資料,你放著慢慢傳遲早會傳完,但卻因為超時而失敗。

另外因為頻寬有限的問題,沒有提供續傳機制 (app 裡面沒做,或是沒有提供檔案直接讓有技術能力的人下載,像是 wget -c 這樣的工具) 就很容易因為失敗浪費頻寬。

另外是遇到軟體更新機制 (像是安全性更新) 無法下載檔案後直接安裝,都會有裝到一半中間要連網的事情。

另外一塊是現在太多工具太肥大,一個簡單的功能要先下載一包 20MB javascript 之類的 (然後換算一下前面提到的頻寬,在網路最好的情況下得花 80 秒下載這包 javascript)。

如果你的使用者族群包括了這類網路狀況不是很好的地區,這篇提到的蠻多東西都還蠻值得參考的。

Openpanel:Mixpanel 的 Open Source Clone

在「Show HN: Openpanel – An open-source alternative to Mixpanel (github.com/openpanel-dev)」這邊看到的專案,GitHub 頁面在「Openpanel」這邊。

主要是因為 Mixpanel 的價錢很詭異,另外作者也希望可以同時追蹤一般常見的 pageview 資訊 (像是 GA4 或是 Plausible),所以作者就跳下來自己寫了...

除了 self-hosted 版本以外,也有 cloud 版本可以先看看介面,或是丟一些量進去看看操作起來如何。