密碼輸入上的 UX

Hacker News 上看到「Gmail password first character is case insensitive on mobile device (support.google.com)」這篇,在講密碼輸入上的 UX。

在 Hacker News 上的討論看到這則:

This is a well-understood feature. Facebook does the same thing[0].

Quote:

Facebook actually accepts three forms of your password:

* Your original password.

* Your original password with the first letter capitalized. This is only for mobile devices, which sometimes capitalize the first character of a word.

* Your original password with the case reversed, for those with a caps lock key on.

[0]: https://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

接受三種密碼,第一種是完全正確的密碼,第二種是第一個字如果是大寫時的密碼 (在行動裝置上可能的行為),第三種是大小寫全部相反的密碼,這在沒注意到 caps lock 時會發生。

強度不會削弱太多,但對於 user experience 好很多的設計。

Facebook 把自家的 MySQL 升級到 8.0

Facebook Engineering 發了一篇將 MySQL 升級到 8.0 的說明:「Migrating Facebook to MySQL 8.0」。

先前的版本主要是 5.6,加上 MyRocks

Our last major version upgrade, to MySQL 5.6, took more than a year to roll out. When version 5.7 was released, we were still in the midst of developing our LSM-Tree storage engine, MyRocks, on version 5.6. Since upgrading to 5.7 while simultaneously building a new storage engine would have significantly slowed the progress on MyRocks, we opted to stay with 5.6 until MyRocks was complete. MySQL 8.0 was announced as we were finishing the rollout of MyRocks to our user database (UDB) service tier.

GitHub 上是有 facebook/mysql-8.0,但看起來從 2017 後就沒更新了,所以應該是沒有 open source 出來。

看看就好 XD

Facebook 5.33 億筆個資外洩,以及 Mark Zuckerberg 的電話...

這兩天應該已經有很多其他媒體報導了 Facebook 5.33 億筆資料外洩的事情:「533 million Facebook users' phone numbers and personal data have been leaked online」。

據稱是用 2019 年的洞撈出來的,不過這份資料看起來也不是完整資料,舉個例子來說,台灣只有 73 萬筆左右,而且也少了很多地區,像是泰國就不在列表內...

另外一個比較特別的是,Mark Zuckerberg 的電話也在這次外洩資料裡面:「Mark Zuckerberg's phone number appeared among the leaked data of Facebook users, according to a researcher」,應該會換號碼了。

這包資料看起來會這陣子會很熱門...

印度威脅要逮捕 Facebook、WhatsApp 與 Twitter 的員工

The Wall Street Journal 上看到的,印度政府威脅 FacebookWhatsAppTwitter,如果不配合政府的要求提供資料並將內容下架,將會逮捕他們在印度的員工:「India Threatens Jail for Facebook, WhatsApp and Twitter Employees」。

這應該是透過上個月才剛過的法令:「Facebook, WhatsApp and Twitter Face New Rules in India」。

印度的市場太大,各家社群網站都想要進去,造就了政府的有足夠的能力跟這些大公司談判,而且是具有壓制性的力量。

在去年殺完 Tiktok 後,上個月擴權然後這個月反過來殺這些美國的企業。

美國政府不知道會幫到什麼程度...

Facebook 放出 Pysa,靜態分析 Python 程式碼的工具

Facebook 丟出來的靜態分析工具,可以拿來分析 Python 程式碼:「Pysa: An open source static analysis tool to detect and prevent security issues in Python code」,專案在「facebook/pyre-check」這邊可以取得。

不過軟體居然是用 OCaml 寫的啊,另外已經包好了,可以用 pip 直接裝 pyre-check

官方的說明裡面有提到要裝 watchman,不過這算是選擇性安裝,不裝 watchman 直接執行也可以用,只是會跳個訊息跟你說裝了可以遞增檢查:

To enable pyre incremental, you can install watchman: https://facebook.github.io/watchman/docs/install

最近在寫的專案都是用 Python,剛好可以拿來掃這些專案...

Facebook 提供 Public NTP Service

在「Building a more accurate time service at Facebook scale」這邊 Facebook 講了不少跟 NTP 有關的東西,不過重點在他們提供 Public NTP service:

Having five independent geographically distributed endpoints helps us provide better service — even in the event of a network path failure. So we provide five endpoints:

  • time1.facebook.com
  • time2.facebook.com
  • time3.facebook.com
  • time4.facebook.com
  • time5.facebook.com

Each of these endpoints terminates in a different geographic location, which has a positive effect on both reliability and time precision.

看起來是混了 anycast 進去,從台灣 (HiNet) 走的話,time1.facebook.com 會到東京,time2.facebook.com 到大阪 (難得在 traceroute 上看到 ITM 這個代碼,代表 伊丹機場),time3.facebook.com 則是台灣,time4.facebook.com 到香港,time5.facebook.com 好像是馬來西亞?看 latency 與 maa 這個詞... (Update:應該是清奈國際機場)

可以考慮看看,另外 Google Public NTP 也是個選項。

Facebook 修正錯字的新演算法

先前 Facebook 已經先發表過 fastText 了,在這個月的月初又發表了另外一個演算法 Misspelling Oblivious Embeddings (MOE),是搭著本來的 fastText 而得到的改善:「A new model for word embeddings that are resilient to misspellings」。

Facebook 的說明提到在 user-generated text 的內容上,MOE 的效果比 fastText 好:

We checked the effectiveness of this approach considering different intrinsic and extrinsic tasks, and found that MOE outperforms fastText for user-generated text.

論文發表在 arXiv 上:「Misspelling Oblivious Word Embeddings」。

依照介紹,fastText 的重點在於 semantic loss,而 MOE 則多了 spell correction loss:

The loss function of fastText aims to more closely embed words that occur in the same context. We call this semantic loss. In addition to the semantic loss, MOE also considers an additional supervisedloss that we call spell correction loss. The spell correction loss aims to embed misspellings close to their correct versions by minimizing the weighted sum of semantic loss and spell correction loss.

不過目前 GitHub 上的 facebookresearch/moe 只有放 dataset,沒有 open source 出來讓人直接用,可能得自己刻...

Cloudflare 提供 Certificate Transparency 的通知服務

Cloudflare 推出了 Certificate Transparency 的通知服務,當有任何新的 SSL certificate 發出時就會通知:「Introducing Certificate Transparency Monitoring」。

基本上就是一組 crawler 去各家記錄挖資料回來:

Business 與 Enterprise 版本的可以設定要通知誰,Free 與 Pro 版本則是固定會通知網域的擁有人 (這邊指的是 Cloudflare 上的):

If you’re on a Business or Enterprise plan, you can tell us who to notify. Instead of emailing the zone owner (which we do for Free and Pro customers), we accept up to 10 email addresses as alert recipients. We do this to avoid overwhelming large teams.

剛剛把掛在上面的 domain 都開起來了,這樣在 Let's Encrypt 自動 renew 的時候應該會收到通知...

另外一個同名的工具則是 2016 年底時 Facebook 推出的 (需要登入才能使用),可以搜尋有哪些 domain:「Certificate Transparency Monitoring」。

Facebook 推出了 Hermes,為了 React Native 而生的 JS Engine

Facebook 提供了一個對 React Native 最佳化的 JS engine:「Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native」。

裡面有提到兩個比較重要的的部份是 No JIT 與 Garbage collector strategy,針對行動裝置的特性而設計:避免 JIT 產生的 overhead,以及降低記憶體使用量。

官方給的改善主要也都是偏這兩塊:

不過沒有提到 CPU usage 會上升多少,只是帶過去:

Notably, our primary metrics are relatively insensitive to the engine’s CPU usage when executing JavaScript code.

對於 Facebook 也許是可以接受的數量,但對於其他人就沒概念了... 要入坑的人自己衡量這部份的風險 XD