用 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,不過畢竟是知名品牌,費用相較起來貴不少...

幹掉 Twitter 的推薦功能

Update:官方的「Show the best Tweets first」設定已經更新了,理論上你關掉後就不會出現這些 spam:

以下是原來的文章。


Twitter 預設是照時間排序,但是在這幾年就加入了「你可能會感興趣的 blah blah blah」之類的官方 spam,或是把 like 的插進來。

先前要幹掉這些功能頗麻煩的,我是看到就按不喜歡,然後大概就會有幾個禮拜不會出現,然後過一陣子後又冒出來...

最近有人找到方法可以一勞永逸的幹掉這些功能,找資料看起來是從這篇開始的,有人發現只要 mute 一些關鍵字就可以把這些功能從 timeline 上幹掉:

我找資料發現這些字其實是出現在 data attribute 上:

然後就有人開始翻開始整理了:

目前看起來效果頗不錯啊,這樣連手機上都可以擋掉這些 spam,頗不賴 :o

Hacker News 的潛規則

在「A List of Hacker News's Undocumented Features and Behaviors」這邊列了不少 Hacker News 的潛規則,看過後其實比較重要的是「當你需要自己實做一個類似的系統時,有哪些歷史教訓是人家已經走過的」。

像是 Anti-Voting Manipulation 與 Flame-War Detector 都是蠻常見的情境,Shadowbanning 則是防治廣告機制中比較軟性的一環。Green Usernames 也算是軟性的機制...

另外產品面上,Hacker News 也設計一些常見的 list 讓使用者除了首頁以外的選擇。

GitHub 的 Gist 要移除匿名發表的功能了...

GitHubGist 變成要註冊使用者才能貼了:「Deprecation notice: Removing anonymous gist creation」。主要的原因也還是因為太多 spam 之類的訊息:

In 30 days, we'll be deprecating anonymous gist creation—a decision we made after a lot of deliberation. Anonymous gists are a handy tool for quickly putting a code snippet online, but as the only way to create anonymous content on GitHub, they also see a large volume of spam. In addition, many people already have a combination of tools authenticated with GitHub that allow them to create gists they own.

預定是 3/19 關閉... 只好繼續貼 Pastebin 了... XD

Amazon SES 提供 Dedicated IP Address 的養 IP 機制...

透過混搭本來的 shared IP address (已經對各 ISP 有信用) 與客戶租用的 dedicated IP address 混發,然後一段時間後養起來 (最多 45 days):「Amazon SES Can Now Automatically Warm Up Your Dedicated IP Addresses」。

Amazon SES controls the amount of email that can be sent through an IP address. Amazon SES uses a predefined warm-up plan that indicates the maximum number of emails that can be sent daily through an IP address to ensure the traffic is increasing gradually over 45 days.

要注意的是,這個過程需要發五萬封才有辦法養出來,不是設上去就會自己養

After you successfully warm up your dedicated IPs (either by yourself or by using the Amazon SES automatic warm-up mechanism), you must send at least 50,000 emails per dedicated IP per day so that the IPs maintain a positive reputation with ISPs. To avoid throttling by the ISPs, avoid sending a high volume of emails soon after the completion of warm-up; we recommend gradually increasing the volume for better deliverability.

現在弄 mail service 超麻煩的...

用 Google 的 Speech Recognition API 破 Google 的 reCAPTCHA

就是「以子之矛,攻子之盾」的概念,用 Speech Recognition APIreCAPTCHA:「ReBreakCaptcha: Breaking Google’s ReCaptcha v2 using.. Google」。

就算 Google 在 reCAPTCHA 的聲音裡面加入 watermark,讓自家的 Speech Recognition API 拒絕分析,還是有其他家的可以用 (像是 Amazon Lex 或是 Bing Speech API),所以這樣做不是什麼好解法。

自建 Mail System 的難度

Hacker News 上的「Ask HN: Is it possible to run your own mail server for personal use?」這篇道出了現在自建 mail system 的難度。作者遇到信件常常被各大 mail 服務歸類成 spam:

The problem is making sure my mail is not marked as spam by the major MTAs out there, gmail and hotmail both mark my mails as spam.

整理一下現在自己建 mail system 要做到哪些事情:

  • 確認 IP (包括 IPv4/IPv6) 沒有列入任何 Open Relay 清單中。
  • 確認 IP 的反解可以查出對應的正解。
  • 確認 SPF 設定。
  • 確認送出去的信件有 DKIM 簽名,而且 DNS 也有設上對應的設定。
  • 確認 TLS 的發送與接收都正常。
  • 確認 DMARC 機制正確運作。

如同「Exercising Software Freedom in the Global Email System」這邊講的,現在要自己搞 mail system 超累...

Amazon SES 可以收信了...

之前 Amazon SES 只能拿來發信,現在可以收信了:「New – Receive and Process Incoming Email with Amazon SES」。

收信下來後可以放到 S3,也可以用 SNS 接,或是用 Lambda 處理。除此之外還有 Spam & Virus 檢查的功能...

一時間想不到用途 :o

Google 發表計算網頁真實性的演算法 (Knowledge-Based Trust)

Slashdot 上看到 Google 發表了計算網頁真實性的演算法,Knowledge-Based Trust (KBT):「Google Wants To Rank Websites Based On Facts Not Links」,原始的論文 PDF 檔案可以在「Knowledge-Based Trust: Estimating the Trustworthiness of Web Sources」這邊取得。

論文本身的原理不難懂 (其實方法相當有趣),主要是給出了三個貢獻。

首先是能夠區分是取出資訊的方法有問題 (extract 的演算法不夠好),或是網站本身就給出錯誤的資訊:

Our main contribution is a more sophisticated probabilistic model, which can distinguish between two main sources of error: incorrect facts on a page, and incorrect extractions made by an extraction system.

第二個則是在效能上的改善:

Our second contribution is a new method to adaptively decide the granularity of sources to work with: if a specific webpage yields too few triples, we may aggregate it with other webpages from the same website. Conversely, if a website has too many triples, we may split it into smaller ones, to avoid computational bottlenecks (Section 4).

第三個則是提出好的分散式演算法,可以螞蟻雄兵計算出來:

The third contribution of this paper is a detailed, large-scale evaluation of the performance of our model.

KBT 並不是要取代 PageRank,而是跟 PageRank 互相配合,可以有效打擊內容農場 (Content farm) 這類網站,畢竟 PageRank 的假設在一般的狀況下是有邏輯的。

在「High PageRank but low KBT (top-left corner)」這段講到了這件事情:

We consider the 15 gossip websites listed in [16]. Among them, 14 have a PageRank among top 15% of the websites, since such websites are often popular. However, for all of them the KBT are in the bottom 50%; in other words, they are considered less trustworthy than half of the websites. Another kind of websites that often get low KBT are forum websites.

再找時間細讀其他類似的演算法...