jq 的開發狀況

Hacker News 上看到「Jaq – A jq clone focused on correctness, speed, and simplicity (github.com/01mf02)」這篇的時候,倒不是 jaq 本身如何,而是在 id=38465712 裡面提到了 jq 的發展停滯了五年左右,但最近又恢復了:

Well, taking into account that jq development has been halted for 5 years and only recently revived again, it's no wonder that bug reports have been sitting there for that time, both well known and new ones. I bet they'll get up to speed and slowly but surely clear the backlog that has built up all this time.

然後下面有提到 https://github.com/jqlang/jq/issues/2305#issuecomment-1572634869 這個,今年六月的時候開始重整團隊改善 bus factor,加入更多新的 maintainer 進來。

算是個好消息,朝向 community 的方式來發展...

GitHub 的 2FA 新計畫

GitHub 決定擴大強制使用 2FA 的範圍:「Raising the bar for software security: next steps for GitHub.com 2FA」。

本來的 2FA policy 是在「Software security starts with the developer: Securing developer accounts with 2FA」這邊提到的,所有的使用者預定在 2023 年年底強制使用 2FA:

GitHub will require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.

另外針對 npm 熱門套件的維護者,則是在三月 (top 100) 與五月 (top 500) 就強制要使用了:

In February we enrolled all maintainers of the top-100 packages on the npm registry in mandatory 2FA, and in March we enrolled all npm accounts in enhanced login verification. On May 31, we will be enrolling all maintainers of the top-500 packages in mandatory 2FA.

但到 2023 年年底才有動作會有點久,所以這次宣佈在 2023 年三月會插入一個新階段,強制這些人要有 2FA 才能進行變更類的操作:

  • Users who published GitHub or OAuth apps or packages
  • Users who created a release
  • Users who are Enterprise and Organization administrators
  • Users who contributed code to repositories deemed critical by npm, OpenSSF, PyPI, or RubyGems
  • Users who contributed code to the approximate top four million public and private repositories

以 developer 為主的 GitHub 大力在推 2FA,其他的服務不知道之後會不會有類似動作...

GitHub 將在 2023 年底強制所有使用者都啟用 2FA

GitHub 公佈了強制使用 2FA 的計畫:「Software security starts with the developer: Securing developer accounts with 2FA」。

文章副標題把該講的都講完了:

GitHub will require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.

自己開是一件事情,整個服務強制啟用是另外一個等級,還有一年多的時間...

Twitter 的 MFA 可以加入多支 YubiKey 了

我手上有好幾隻 YubiKey,目前幾個有在用的服務都有支援同時綁定多組 U2F/WebAuthn 的能力 (像是 FacebookGitHub)。

Twitter 一開始推出的時候也可以支援多組,但在去年 2020 年八月的時候發現這個功能被拔掉,只能放一把進去。

我自己開了一張 ticket 定時回頭看一下有沒有修正,剛剛定期回顧發現這個功能被加回來了,而且官方的文件上也加上去了:「How to use two-factor authentication」。

翻了一下 Internet Archive 上的資料,看起來是 3/113/16 中間更新文件的...

手上有多把 security key 的人也可以處理一下。

RSA-240 (十進位 240 位數) 成功分解

在「RSA-240 Factored」這邊看到的,RSA-240 前幾天被解開了:

RSA-240 = 124620366781718784065835044608106590434820374651678805754818788883289666801188210855036039570272508747509864768438458621054865537970253930571891217684318286362846948405301614416430468066875699415246993185704183030512549594371372159029236099 = 509435952285839914555051023580843714132648382024111473186660296521821206469746700620316443478873837606252372049619334517 * 244624208838318150567813139024002896653802092578931401452041221336558477095178155258218897735030590669041302045908071447

有效長度是 795 bits,相較於十年前解出來的 RSA-768 (768 bits) 又多了「一些」。看了一下,算法上沒有太多突破,主要是硬體的發展與軟體的最佳化有進展...

移除 Facebook 上的行動電話

Facebook 上的行動電話號碼除了被拿來當作 2FA 的備案外,也被強制分享。更糟的是還被拿來當作廣告的條件:

目前同時有 TOTP (Facebook 的 app 提供的) 與 U2F,完全不會用到簡訊認證,就拔掉吧...

CA/Browser Forum 上的會議記錄:關於密碼與 2FA 的強制要求

CA/Browser Forum 會定時將會議記錄與最後的結論公開放在網站上,有時候有些資訊還蠻有趣的。像是前幾天在「Ballot 221 - Two-Factor Authentication and Password Improvements - CAB Forum」這邊看到 CA/Browser Forum 的成員對密碼與 2FA 提出了修正提案,其中瀏覽器端只有 Microsoft 參與投票,但是被否決了...

不知道否決的原因,但是大概可以猜到幾個點。

第一個是提案提到了 NSANIST 800-63B Appendix A,這個單位不太受歡迎啊...

第二個則是「For accounts that are accessible only within Secure Zones or High Security Zones, require that passwords have at least twelve (12) characters;」這段強迫使用密碼,而現在有比密碼更安全的方案存在 (以 public key cryptography 為認證基礎的方案),像是早期的 U2F 以及今年定案的 WebAuthn

應該是這些原因吧...

Amazon 的多變數最佳化

在「An efficient bandit algorithm for real-time multivariate optimization」這邊提到了 Amazon 不是走傳統的 A/B testing,而是同時進行多變數的最佳化:

Consider the problem of trying to find a near-optimal version of a promotional message such as this one, which has 5 variable parts and 48 different combinations in total.

在這樣的測試數量下,作者預估需要 66 天才能夠得到有效的結果,而這也表示當變數更多的時候問題就更大了:

Based on the Amazon success rate and traffic size, the authors calculated it would take 66 days to conduct a 48 treatment randomized experiment. Often this isn’t practical.

也就是開頭提到的,如何一個禮拜就提昇 21% conversion rate:

Aka, “How Amazon improved conversion by 21% in a single week!”

作者也提到了這個方法其實打臉了他先前提到的另外一篇論文,在 2014 年提出測試應該要盡可能簡單 XDDD:

Yesterday we saw the hard-won wisdom on display in ‘seven myths‘ recommending that experiments be kept simple and only test one thing at a time, otherwise interpreting the results can get really complicated.

只能說狀況愈來愈複雜,導致需要新方法解決問題。而且這些電商會遇到在測試時不同的 factor 之間有可能會有相依性 (也就是說這些 factor 不是 i.i.d.),你用本來的方式反而會測不出來。