user – Gea-Suan Lin's BLOG

Slack 要拿使用者資料訓練 AI

在「Slack AI Training with Customer Data (slack.com)」這邊看到的，原公告在「Privacy Principles: Search, Learning and Artificial Intelligence」這邊。

預設會被丟進去訓練，Opt-out 無法直接設定，需要透過 e-mail 寫信找 feedback@slack.com (yeah，dark pattern)：

Contact us to opt out. If you want to exclude your Customer Data from Slack global models, you can opt out. To opt out, please have your Org or Workspace Owners or Primary Owner contact our Customer Experience team at feedback@slack.com with your Workspace/Org URL and the subject line “Slack Global model opt-out request.” We will process your request and respond once the opt out has been completed.

拿企業資料來搞事嗎... 這應該已經不只是 privacy 議題而是 security 層面了，PR 層面鐵定很難看，來看後面會不會轉彎？

更激進的考慮使用者會混淆的問題

前陣子寫的「UUID 的 UX」考慮到了人眼會把 0Oo 以及 1IiLl 看錯的問題，這篇則是更激進的想辦法去避免類似的問題：「Understanding and avoiding visually ambiguous characters in IDs」，對應的討論可以在「Understanding and avoiding visually ambiguous characters in IDs (gajus.com)」這邊看到。

作者有提到，這是用在人類需要寫下或是溝通時，避免錯誤的發生：

Any time that the ID might need to be communicated verbally or written down[.]

這就不只是前面提到的 0Oo 與 1IiLl 問題了，包括看起來有機會誤會的字，像是 2Z 以及 8B 這種也要避開。

如果是大小寫都放進去的話是 53 個字可以用，但如果希望大小寫意思一樣的話就只剩下 22 個字可以用了：

Assuming that you are going with case sensitivity, you have 53 characters to choose from (adjusted for visually ambiguous characters). On the other hand, if you decide to make your IDs case-insensitive, you have only 22 characters to choose from.

他給出了這 22 個字：

[
  "a",
  "b",
  "c",
  "d",
  "e",
  "f",
  "h",
  "i",
  "j",
  "k",
  "m",
  "n",
  "o",
  "p",
  "r",
  "s",
  "t",
  "w",
  "x",
  "y",
  "3",
  "4"
]

後續還提到 rn 與 m，以及 vv 與 w 的相似問題，不過這邊的 generator 就更難搞了...

搞到這樣，乾脆用數字就好？使用者的 UX 也比較好？

UUID 的 UX

在「The UX of UUIDs (unkey.dev)」這邊看到的紋章，原文在「The UX of UUIDs」。

裡面有不少是有幫助的建議，像是第一個建議是把 UUID 裡面的 - 拿掉，這樣對於 copy 比較方便 (畢竟大多數人應該是 copy UUID，不會是念出來？)。

第二個建議是加上 prefix，這點不一定侷限在 UUID，只要是 token 上面都很適合。這個在不少系統上應該都有看過，像是 GitHub 的 token，或是 AWS 的 token 都算是這類。

文章裡面沒有提到，但這個建議也可以幫助你在 CI 上設定 regex，擋下把 secret token 寫進去的行為。

第三個提到用 base58，一方面是減少長度，另外一方面是想要避免 1IiLl 與 0Oo 的問題，這點我覺得還好... 既然都是 copy & paste 了，我覺得拿 base62 (i.e. 大小寫加上數字) 不錯，這避免特殊字元無法選擇到，也就是文章裡面第一個建議。

第四個建議是建議重新思考 range，因為 UUID 的 128-bit range 很大，但不是所有應用都需要用到這麼大的範圍確保 collision-free (於是可以當 primary key)。

這點讓我想到 X (Twitter) 當初發表的 Snowflake ID，在 Twitter 這種規模下 64-bit range 也已經夠用。

後面的文章內容就是在推銷自家東西，我就... 跳過了。

uBlock Origin 1.48.0 的改善

Hacker News 上看到「uBlock Origin 1.48 adds readiness status, code viewer, and other fixes (github.com/gorhill)」這則消息，uBlock Origin 在 1.48 有個蠻重要的 UI/UX 改善 (Readiness status at browser launch)。

uBlock Origin 預設會搭配「工人智慧」維護的列表，這些列表通常都不小，在剛開瀏覽器，還在讀取的過程中去看網站會遇到阻擋不完整的情況。

先前沒有辦法知道這個問題，在這版加上了對應的 icon color 來解決，黃色表示還在讀：

這時候跑去逛網站的話會出現驚嘆號：

讀取完後 icon 會變成標準的紅色，但驚嘆號仍然會留著，表示這個頁面未必有完整過濾：

正常有阻擋的則是這樣：

理論上可以減少 bug report XDDD

To reduce the number of reports caused by this issue which is outside of uBO's control, uBO's toolbar icon will now reflect its readiness status at browser launch.

Mac 會自己改變 Desktop 位置的問題

以前好像沒遇過，換了 M1 以後才注意到 desktop 位置位自己被改變，覺得很阿雜... 找了資料才發現是個 "feature"：「How to prevent Mac from changing the order of Desktops/Spaces」。

關掉就好了，網路上的資料最早出現在 2018 年左右，大概是那個時候被加進去的？

Banner blindness

前幾天的 Hacker News Daily 上看到「Why do people not notice our enormous, prominent, clear and contrasting purple banner?」這篇 2018 年的討論，裡面在講為什麼使用者會常態性忽略 banner 的內容。

在答覆區裡面有人提到了維基百科上面的 Banner blindness 這個條目，題到了網站的使用者會刻意或是非刻意的忽略掉像 banner 的資訊：

Banner blindness is a phenomenon in web usability where visitors to a website consciously or unconsciously ignore banner-like information. A broader term covering all forms of advertising is ad blindness, and the mass of banners that people ignore is called banner noise.

開頭也提到了 banner 廣告 CTR 的變化：

The first banner ad appeared in 1994. The average click-through rate (CTR) dropped from 2% in 1995 to 0.5% in 1998. After a relatively stable period with a 0.6% click-through rate in 2003, CTR rebounded to 1% by 2013.

所以這個現象有個專有名詞來形容...

如果把 OpenSSL 包裝成 GUI 版本

在 Hacker News Daily 上看到這則，蠻有趣的嘗試，如果幫 OpenSSL 包裝成 GUI 版本的話，可能會長的樣子：「If OpenSSL were a GUI」，而 Hacker News 上對應的討論在「If OpenSSL were a GUI (smallstep.com)」這邊可以看到。

要注意的是這是 mock 出來的圖，而不是真的有人這樣幹了一個版本出來。主要是在帶出 OpenSSL 這個工具極度複雜的問題，另外也因此帶出 GUI application 的取捨問題，在 Hacker News 上的討論都有人提出來。

不過讓我吸引的點反而是 mock UI 的選擇上，看起來作者選了 Platinum 風格 (Mac OS 8 & Mac OS 9)，在維基百科的「Appearance Manager」這個頁面有提到：

The default look and feel of the Appearance Manager in Mac OS 8 and 9 is Platinum design language, which was intended to be the primary GUI for Copland.

是個讓人懷念的風格，而且意外的看起來反而讓 GUI 柔和不少，而且其實就功能性來說還蠻不錯的？