蒐集 Hacker News 上被不合理條件「消失」的連結

在「Stories removed from the Hacker News Front Page, updated in real time (github.com/vitoplantamura)」這邊看到的計畫,專案在 GitHub 上面:「vitoplantamura/HackerNewsRemovals」。

蒐集的條件是假設如果本來在第一頁上面 (top 30),不應該下一分鐘就調出 top 90:

The assumption is that a Story cannot go from the top 30 to a position higher than 90 in a single minute, without having been explicitly removed.

dangid=39231821 有解釋有些情況是會直接被 downrank 出去的:

The first two you listed were downranked by the flamewar detector. The last one was downranked by users. Admins didn't touch any of them.

其實 Hacker News 混久了大家心裡也都有底,這兩個很 buggy 的機制就是要夠 buggy 才能操弄,這點從某些特定主題 (像是 climate change 相關的) 會突然消失,然後被推給這兩個系統...

所以 Hacker News 被說黑箱也不是一天兩天了,隔壁 Lobsters 至少有 Moderation Log 可以看...

現在這樣可以撈出其他有用的連結來看了,另外應該也可以讓他變成類似 Hacker News Daily 的方法才對,每天整理出來後變成一篇 blog post,這樣可以訂起來看,來提議給作者看看好了?

用 x86 組語寫的 web forum

另外一個在週末看到的奇怪東西,用 x86 組語寫的 web forum:「AsmBB – a lightweight web forum engine written in assembly language (asmbb.org)」,官網在 asmBB 這邊,說明則是在「What is AsmBB?」這頁。

是個 x86 assembly + SQLite 的組合:

AsmBB is fully written in assembly language and uses SQLite as a database back-end. That is why it can work on really weak hosting and in the same time serve huge amount of visitors without lags and delays.

程式碼是用 Fossil 管的,不過作者有 mirror 到 GitHub 上:「johnfound/asmbb」。

SQlite 的部分用了 SQLeet,可以在 sqleet.inc 這個檔案裡面看到引用了 libsqleet.so

AsmBB uses SQLite with SQLeet extension as a back-end storage database and FastCGI interface to the web server.

組語的部分看起來是用 fasm 寫的,看程式碼 (像是 encryption.asm) 可以看到一些好用的語法,像是自動處理 function 參數的部分 (應該有設定某種 convention),跟當年寫 MASM 的用法方便不少:

stdcall TextCreate, sizeof.TText
mov     edx, eax

stdcall TextCat, edx, <"Content-type: text/html; charset=utf-8", 13, 10, 13, 10>
stdcall RenderTemplate, edx, 'crypto.tpl', 0, esi

目前 Reddit 的替代方案

看到「sub.rehab · Find your next diving spot」這個頁面,在整理目前 Reddit 社群的其他出處。

從目前的資料看起來,Lemmy 應該是主要方案,有些可能自架,但蠻多人就是跑去找一個 instance 掛?

第二多的是轉移到 Discord 上,這點蠻特別的...

而因為 Discord 的封閉性,也看到了「Answer Overflow - Index Your Discord Server Channels Into Google」這種服務,可以把 Discord 的內容轉成 html 頁面,讓搜尋引擎可以讀到內容。

所以這波 Reddit 決定來硬的到底會不會成呢...

TLS 憑證的最長時效將從 825 天降到 398 天

在「Reducing TLS Certificate Lifespans to 398 Days」這邊看到才想起來沒寫這篇,這邊發生了一些有趣的事情...

提案是降低 TLS 憑證的有效時效,這件事情一開始是在 CA/B Forum 討論,但經過投票後沒有通過:「Ballot SC22 - Reduce Certificate Lifetimes (v2)」。

從投票記錄可以看到所有的憑證使用方 (包括了許多瀏覽器的廠商) 都贊同,但有大約 2/3 的憑證發行方都反對:

7 votes total including abstentions:

  • 7 Yes votes: Apple, Cisco, Google, Microsoft, Mozilla, Opera, 360
  • 0 No votes:
  • 0 Abstain:

33 votes total including abstentions

  • 11 Yes votes: Amazon, Buypass, Certigna (DHIMYOTIS), certSIGN, Sectigo (former Comodo CA), eMudhra, Kamu SM, Let’s Encrypt, Logius PKIoverheid, SHECA, SSL.com
  • 20 No votes: Camerfirma, Certum (Asseco), CFCA, Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy, Izenpe, Network Solutions, OATI, SECOM, SwissSign, TWCA, TrustCor, SecureTrust (former Trustwave)
  • 2 Abstain: HARICA, TurkTrust

然後幾個比較大的憑證使用方 (AppleGoogleMozilla) 在提案被否決後就決定放到自家的規則了:「Apple strong-arms entire CA industry into one-year certificate lifespans」。

從 2020/09/01 開始,如果發出來的憑證超過 398 天就當作是無效憑證,也就是 2020/08/31 是最後一天可以發有效期限為 825 天的憑證,會落在 2022/12/05 失效:

$ date --date='Sep 1 2020 GMT+0000 +825days'
Mon Dec  5 08:00:00 CST 2022

這三家搞下去,就等於是強制性讓這些 CA 到九月就不能賣兩年的憑證了 (雖然還沒看到 Microsoft),這些 CA 一定是在心裡幹爆... XD

用 CleanTalk 擋論壇的廣告...

看到 Hacker News 上「You probably don’t need ReCAPTCHA (kevv.net)」這篇在討論 reCAPTCHA (原始文章在「You (probably) don’t need ReCAPTCHA」這篇),裡面除了認為 reCAPTCHA harmful 的觀點還 ok 外,其他的觀點我覺得都無法讓人認同...

因為看到 reCAPTCHA 而想到已經用了 CleanTalk 一陣子,效果還不錯,所以寫一篇講一下...

起因是維護「FJC 華語社群」這個站台,這是一個使用 phpBB 架設的站台,為了方便,我透過 RSS + IFTTT,當論壇上有新文章時就會自動貼到 Line 群組上面...

為了避免論壇上面有 spam,我有針對註冊開 reCAPTCHA,但發現還是有不少「全人工註冊」的帳號會貼文,所以就得找更精準的服務來用... 後來在 phpBB 網站上翻到 CleanTalk 這個服務,對於在「CleanTalk Anti-Spam Installation Manuals」這頁看到支援的軟體只要 USD$8/year/site,從一月用到現在超過五個月了,就沒遇到 spam 了...

機制上他會透過 client database 分析他們自己的 spam 資料庫,另外在發文時他也會分析文章內容是不是 spam,所以裝上去之後兩關都有過濾機制...

類似的服務還有 Akismet,不過畢竟是知名品牌,費用相較起來貴不少...

在 Ubuntu 18.04 (Bionic) 上跑 Percona Server 5.7

Percona 的文件「Installing Percona Server on Debian and Ubuntu」這邊雖然還沒列 Ubuntu 18.04 上去,但已經有東西在裡面可以安裝了。不過還是屬於官方未正式支援的情況,用的時候自己要注意。

另外查資料的時候有看到「Ubuntu 18.04 (bionic) - percona-xtradb-cluster-server installation break」這篇提到 Percona XtraDB Cluster 裝不起來,但有 workaround 可以硬裝進去,要玩的人也可以參考一下 XD

這樣可以把 14.04 機器換一換了。(先前清點時本來以為已經是 16.04,做一些操作時才發現是 14.04...)

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

應該是這些原因吧...

SSL Certificate 的認證方式限縮

在「Ballot 218 - Remove validation methods 1 and 5 - CAB Forum」看到「Ballot 218: Remove validation methods #1 and #5」這則議案以 78% 的同意票通過,限縮 SSL Certificate 的認證方式。眼睛瞄到中華電信投下反對票:

14 Yes votes: CFCA, Cisco, Comodo CA, D-TRUST, DigiCert, GDCA, GlobalSign, GoDaddy, Izenpe, Let’s Encrypt, Logius PKIoverheid, SSL.com, TrustCor, Trustwave

4 No votes: Buypass, Chunghwa Telecom, Entrust Datacard, SwissSign

4 Abstain: Actalis, Disig, HARICA, OATI

78% of voting CAs voted in favor

找了一下在 BR (Baseline Requirements) 的 3.2.2.4.1 與 3.2.2.4.5,其中前者是透過註冊商認證:

3.2.2.4.1 Validating the Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar.

後者是透過文件認證:

3.2.2.4.5 Domain Authorization Document

Confirming the Applicant's control over the FQDN by relying upon the attestation to the authority of the Applicant to request a Certificate contained in a Domain Authorization Document.

在想投下反對的原因,會不會是因為中華自己的 domain 應該都是透過後者方式發的?透過內部公文系統...

2017 年 CA/Browser Forum 在台北辦的見面會議的會議記錄出爐了...

2017 年 CA/Browser Forum 在台北舉辦的見面會議,會議記錄總算是出爐了:「2017-10-04 Minutes of Face-to-Face Meeting 42 in Taipei - CAB Forum」。

由於是辦在台北,所以台灣很多單位都有出席,像是中央警察大學 (1)、中華電信 (11)、日盛聯合會計師事務所 (1)、TWCA (3):

Attendance: Peter Bowen (Amazon); Geoff Keating and Curt Spann (Apple); Jeremy Shen (Central Police University); Franck Leroy (Certinomis / Docapost); Wayne Chan and Sing-man Ho (Certizen Limited); Wen-Cheng Wang, Bon-Yeh Lin, Wen-Chun Yang, Jenhao Ou, Wei-Hao Tung, Chiu-Yun Chuang, Chung-Chin Hsiao, Chin-Fu Huang, Li-Chun Chen, Pin-Jung Chiang, and Wen-Hui Tsai (Chunghwa Telecom); Alex Wight and JP Hamilton (Cisco), Robin Alden (Comodo), Gord Beal (CPA Canada), Ben Wilson and Jeremy Rowley (DigiCert), Arno Fiedler and Enrico Entschew (D-TRUST); Kirk Hall (Entrust Datacard); Ou Jingan, Zhang Yongqiang, and Xiu Lei (GDCA); Atsushi Inaba and Giichi Ishii (GlobalSign); Wayne Thayer (GoDaddy); Devon O’Brien (Google); David Hsiu (KPMG); Mike Reilly (Microsoft); Gervase Markham and Aaron Wu (Mozilla); Hoang Trung La (National Electronic Authentication Center (NEAC) of Vietnam); Tadahiko Ito (Secom Trust Systems); Leo Grove and Fotis Loukos (SSL.com); Brian Hsiung (Sunrise CPA Firm); Steve Medin (Symantec); Frank Corday and Tim Hollebeek (Trustwave); Robin Lin, David Chen, and Huang Fu Yen (TWCA); and Don Sheehy and Jeff Ward (WebTrust).

開頭有提到會議記錄 delay 的情況:

Preliminary Note: The CA/Browser Forum was delayed in completing the minutes for its last Face-to-Face meeting Oct. 4-5, 2017 in Taipei, and the proposed final Minutes were only sent by the Chair to the Members on December 13, 2017 for their review. There was not enough time for Members to review the draft before the next teleconference of December 14, and the teleconference of December 28 was cancelled due to the holidays. The next Forum teleconference is scheduled for January 11, 2018.

會議記錄很長,主要是有不少主題被拿到見面會議上討論,另外有一半的篇幅是在說明各家 root program policy 的變化。

下次的見面會議會在三月,然後會由 Amazon 辦在東岸:

Peter confirmed the next F2F meeting will be hosted by Amazon on March 6-8, 2018 at its Herndon, Virginia location. More information will be provided in the coming months.

Google Chrome 對 Symantec 全系列憑證的不信任計畫

Google Chrome 前陣子整理了一份對 Symantec 憑證的不信任計畫:「Chrome’s Plan to Distrust Symantec Certificates」。

這包括了一卡車的品牌,像是 ThawteVeriSignGeoTrustRapidSSL,不過 Equifax 跟 Symantec 的關係我沒查到...:

Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements.

反正整個計畫會在 Google Chrome 70 推出時告一段落 (變成完全不信任),會是 2018/09/13 (預定時間) 與 2018/10/23 (預定時間) 在 beta channel 與 stable channel 上推出。

中間比較重要的時間點是 2018/03/15 (預定時間) 與 2018/04/17 (預定時間),Google Chrome 66 在 beta channel 與 stable channel 上推出,這個版本不會信任 2016/06/01 前發出的憑證:

Chrome 66 released to beta, which will remove trust in Symantec-issued certificates with a not-before date prior to June 1, 2016. As of this date Site Operators must be using either a Symantec-issued TLS server certificate issued on or after June 1, 2016 or a currently valid certificate issued from any other trusted CA as of Chrome 66.
Site Operators that obtained a certificate from Symantec’s old infrastructure after June 1, 2016 are unaffected by Chrome 66 but will need to obtain a new certificate by the Chrome 70 dates described below.

整個計畫的時間軸清楚多了...