圖文來源：ars technica（Infinite Loop）
上週蘋果將 Mac App Store 上傳軟體強制包含沙盒（sandboxing）防護的期限延長到了明年（2012）年的三月一號，對於部分 Mac 軟體開發者算是可以喘一口氣。
sandboxing 防護對於 iOS 軟體開發者來說，應該是一點也不陌生，因為從一開始蘋果就強制要求 iOS 開發者納入 sandboxing API 讓軟體彼此區隔，並且限制軟體對於系統資源的取用，想當然也會讓軟體的部分功能遭到限制，但也可以增加系統的安全性。
而如今這樣的安全防護，也將在每一個上傳到 Mac App Store 的軟體上面實施，如果不願意配合的開發者，到時候就得收拾包袱，離開伊甸園。 這樣的措施對於一般 Mac 使用者來說，同樣可減少被惡意軟體侵擾的機會，但開發者就得面臨保留功能或是推廣銷售管道間的取捨。
然而也不是每一個軟體的開發者都會遇到左右為難的狀況，讓軟體被 sandboxed，對於有些開發者來說反倒是省了不少麻煩；一如 Agile Bits，他們為了要讓 1Password 這套軟體趕上原先包含沙盒（2011 年 11 月 1 號）的規定期限，可以說是花了不少功夫，也讓軟體本身少了部分功能以及使用上的彈性，不過他們認為一旦了限制一般使用者存取儲存密碼的檔案，多少會減少一些悲劇（手滑誤刪啥的），也讓客服可以輕鬆一點。
相同的意見也被大部分的軟體開發者所認同，至少對於 99.5% 的軟體開發者來說，sandboxing 是利多於弊；那另外的 0.5% 呢？對於這 0.5% 來說，相關的限制將讓他們非常頭大，以 Panic 家的 Transmit FTP 軟體為例，一旦放入沙盒，他們將無法直接讀取、執行一些硬碟中的檔案，大大影響該軟體的正常功能；雖然他們可以向蘋果申請緩執行相關的限制，不過在三月一號以後也必須漸漸跟大家一樣。
也因此有開發者建議，蘋果是否該提供更好的 API 來讓他們把軟體放到沙盒的同時，也能讓原本的功能遭受最少的閹割；另一方面，也有使用者質疑讓全部 Mac App Store 軟體進沙盒的必要性，畢竟原先的架構已經足以提供相當的安全性防護，這樣的作法，或許根本是蘋果想要限制第三方軟體的能為，就像其他 iOS 軟體一樣。
不過如果真要做，蘋果大可讓全部的軟體通通只能走 Mac App Store，但也難說，說不定這就是蘋果的終極目標也不一定。
不知道各位對於沙盒這回事有啥其他想法要分享呢？
更多相關有趣內容：
- Mac OS X Lion 升級版（Mac App Store 下載）安裝懶人包...
- 蘋果出包？PayPal 出包？Mac OS X Lion 下載重複扣款責任難了？
- 【好撇步】Mac 實用小技巧：螢幕截圖
