Category: Spam

批評 Medium 不適合當作 Blogging Platform...

這篇文章批評了 Medium 不適合當作 Blogging Platform：「Medium is a poor choice for blogging」。

文章裡提到的情況我之前也常遇到 (然後默默的點 X 關掉...)，我是還蠻建議把 [*.]medium.com 放到 Google Chrome 的 javascript 禁止清單裡面，這樣畫面會乾淨很多，而且也省很多 CPU 資源...

不過自訂網域的部分就沒辦法用這個方式擋了，有點可惜...

幹掉 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 要移除匿名發表的功能了...

GitHub 的 Gist 變成要註冊使用者才能貼了：「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

透過 DMCA takedown notice 非法下掉 Easylist 內的過濾條件

參考「Ad blocking is under attack」這邊，有業主 functionalclam.com 透過 DMCA takedown notice 發信要求 Easylist 移除過濾條件 (參考「2017-08-02-LevenLabs.md」)，對應的 commit 參考「M: Removed due to DMCA takedown request」) 這邊。

這件事情再次證實了 DMCA takedown notice 被濫用的情況，明明不是侵權的情況卻被拿來濫用 (因為對原提出者唯一的處罰必須過反過來提告，然後要得自己舉證因為這樣受損)。

目前看起來 EFF 願意介入，就來看看後續了。

Google 與 Facebook 都在建立消息驗證系統

Google 的在「Fact Check now available in Google Search and News around the world」這，Facebook 的在「Working to Stop Misinformation and False News」這。

Google 是針對搜尋與新聞的部份給出建議，透過第三方的網站確認，像是這樣：

後面的機制是透過公開的協定進行：

For publishers to be included in this feature, they must be using the Schema.org ClaimReview markup on the specific pages where they fact check public statements (documentation here), or they can use the Share the Facts widget developed by the Duke University Reporters Lab and Jigsaw.

但也是透過演算法判斷提供的單位是否夠權威：

Only publishers that are algorithmically determined to be an authoritative source of information will qualify for inclusion.

而 Facebook 是針對 Timeline 上的新聞判斷，但是是透過與 Facebook 合作的 partner 判斷，而且會針對判斷為假的消息降低出現的機率：

We’ve started a program to work with independent third-party fact-checking organizations. We’ll use the reports from our community, along with other signals, to send stories to these organizations. If the fact-checking organizations identify a story as false, it will get flagged as disputed and there will be a link to a corresponding article explaining why. Stories that have been disputed also appear lower in News Feed.

我不是很喜歡 Facebook 的方法，變相的在控制言論自由 (不過也不是第一天了)。

透過 DNS TXT 傳遞指令的惡意程式

看到「New Fileless Malware Uses DNS Queries To Receive PowerShell Commands」這篇，所以是有人開始這樣惡搞了...

Distributed through an email phishing campaign, the DNSMessenger attack is completely Fileless, as it does not involve writing files to the targeted system; instead, it uses DNS TXT messaging capabilities to fetch malicious PowerShell commands stored remotely as DNS TXT records.

利用 DNS 的穿透力來取得外部資訊...

用 Google 的 Speech Recognition API 破 Google 的 reCAPTCHA

就是「以子之矛，攻子之盾」的概念，用 Speech Recognition API 破 reCAPTCHA：「ReBreakCaptcha: Breaking Google’s ReCaptcha v2 using.. Google」。

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

Amazon EC2 會對 Port 25 的連線數量限制

起因於一台 ap-northeast-1 的機器 (東京) 會使用 us-west-2 的 SES (美西，奧勒岡)，然後發現信延遲的有點嚴重，看 mail log 發現是因為連線 timeout。

查了以後發現在「Amazon SES SMTP Issues」這邊就有提到 EC2 instance 對 port 25 有限制：

You are sending to Amazon SES from an Amazon EC2 instance via port 25 and you cannot reach your Amazon SES sending limits or you are receiving time outs—Amazon EC2 imposes default sending limits on email sent via port 25 and throttles outbound connections if you attempt to exceed those limits. To remove these limits, submit an Amazon EC2 Request to Remove Email Sending Limitations. You can also connect to Amazon SES via port 465 or port 587, neither of which is throttled.

按照建議，直接走 port 587 就可以解決，另外一個方法是開 support ticket 請 AWS 解除：「How do I remove the throttle on port 25 from my EC2 instance?」。

Amazon EC2 throttles traffic on port 25 of all EC2 instances by default, but you can request that this throttle be removed for your instance at Request to Remove Email Sending Limitations (you must sign in with your root account credentials). Provide a description of your use case for sending email, and then choose Submit.

還是改走 port 587 比較簡單一點...

Gmail 要開始導入 SMTP Strict Transport Security 了

SMTP MTA Strict Transport Security 算是 SMTP STARTTLS 裡的 HSTS 機制，而 Google 的人在 RSA Conference 上提出要開始用了：「SMTP STS Coming Soon to Gmail, Other Webmail Providers」。

Elie Bursztein, the head of Google’s anti-abuse research team, said at RSA Conference that SMTP STS will be a major impediment to man-in-the-middle attacks that rely on rogue certificates that are likely forged, stolen or otherwise untrusted. Google, Microsoft, Yahoo and Comcast are expected to adopt the standard this year, a draft of which was submitted to the IETF in March 2016.

補上去後對於 SMTP 的隱私保護就會更好了...