【科技新聞】FTC 因使用 2FA 電話號碼進行廣告定位而對 Twitter 罰款 1.5 億美元

我對此沒有任何影響的最樂觀前景，但我真的希望這開創了一個先例，限制公司試圖將您的身份與電話號碼聯繫起來的黑暗模式的使用。我認為這筆罰款的總金額相當短視：它忽略了未來可能的數據洩露的長尾以及它可能對受影響賬戶背後的人產生的影響。

幾年前，我創建了當前的 Twitter 帳戶，但它一直處於休眠狀態。儘管沒有發布任何推文或使用會冒犯任何人的句柄或暱稱，但它被標記為“違反我們的政策”。為了解決這個問題，我必須輸入我的電話號碼來“保護”我的帳戶。我不知道是什麼過程觸發了這次審查，但如果它聞起來不像是一種將現有營銷資料與我的 Twitter 帳戶相關聯的簡單方法，我會被詛咒的。當然，介紹我用來了解行業新聞和發布有關 Goban 謎題的服務非常重要。

我也在 Discord 和類似平台上遇到過類似的模式； “糟糕！該帳戶（您剛剛創建的）發生了一些可疑的事情。請在您的個人資料中添加一個電話號碼以繼續。”

儘管我在身份/密碼管理方面遵循了一套合理的做法，但我通常採用“我不在乎是否丟失此帳戶”的方法來構建我的風險概況。如果該聲明不正確，那麼我將很樂意應用所有可用的安全措施。然而，創建“我不在乎”賬戶的想法似乎變得越來越困難，因為我們繼續投資於用戶營銷分析並降低進入這些不符合消費者最大利益的技術的門檻頭腦。

這對我來說是一個有趣的部分：“[T]he new order[0] 增加了更多條款來保護未來的消費者：…… Twitter 必須提供不需要人們提供電話號碼的多因素身份驗證選項。”

我希望看到這是一個更廣泛的規則。不，我不會被“短信很容易”或“騙子批量獲取可以接收短信的號碼更難”所感動。如果必須，請給用戶選擇權，但沒有義務交出手機號碼。

0 – https://www.ftc.gov/legal-library/browse/cases-proceedings/2…

Twitter 不允許我私信那些不關注我的人，因為我沒有提供手機號碼。我拒絕給它，主要是原則上。我很少發送消息，顯然不是機器人。什麼時候要求提供電話號碼才能訪問服務的基本元素？即使我嘗試向 DM 開放的人發送消息，也會發生這種情況。

這是一組非常有趣的發現。在閱讀本文時，重要的是要意識到這是一個倖存者偏差的案例。被審計的初創公司顯然還活著，任何遭受致命缺陷的公司很可能已經離開了池子。

在進行技術盡職調查（200 多個工作）的 15 年中，我還沒有遇到過一家公司，技術最終殺死了他們。但是商業案例問題，例如不知道部署產品的真實成本和在每筆交易中虧損是非常普遍的。成本分配不當、產品市場錯配、一廂情願、創始人衝突、創始人與投資者的衝突、依賴不存在的技術而暫時造假等等，都扼殺了相當多的公司。

技術是可以修復的，如果其他一切正常，就會有預算這樣做。無論預算如何，這些其他問題通常都無法解決。

> 簡單優於智能。作為一個自認是精英主義者，這樣說讓我很痛苦，但這是事實：我們審計的那些現在做得最好的初創公司通常都有一種近乎厚顏無恥的“保持簡單”的工程方法。

我之前寫過這個作為一個行業，我們為了複雜性而使編寫軟件變得複雜。

> 想像一下，在一個沒有乾淨代碼概念而是盡可能簡單地編寫代碼的世界裡。沒有成千上萬的間接類。

如果您的代碼邏輯是簡單的函數和一堆 if 語句會怎樣。不聰明，但它會工作。

如果您的招聘過程沒有針對算法效率進行優化，但某些東西只是可靠地工作，該怎麼辦。

想像一個軟件工程師使用的工具並不脆弱但易於使用和學習的世界。哦，世界將是一個美好的地方，但問題是大多數人不知道如何製作軟件。但在這裡，我們正在紙牌屋上構建軟件 [0]

:[0] – https://news.ycombinator.com/item?id=30166677

我已經看到了諮詢中的大多數架構問題 – 一個聰明的工程師團隊如何能夠將一件簡單的事情變得如此復雜，這真是令人驚訝。

微服務、僅限雲的依賴項、無法輕鬆創建環境、ORM 和包裝數據庫創建瘋狂模式的工具……這個列表還在繼續；如果你還早，你可以做的比在一個只使用 postgres、redis 和 nginx 並使用 'git pull' 部署的 monorepo 中創建一個明智的單體應用程序更糟糕……

大家好！我是 YouTubeDrive 的創建者 David，我從沒想過會在 HN 上看到這個老項目。 YouTubeDrive 是在我還是一名大學新生時創建的，我的編程能力值得懷疑，完全不了解編碼理論，而且空閒時間太多。

YouTubeDrive 使用的編碼方案非常簡單：在 64×36 圖像序列的每個像素中打包 3 位（我只使用 RGB 值 0 和 255，中間什麼都沒有），然後將這些圖像放大 20 倍製作 1280×720 視頻。這些 20×20 的彩色方塊足夠大，可以可靠地在 YouTube 的壓縮算法中存活下來（或者至少它們在 2016 年是這樣——從那以後算法可能已經改變了）。你確實需要那個大小的東西，因為我發現 YouTube 的視頻壓縮有時會將 10×10 正方形的平均顏色從 0 翻轉到 255，反之亦然。

現在回想作為一名研究生，我意識到有很多更聰明的方法可以解決這個問題：更好的編碼方案（離散傅立葉/餘弦/小波變換）可以讓我在頻域而不是空間域中打包比特，從而減少位翻轉錯誤的概率，以及一個好的糾錯碼（Hamming、Reed-Solomon 等）會讓我在這里和那裡容忍一些位翻轉。以經典的學術方式，我將把它作為練習留給讀者來實現這些擴展:)

– 回到文件共享剛剛興起的那一天，我從大學裡的朋友那裡贏得了兩輪啤酒——第一輪是在我嘗試了我所謂的硬核備份（Tarred、gzipped 和 pgp'd 存檔，在上面加上 avi 頭文件之後） ，將其重命名為 britney_uncensored_sex_tape[XXX].avi 或類似名稱，然後在 WinMX 上共享它，假設硬盤空間是空閒的，而且十幾歲的男孩是十幾歲的男孩，至少有一些下載它的人會留下它來分享，即使文件聲稱腐敗。

它很有魅力。

第二輪？一年後，當檔案仍然可以從無數主機處獲得時。

據我所知，它仍然在誰知道有多少舊硬盤驅動器上徘徊……

在寬帶普及之前，TiVo 過去常常在美國購買通宵付費節目時段，並播放修改後的 PDF417 視頻流，為 TiVo 用戶提供每週節目指南數據。 YouTube https://www.youtube.com/watch?v=VfUgT2YoPzI上有一個示例，但他們通常會在 28 分鐘的數據廣播前後播放 60 秒的廣告。數據流中有足夠的糾錯功能，即使在模擬電視接收效果不佳的情況下也能進行適當的處理。