Amazon Echo 會「聽」並且將資料送到第三方廣告平台

前陣子看到的研究報告,證實 Amazon Echo 會聽取資訊並且將這些資料送到第三方的廣告平台上 (會送到 Amazon 自家應該不算新聞):「Your Echos are Heard: Tracking, Profiling, and Ad Targeting in the Amazon Smart Speaker Ecosystem」。

先從 abstract 開始看,主要是目前這些 smart speaker 基本上沒有透明度,所以十位作者群們建立了一套評估用的 framework 用來測試各家 smart speaker 資訊蒐集已經影響的情況:

Smart speakers collect voice input that can be used to infer sensitive information about users. Given a number of egregious privacy breaches, there is a clear unmet need for greater transparency and control over data collection, sharing, and use by smart speaker platforms as well as third party skills supported on them. To bridge the gap, we build an auditing framework that leverages online advertising to measure data collection, its usage, and its sharing by the smart speaker platforms.

這次論文裡面提到的目標就是 Amazon Echo 會將聽到的東西分享給第三方的廣告平台,並且讓廣告平台可以調整競價 (賺更多的錢),而且這些資訊並沒有被揭露在 privacy policy 裡面:

We evaluate our framework on the Amazon smart speaker ecosystem. Our results show that Amazon and third parties (including advertising and tracking services) collect smart speaker interaction data. We find that Amazon processes voice data to infer user interests and uses it to serve targeted ads on-platform (Echo devices) as well as off-platform (web). Smart speaker interaction leads to as much as 30X higher ad bids from advertisers. Finally, we find that Amazon's and skills' operational practices are often not clearly disclosed in their privacy policies.

幾個比較重要的資訊,其中一個是「Network traffic distribution by persona, domain name, purpose, and organization」:

另外一個重點是哪些 3rd-party:

就心裡有個底,然後隔壁棚也有類似產品 (主業是做廣告的那家),大概要跑不掉...

Kagi 的搜尋引擎開放註冊,以及公佈付費方案

先前提過 Kagi 這個搜尋引擎 (「來測試 Kagi 這個搜尋引擎」與「用兩個禮拜 Kagi 的心得」),剛剛翻信箱時看到他們的信件,看起來現在任何人都可以註冊了:

If by any chance you do not have a Kagi account yet, you can make one at https://kagi.com/signup?invite_code=humaneweb (feel free to share with your friends)

另外有提到目前規劃的收費計畫是 US$10/mo:

Kagi will come as a free version with limited use; and an unlimited use, paid option at $10 a month, both versions having great search results with less spam and completely ad-free, tracking free, and with none of your search data being retained.

Kagi 已經是我目前預設的 search engine,而且品質其實相當滿意 (偶而會切到 DuckDuckGo 以及 Google 比較),之後就等付費機制上線...

實做 RSS/Atom feed 的最佳實踐

前陣子看到的文章,在講實做 RSS/Atom feed 的 best practice:「RSS Feed Best Practises」。

最簡單的當然還是丟個 Atom feed 就好,接下來就是一些延伸出來可以多做的事情。

首先有提到 discovery,可以讓 crawler 在抓到 HTML 頁面的時候知道 feed 在哪裡,這對於 user experience 來說蠻重要的,大多數的 feed reader 都可以透過這個方式抓到真正的 feed 位置。舉個例子來說,我丟 https://blog.gslin.org/ 進 feed reader,可以透過 discovery 的方式告訴 feed reader 我的 feed 位置在 https://blog.gslin.org/feed/

<link rel="alternate" type="application/rss+xml" title="Gea-Suan Lin&#039;s BLOG &raquo; Feed" href="https://blog.gslin.org/feed/" />

另外是常見的 cache 問題,這個設起來不算太難,主要是細節很多 XD

後面提到的 WebSub,以前叫做 PubSubHubbub,是一個在 feed 更新後主動通知讓 crawler 來抓的機制。不做的話也還好,現在的 crawler 現在都還蠻聰明的,會針對更新比較頻繁的 feed 常常去確認,但這樣總是會有一些時間差。

不過裡面好像沒提到 Update Services,這是比較早期的方法,走 XML-RPC,雖然也不知道現在有什麼用途了,大概就是這樣所以沒提...

FreeBSD 的 Amazon EC2 Image 打算自動使用本機空間當作 Swap

Twitter 上看到 Colin Percival 說計畫將 FreeBSD EC2 image (AMI) 自動偵測並使用 ephemeral disk 的空間當作 swap:

就算是使用 EBSgp2 或是 gp3,甚至是其他 VPS,我也很習慣開一點點的 swap 空間來用 (通常是用 file swap 的方式開 512MB,無論記憶體有多大),這算是我自己的 best practice 了,這可以把一些完全沒用到的 daemon 塞進 swap。

不過對於已經把 ephemeral disk 規劃拿來用的人可能會不太開心,需要去改設定...

Cloudflare 推出了讓你買 cache 空間的 Cache Reserve

這幾天 Cloudflare 推出了一大包東西,其中一個是 Cache Reserve:「Introducing Cache Reserve: massively extending Cloudflare’s cache」。

一般的使用情境是依照 LRU 演算法在決定 Cloudflare 的 cache 滿的時候要排除誰:

We do eviction based on an algorithm called “least recently used” or LRU. This means that the least-requested content can be evicted from cache first to make space for more popular content when storage space is full.

Cache Reserve 就是自己買 cache 空間,他的作法是你付 R2 的空間費用:

Cache Reserve is a large, persistent data store that is implemented on top of R2.

這樣就可以完全依照 Cache-Control 這類 HTTP header 內的時間保存了,你就不用擔心會被 purge 掉,首先價錢包括了 R2 的部份:

The Cache Reserve Plan will mimic the low cost of R2. Storage will be $0.015 per GB per month and operations will be $0.36 per million reads, and $4.50 per million writes.

另外還有還沒公告的 Cache Reserve 的部份:

(Cache Reserve pricing page will be out soon)

對於很極致想要拼 hit rate 的使用者來說是個選擇就是了,另外可以想到直播相關的協定 (像是 HLS) 好像可以這樣搞來壓低對 origin server 的壓力?

NVIDIA 開源 Linux GPU Kernel Driver

NVIDIA 宣佈開源 Linux 下的 GPU Kernel Driver:「NVIDIA Releases Open-Source GPU Kernel Modules」。

從一些描述上可以看出來,應該是因為 Datacenter 端的動力推動的,所以這次 open source 的版本中,對 Datacenter GPU 的支援是 production level,但對 GeForce GPU 與 Workstation GPU 的支援直接掛 alpha level:

Which GPUs are supported by Open GPU Kernel Modules?

Open kernel modules support all Ampere and Turing GPUs. Datacenter GPUs are supported for production, and support for GeForce and Workstation GPUs is alpha quality. Please refer to the Datacenter, NVIDIA RTX, and GeForce product tables for more details (Turing and above have compute capability of 7.5 or greater).

然後 user-mode driver 還是 closed source:

Will the source for user-mode drivers such as CUDA be published?

These changes are for the kernel modules; while the user-mode components are untouched. So the user-mode will remain closed source and published with pre-built binaries in the driver and the CUDA toolkit.

nouveau 來說,是可以從 open source driver 裡面挖一些東西出來用,不過能挖到跟 proprietary 同樣效能水準嗎?

Amazon EFS 的 file lock 限制

看到「Amazon EFS now supports a larger number of concurrent file locks」這篇提到:

This Amazon EFS update increases the number of simultaneous file locks an NFS mount can acquire to 65,536 (from 8,192 previously), enabling Amazon EFS to be used for a broader set of applications that heavily leverage file locking (including message broker and distributed analytics applications).

所以 NFS 的部份先前有 8192 個的上限在,現在則是拉 65536 個了。

不過提到 message broker,應該是以前的應用利用 NFS file lock 來做一些事情?

Cloudflare 的 D1 (SQLite as a service)

Hacker News Daily 上看到 Cloudflare 推出了新產品 D1:「Announcing D1: our first SQL database」,在 Hacker News 上對應的討論在「D1: Our SQL database (cloudflare.com)」這邊可以看到。

就如同 Hacker News 上的討論提到的,這篇文章不像一般的 Cloudflare 文章會帶有很多技術上的說明 (尤其是在描述技術產品),這篇算是非常的行銷導向的文章,目前大家只能靠「猜」的去理解:

For a Cloudflare article, this one is surprisingly light on technical details. And for the product where it most matters.

翻了一下這兩個屬名的作者,Rita Kozlov 是 Director of Product at Cloudflare,而 Glen Maddern 是 Systems Engineer at Cloudflare。

目前知道的是,D1 是架構在 SQLite 上面:

D1 is built on SQLite.

然後從範例的程式碼內可以看到,在 JavaScript 裡面的用法是透過 await env.DB.get() 操作:

export default {
  async fetch(request, env, ctx) {
    const { pathname } = new URL(request.url)
    if (pathname === '/num-products') {
      const { result } = await env.DB.get(`SELECT count(*) AS num_products FROM Product;`)
      return new Response(`There are ${result.num_products} products in the D1 database!`)
    }
  }
}

然後從 screenshot 上沒有看到 region,但是 class 那邊出現了一個 tokyo3 不知道是什麼東西:

目前看到的就這些,沒提到 replication 機制 (這其實還蠻重要的,某些資料是有法規限制的),另外開發者會很在意的 performance 或是 latency 也沒提到 (所以可以預期應該不會太好?)。

另外在 RDBMS 內很重要的 ACID 特性與分散式系統中 CAP theorem 的性質也都沒有分析。

可以先放著看看就好...

關於阻擋 cookie consent window (會問你同意 cookie 的視窗)

看到「It’s time we fix the unethical design of cookie consent windows」這篇,我這邊不是要討論那堆 dark pattern 以及對應的法律問題 (像是先前提到的「Google 在歐盟的服務將提供 Reject All Cookies 的按鈕」),而是想要提一下有對應的 filter rule 專門在擋這類東西的。

uBlock Origin 內的列表有個「Annoyances」的清單可以選:

主要就 AdGuard AnnoyancesFanboy’s Annoyance 以及 uBlock filters – Annoyances 這三個,這樣會讓你在使用網路順不少...

用 GitHub Actions 做的監控服務 Upptime

是在 Twitter 上看到這個:

然後翻到 Upptime 這個 open source monitoring 工具,直接是用 GitHub Actions 提供的 schedule (cron job) 每五分鐘跑一次。這邊要注意的是,如果是 public repository 的話不受限制,如果是 private repository 的話會有機會把 quota 吃完:

Billing note: Upptime uses thousands of build minutes every month (approximately 3,000 minutes in the default setting). If you use a public repository, GitHub offers unlimited free build minutes, but if you use a private repository, you'll have to pay for this time.

依照說明是用 GitHub Actions、GitHub IssuesGitHub Pages 三個功能在運作:

  • GitHub Actions is used as an uptime monitor
  • GitHub Issues are used for incident reports
  • GitHub Pages are used for the status website

除了用這三個功能外,另外還是會每天塞一些資料回 git history 裡面:

We also record the response time once per day and commit it to git history. This way, we can graph long-term trends in your websites' response times by going through git commit history. We generate these graphs once every day, also using schedulers.

好像可以玩看看...