如果您正在使用 Windows 或 macOS，並且安裝了 Adobe Creative Cloud，您可能需要檢查一下您的 hosts 檔案。原來 Adobe 會因為一個非常愚蠢的原因，在 hosts 檔案中加入大量條目。

他們是利用這個方法來偵測您在瀏覽他們網站時是否已經安裝了 Creative Cloud。

當您瀏覽 https://www.adobe.com/home 時，他們會使用 JavaScript 載入這張圖片：

https://detect-ccd.creativecloud.adobe.com/cc.png

如果您的 hosts 檔案中存在該 DNS 條目，您的瀏覽器就會連接到他們的伺服器，這樣他們就知道您安裝了 Creative Cloud；反之，載入失敗，他們就會偵測到。

他們以前只是直接連接到您的 Creative Cloud 應用程式，載入 http://localhost:<各種埠號>/cc.png，但後來 Chrome 開始封鎖本機網路存取，所以他們不得不改用這種 hosts 檔案的技巧。

商業軟體套件在什麼時候會變成惡意軟體？

商業軟體套件在什麼時候會變成惡意軟體？

這讓人聯想到 2000 年代中期 Sony/BMG 的根目錄病毒事件。雖然修改 hosts 檔案不算是根目錄級別的漏洞，但它仍然是第三方軟體絕對不應該觸碰的東西；絕大多數的 Windows/Mac 使用者自己甚至不知道它是什麼或它的作用。

在這個充斥著「氛圍編碼」的時代，我不會驚訝於這種系統級別的修改最終會導致作業系統安裝損壞和資料遺失，當一家商業軟體公司懶得對他們「Claude 嘔吐」出來的程式碼進行品質控制，並為了保護複製權而修改了比 hosts 檔案更重要的東西時。

每一個*軟體都想完全掌控您的機器。他們膽敢假定自己比使用者和已安裝的其他軟體更優越。

（啟動畫面、通知圖示、工作列釘選、…）

但理論上，內建 DRM 的 Windows 應該能為這個動物園帶來秩序。然而，就像 Steam 的強大保護措施不足以阻止第三方繼續推行垃圾保護機制一樣。

啊，我認為在「氛圍編碼」之前，我們已經有很多垃圾了。還記得 StackOverflow 的「複製貼上」時代嗎？甚至在那之前，開發人員就會隨便貼上看起來能過關的程式碼，並想辦法推行。

AI 只是放大了它。糟糕的程式設計師變得更糟，優秀的程式設計師變得更好。

但理論上，內建 DRM 的 Windows 應該能為這個動物園帶來秩序。

順帶一提，標準的音訊 CD 在 Windows 中不受任何 DRM 的約束，至今您仍然可以使用 Windows Media Player 將它們擷取成 MP3 或 WAV 格式。這是因為標準音訊 CD 是一種 ISO 標準，因此不僅可以以合理的費用從 ISO 購買規格，而且任何專利持有者都必須根據 FRAND 條款（這意味著他們不能施加任意的複製限制，例如）授予您授權。

整個 Sony/BMG 根目錄病毒事件之所以發生，正是因為 Sony 想在 ISO 格式上施加 DRM，所以他們的「解決方案」是在您的機器上安裝惡意軟體，以防止任何複製軟體存取音訊軌。如果有的話，較新版本的 Windows（Vista 及以上版本）破壞了這個 DRM，因為您會收到一個自動播放提示、一個使用者帳戶控制提示（這不是您預期從音訊 CD 獲得的，所以「否」是正確的答案），以及可能一個未簽名的驅動程式警告。

即使是 DVD 和藍光，Windows 也不會阻止複製，如果您有像 DVDFab 或 Xreveal 這樣的「未授權」工具，Windows 會讓這些工具順利存取光碟機，只有像 PowerDVD 這樣的官方工具必須使用受保護媒體路徑來播放藍光，這是因為好萊塢要求如此（您可以在 Windows XP 中以 HD 畫質觀看藍光）。

我的觀點更在於，目前像微軟和亞馬遜這樣的公司，將「AI」生成的程式碼視為「聖杯，保證 100% 可用且不應質疑，直接發布到生產環境」，其後果是不可避免且滑稽到悲劇的。微軟發現了數百個新引入 Windows 的錯誤，亞馬遜在 AWS 發生了故障，這都是由於這種輕率的態度和荒謬的開發方法造成的，兩家公司都不得不公開縮減這種態度並進行修復分類。

「AI」在編寫程式碼方面並不比人類更好；它本質上就是「垃圾進，垃圾出」，它只是在整個 Stack Overflow 複製貼上這件事上比我們快。它不在乎是否犯錯，它沒有自尊、傲慢或責任感，它不會告訴您它抄襲了錯誤甚至危險的程式碼。這就落到了實際的開發人員和 QA/QC 人員身上，以確保程式碼是正確的，並且在發布時不會導致整個系統崩潰。

我看到「AI」參與軟體開發有一個切實可行、可證明的益處，那就是在尋找錯誤/漏洞方面。一年前，它的可靠性很低，有時會編造新的錯誤而不是找到它應該找到的錯誤。據我所知，現在它更準確了，並且，**當由經驗豐富且才華橫溢的開發人員使用時**，它可以比開發人員單獨工作快得多、徹底得多。請注意強調：最終，人類**必須**參與到這個過程中，否則一切都會像紙牌屋一樣崩塌。

AI「輔助」開發是危險的，正是因為它感覺起來很有能力，而且說實話，它可能確實能產生比許多開發人員更高的程式碼（不一定更正確）。

所以，當一個沒有經驗的開發人員看到一個漂亮的輸出時，他們會認為自己有了解決方案。

但當一個有經驗的開發人員查看 AI 程式碼時，他可以識別出哪些部分是好的，哪些部分是純粹的 BS，並將其指出來。

換句話說，有能力的程式碼審查變得更加重要。

問題是……高層屬於「完全不知道程式碼是否真的正確」的陣營。對他們來說，它看起來足夠有能力了。

「你為什麼不寫更多 AI 程式碼？」 「但是，先生，這是垃圾。」 「約翰每天提交 10 個拉取請求，要麼跟上，要麼我們將把你列入 PIP（績效改進計畫）。」

謝謝，我感覺我們在這裡完全一致。：)

像這樣的東西應該是完全非法的。句點。

Adobe 無權修改系統級檔案。句點。

Chris Titus 的 Windows 清理工具提供了一個選項來阻止 Adobe Cloud 的 BS，他似乎已經領先一步了。我剛看了他的腳本對 hosts 檔案所做的更改——有大約 900 行與 Adobe 相關，例如：

#New Ver 26.8 0.0.0.0 adobe.io 0.0.0.0 x0850n5e.1q9cz.adobestats.io 0.0.0.0 0ojupfm51u.adobe.io 0.0.0.0 ssrtnxk6uq6x.sf7e3.adobestats.io 0.0.0.0 v62vpzg2av.adobestats.io 0.0.0.0 a1815.dscr.akamai.net 0.0.0.0 ims-na1.adobelogin.com.cdn.cloudflare.net 0.0.0.0 o1383653.ingest.sentry.io 0.0.0.0 wtl71c0ylo.adobestats.io 0.0.0.0 3d5vic7so2.adobestats.io 0.0.0.0 o987771.ingest.us.sentry.io 0.0.0.0 vgetwxoqno.adobe.io 0.0.0.0 cc-api-data.adobe.io 0.0.0.0 cctypekit.adobe.io 0.0.0.0 lm-prd-da1.licenses.adobe.com 0.0.0.0 zqr7f445uc.adobestats.io 0.0.0.0 zz8r2o83on.adobestats.io 0.0.0.0 6ll72mpyxv.adobestats.io 0.0.0.0 g6elufzgx7.adobestats.io 0.0.0.0 gdtbhgs27n.adobestats.io 0.0.0.0 hciylk3wpv.adobestats.io

當然，如果您擁有 Adobe Creative 產品，封鎖所有這些條目會導致其損壞，但天啊，900 個條目！

瀏覽器如何在未經您許可的情況下修改系統級檔案並寫入？

權限可能隱藏在他們冗長的服務條款中。

這就是為什麼所有東西都應該安裝在容器中。我喜歡 Bazzite 的這一點。Windows 應該做類似的事情——老實說，這在 Windows 上更重要。