貳零壹貳參月壹日起,Mac App Store 軟體一律在自己的沙盒裡面玩!

貳零壹貳參月壹日起,Mac App Store 軟體一律在自己的沙盒裡面玩! 

圖文來源: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,但也難說,說不定這就是蘋果的終極目標也不一定。

不知道各位對於沙盒這回事有啥其他想法要分享呢?

更多相關有趣內容: