Stripe 原來支援 JCB 了啊...

剛剛在買東西的時候故意丟 JCB 的卡號進去,發現 Stripe 認得,找了一下公告資料,發現是去年 2020 年五月支援的:「Expanding support for JCB payments」。

先前在日本買 Live 物販的時候 (2019 年年底,應該是 H-el-icalSee-Saw 這兩場),看到現場是使用 iPad + Stripe 的組合,一開始還驚訝了一下,但被告知不支援 JCB 的時候心裡「...」了一陣子,只能刷 Mastercard 或是 Visa


Businesses using Stripe in Japan can now automatically accept payments with JCB, in most cases without any additional work.


We are rolling out JCB acceptance to businesses in more countries, starting with Canada, Australia, and New Zealand, with more to come. This lets global businesses, from e-commerce sites in Canada to subscription services in Australia, easily transact with JCB cardholders.

如果 2022 年有機會去日本的話,應該會看到更多使用 Stripe 的方案了...

Visa 網站上面的 Opt-Out 功能被拿來玩 Timing Attack...

Hacker News Daily 上看到「Visa Advertising Solutions (VAS) Opt Out (」這篇講 Visa 的 Visa Advertising Solutions (VAS) Opt Out,本來以為是在討論企業賣資料的問題 (下面的討論的確是有在討論這個),但最上面的討論居然是在討論 timing attack,像是這篇:

morpheuskafka 2 days ago [–]

Checked and the Mastercard one someone posted below doesn't seem to be vulnerable to this. My real card number and a dummy mastercard number with valid prefix and check digit both returned a 200 OK in around 1.01s. A random 16digit number without valid check digit returned 400 Bad Request in about 800ms. Decided to check that one since they have a completely useless machine-readable catchpa.

For Visa it was 835ms for valid, 762ms for dummy, prefix and check digit appears to be checked client side.

我印象中這類方式已經發展很久了 (透過網路反應時間的 timing attack),討論裡面有提到「Exploiting remote timing attacks」這篇,也是十多年前的資料了... 不過官方網站玩起來總是有中特別爽的感覺 XDDD

不過 Visa 的這個網站前面用了 Cloudflare,用機器人掃感覺很容易被擋,這又是另外一回事了...

在 Hacker News 上看到 Raspberry Pi 400 使用心得

Hacker News 看到 Raspberry Pi 400 的使用心得:「I've now played with a Raspberry Pi 400 for a week and here are my conclusions」,先前在「Raspberry Pi 400」這邊有提到 Raspberry Pi 400,主要就是一台 Raspberry Pi 4 Model B 的主機,但跟鍵盤整合在一起。

在文章裡提到了 Raspberry Pi 4 可以 USB Boot 後帶來的改變 (參考之前寫的「Raspberry Pi 4 可以透過 USB 開機了」這篇),主要是透過 USB3 外接硬碟可以讓讀寫速度大幅提昇 (尤其是 SSD),這一直都是 Raspberry Pi 上面用 SD card 的問題,看起來唯一的問題還是 CPU 的速度還是沒有像目前常見的 x86-64 強。

If you give it fast enough "disk" storage it really moves. I plugged in a Kingston brand 120GB SSD on a USB3 adapter. hdparm -t gave 292MB/s read speed and the default LXDE environment was really crisply responsive, with even a first launch of Chromium taking less than two seconds. With such good storage, the only real limitation is that heavy Javascript stuff is too slow - 5+ seconds to switch between folders in Chrome, or for the thumbnail gallery to appear in Youtube. Also, video calling is marginal. Aside from that the CPU is fast enough.

另外討論裡面也有人希望 Raspberry Pi 考慮引入 eMMC 或是提供 M.2 界面改善讀寫速度,不過我覺得 SD card 的設計算是 Raspberry Pi 當初的方向,本來就有取捨,不太可能什麼都做進去...

回到作者的心得,雖然 USB3 轉 SSD 看起來 i/o 速度快不少,但我好像主要不是遇到 i/o 速度問題,反倒是最近 chromium 的硬體解碼好像有些進度,也許看影片有機會用硬體處理 (至少一部份?),希望至少可以輕鬆看 1080p60 啊...

四個 HDMI 的顯示卡

Facebook 上正妹 wens 問是不是用華碩的 GT710-4H-SL-2GD5 這張顯示卡:「The Most Innovative ~$50 Graphics Card For Linux Users」,看了一下是一張蠻有趣的顯示卡,而且價位還蠻有競爭力的,拉一篇出來記錄好了...

我自己是用四螢幕,先前一直都是用 1080 Ti 在接 (2 HDMI + 2 DP),但覺得好像太吃電,後來在網路上弄了一張有四個 miniDP 輸出的 Quadro P600 顯示卡,另外又找了四條 miniDP 轉 DP 的線。

換上去後發現有時候不是那麼順,後來發現是因為常常開一堆 Twitch 反而吃了不少 GPU 資源 (在 Linux 下可以用 nvidia-smi 觀察),而且有時候還是希望跑個 KataGo 分析圍棋棋局,所以還是需要 GPU 計算能力,就換回用 1080 Ti 了...

不過這張 GT710 是四個 HDMI,用一般的 HDMI 線就可以了,相較於 P600 提供的 miniDP 需要 miniDP 轉 DP 的線,取得上應該容易不少:

另外他只需要 PCI Express 2.0 (x1) 而且是被動散熱,手上的 P600 得用到 PCI Express 3.0 (x16) 而且上面還是有一顆風扇,我猜 GT710 這張應該是更省電?不過官網上沒寫 GT710 這張的功耗,不過在「GeForce 700 series」這邊是寫 19W,而 P600 的最大功耗是 40W。

目前有看到的缺點應該是多顆 4K 解析度下時的更新頻率只有 30Hz:

* Detailed digital max. resolution:
3840×2160@60Hz for 1 monitor
3840×2160@30Hz for more than 2 monitors

對於想要有多螢幕輸出的人可以考慮看看,目前查到的價位上在新台幣 2000 上下,比 Quadro 便宜不少,畢竟定位還是不太一樣...

把 SSH Key 放進 Secure Enclave 裡保護

看到 Secretive 這個專案,是利用蘋果的 Secure Enclave 機制,把 SSH private key 放進去在裡面進行運算,避免 private key 檔案被惡意程式讀取就洩漏出去了。

從 Secure Enclave 的介紹頁面可以看到這個需要有 T1 或是 T2 晶片才有 Secure Enclave 功能:

Mac computers that contain the T1 chip or the Apple T2 Security Chip

而從 Apple Silicon 這邊可以看到 Apple T1 chip 是 2016 年後的機種引入的:

The Apple T1 chip is an ARMv7 SoC (derived from the processor in S2 SiP) from Apple driving the System Management Controller (SMC) and Touch ID sensor of the 2016 and 2017 MacBook Pro with Touch Bar.

然後對於沒有 Secure Enclave 的古董機,可以透過有支援 smart card 的硬體掛上去,像是 YubiKey

For Macs without Secure Enclaves, you can configure a Smart Card (such as a YubiKey) and use it for signing as well.

照著他講的建議去翻了「YubiKey Smart Card Deployment Guide」這邊的資料,看起來 YubiKey 在 4 系列之後就有產品支援 Smart Card 了,不過要注意純 U2F 的版本沒支援。

Mastercard 對實體物品提供免費試用後的訂閱條款

Mastercard 規定在免費試用後 (實體物品),需要另外再讓使用者再同意一次才能開始收訂閱費用:「Free Trials Without The Hassle」。

The rule change will require merchants to gain cardholder approval at the conclusion of the trial before they start billing. To help cardholders with that decision, merchants will be required to send the cardholder – either by email or text – the transaction amount, payment date, merchant name along with explicit instructions on how to cancel a trial.

新聞一開始出來時其實讓蠻多人關注的,因為一堆網路服務都是靠這招... 所以 Mastercard 在文章後更新說明,目前只有實體物品套用這個規則:

*This blog was updated on January 17, 2019 to clarify that the rule change is applicable to physical products such as skincare, healthcare items etc.


看到「The curious case of the Raspberry Pi in the network closet」這篇有趣的過程,先從開頭與最後面開始看。首先是他們在辦公室裡面發現有個奇怪的設備:


I checked the DNS logs and found the exact date and time when the Pi was first seen in the network. I checked the RADIUS logs to see which employee was at the premises at that time and I saw multiple error messages that a deactivated account tried to connect to wifi.

That deactivated account belongs to an ex employee who (for some reason) made a deal with management that he could still have a key for a few months until he moved all his stuff out of the building (don't ask..).

中間的過程還蠻有趣的,包括研究是什麼擴充卡 (以及用途),然後從 SD card 上面挖資料,配合 Google 找線索,還有透過 WiGLE 定位,以及透過內部系統交叉比對,最後找到兇手...

然後發現是離職員工以搬東西當作理由,讓他在離職後還有辦公室鑰匙而導致的 XDDD

就算關掉 Google 的定位服務也還是會蒐集位置資訊...

就如標題所寫的,Quartz 獨家刊出來的新聞,即使你關掉 Google 的定位服務,Google 還是會蒐集你的位置 (而且跟 Google 發言人確認後也證實):「Google collects Android users’ locations even when location services are disabled」。

而且是全背景作業,在你沒有開定位服務,沒有插 SIM 卡,也沒有跑任何 app,他就會將定位資訊傳出去:

Many people realize that smartphones track their locations. But what if you actively turn off location services, haven’t used any apps, and haven’t even inserted a carrier SIM card?

從今年年初開始這樣搞的,Google 發言人只宣稱這個資料並沒有被用來整合到「network sync system」,並且會立即丟掉 (所以你還是不知道被用到什麼地方):

“In January of this year, we began looking into using Cell ID codes as an additional signal to further improve the speed and performance of message delivery,” the Google spokesperson said in an email. “However, we never incorporated Cell ID into our network sync system, so that data was immediately discarded, and we updated it to no longer request Cell ID.”

這句話的意思其實代表著是丟掉 raw data,改以統計的方式轉移存到其他系統。

另外 John Gruber 在「Google Collects Android Users' Locations Even When Location Services Are Disabled」其實寫的更直接:

If they were “never used or stored”, why did they start collecting them in the first place? This is like a kid caught with their hand in the cookie jar saying they weren’t going to eat any cookies. Sure.


應該會促進 microG 的發展... (參考「microG 的進展...」)

各家 Session Replay 服務對個資的處理

Session Replay 指的是重播將使用者的行為錄下來重播,市面上有很多這樣的服務,像是 User Replay 或是 SessionCam

這篇文章就是在討論這些服務在處理個資時的方式,像是信用卡卡號的內容,或是密碼的內容,這些不應該被記錄下來的資料是怎麼被處理的:「No boundaries: Exfiltration of personal data by session-replay scripts」,主要的重點在這張圖:

後面有提到目前防禦的情況,看起來目前用 adblock 類的軟體可以擋掉一些服務,但不是全部的都在列表裡。而 DNT 則是裝飾品沒人鳥過:

Two commonly used ad-blocking lists EasyList and EasyPrivacy do not block FullStory, Smartlook, or UserReplay scripts. EasyPrivacy has filter rules that block Yandex, Hotjar, ClickTale and SessionCam.

At least one of the five companies we studied (UserReplay) allows publishers to disable data collection from users who have Do Not Track (DNT) set in their browsers. We scanned the configuration settings of the Alexa top 1 million publishers using UserReplay on their homepages, and found that none of them chose to honor the DNT signal.

Improving user experience is a critical task for publishers. However it shouldn’t come at the expense of user privacy.

下一個版本的 Chrome (56) 將會對要求卡號或是密碼的 HTTP 站台標示「Not Secure」

如同之前在「Google Chrome 56 將會對 HTTP 網站標示「Not secure」」提到的規劃,Google Chrome 56 (也就是下一個版本) 將會對要求卡號或是密碼的站台標示「Not Secure」:「Chrome 56 Beta: “Not Secure” warning, Web Bluetooth, and CSS position: sticky」。

比較九月的 screenshot 與最近的 screenshot,從「Not secure」變成「Not Secure」了... 這是九月的: