App上架重磅通知：蘋果安全新規17年1月生效

01-26

也許很多人並不了解什麼是ATS（App Transport Security），但是對於App開發者，這卻是一個定時炸彈，引爆點在2016年底，後果就是你不注意，可能就會導致產品無法在App Store上架，雖然沒有違規操作下架那麼嚴重，但結果同樣致命。現在還有2個月的緩衝期，但還有很多開發者沒有想到這一點，有必要給大家提個醒。

ATS是在2015年由蘋果引入的強化網路傳輸安全的標準，要求所有的App在從Web端獲取數據的時候都要使用安全的HTTPS鏈接，並進一步強調要使用最新的TLS1.2版本的HTTPS。

註：可以從網址前綴http://或者https://來區別兩種標準

蘋果也清楚還有大量的Web內容仍舊在使用不安全的HTTP鏈接，因此定義了ATS開關選項的集合（Dictionary），允許大家通過info.plist文件設置（如下圖所示），不過我估計99.9%的開發者會選擇先打開允許任意鏈接的選項，然後大部分人過段時間就忘了這回事，好像什麼事都沒有發生過。

現在是醒過來面對現實的時候了，蘋果在WWDC時已經透漏，強制使用ATS的大限是今年底，也就是說，從17年開始蘋果審核團隊會將ATS作為強制審核項，以蘋果的脾氣，可能會硬來，反正已經給了一年多的緩衝期了！

到時一刀切怎麼辦？作為開發者應該如何處理？我們今天就來詳聊下這個問題！

首先，我們還是要了解具體的政策，然後在此基礎上做出合理的猜測，這樣每家根據自己的具體情況評估之後就知道該怎麼做了。然而無論如何，大的原則是要快速做出反應，不要存有僥倖心理！

當然，HTTPS是大勢所趨，蘋果強制執行ATS也是本著對用戶負責的態度，無可厚非。在執行的尺度上，我認為蘋果也會靈活的評估，肯定有一些"I will know it when I see it"的模糊情況，想必App Store的老司機都心領神會。

雖然說17年ATS會成為強制標準，但是這裡面還是分為幾種不同的情況的，為了幫助大家理解，沙銘從推廣和開發兩個角度去說

推廣角度

第一

App的內容來源如果有自家網站，去和技術核對一下是使用哪種傳輸標準，如果仍然使用HTTP或者是低於TLS1.2的HTTPS，要不就趕緊整改，要不就準備和蘋果審核磨，準備好申請特例的充分理由。在我的星座蘋果系列中有兩篇文章《善變雙子，難言的苦衷：史上最強審核團隊起底，掩藏的秘密》和《悶瓜金牛，本應昭告天下卻緘默：開發者賬號，審核加速揭秘》，了解應該如何跟審核團隊打交道，以及開發者賬號在審核過程中的作用，還是非常必要的。

第二

App的內容如果有來自已知的第三方，可以暫時不用管，讓技術設置一下ATS的開關（下文中會涉及），不過最好的做法是和第三方溝通下，敦促他們所有的傳輸都使用TLS1.2加密。

第三

App的內容來自於不可知的第三方，比如說允許用戶通過App訪問任意網站，可以忽視ATS，不過來自於自有網站的內容還是必須遵循第一條。同時詢問技術使用的是何種框架，如果是WebKit，建議切換到Safari，否則今後可能還會有麻煩事。

第四

如果是提供流媒體內容的App，不想服從於ATS，就必須在源頭進行流媒體加密，並且使用蘋果的流媒體框架，就可以暫時無視ATS。

因此，大家可以根據自己的情況來決定是採用哪種對策，當然上策是盡量使用TLS1.2的HTTPS安全標準，實在不行就要多想想如何跟蘋果解釋，以爭取特例！

不過有個問題目前還不是特別明朗：對於那些不達標準的已上架App如何處理？我個人不太相信App會因為這個原因被下架，蘋果最可能的做法是等到App迭代時拒絕上架。這時可能又有人會想了：那我就不更新！呵呵，也許也是一種辦法。總而言之，新一輪的貓捉老鼠遊戲又要開始了。

開發角度

第一

ATS設置中打開了以下開關，又沒有提交合理的解釋，那麼會100%被拒

NSAllowsArbitraryLoads，打開此開關相當於關閉ATS
NSExceptionAllowsInsecureHTTPLoads，使用自有網站的HTTP鏈接
NSExceptionMinimumTLSVersion，使用自有網站低於TLS1.2標準的HTTPS鏈接

至於什麼是合理的解釋，這個就完全是一個主觀判斷的過程了，也許有的人覺得自己的理由很充分，但是如果不能夠說服蘋果審核，你的App就是上不了線，這考驗團隊的溝通技巧和英文水平！

第二

以下幾種情況蘋果給予特例，不需要提供解釋：

App提供流媒體服務，媒體源已經對內容進行了加密，這時只要使用蘋果的AV Foundation框架載入內容，就可以無視ATS；
不使用Forward Secrecy（完全前向保密）技術，可以在ATS設置中關閉NSExceptionRequiresForwardSecrecy開關（預設是打開）；
NSThirdPartyException，使用第三方鏈接，而這裡面又包括使用第三方HTTP鏈接或者是低於TLS1.2版本的HTTPS等幾個開關。

估計有人會想，那我把自己的網站偽裝成第三方網站，使用這個特例不就好了，Bingo！如果你能經得起被拒甚至更重的懲罰，也許可以試試，不過有理由相信蘋果有多種方法判斷關聯網站，承受不起風險者勿試。

第三

ATS設置中還有個開關NSAllowsArbitraryLoadsInWebContent，打開後允許使用任意Web鏈接，這個和NSAllowsArbitraryLoads有些區別，主要是針對那些提供類似於Web瀏覽器服務的App，由於事先不知道用戶會瀏覽哪些網站，因此無法限制鏈接類型。

不過蘋果建議如果要提供瀏覽器類的服務，請使用SFSafariViewController，優於WKWebView，後者更適用於對用戶訪問web內容更有把控的情況。

關於ATS的詳細設置，開發可以參考蘋果官方文檔。

此外，蘋果還建議放棄以下較老的標準

RC4
SSLv3
SHA-1
3DES

並向最新的安全標準遷移，包括

Forward Secrecy
SHA-2
OCSP Stapling

蘋果對用戶隱私的關注度極高，以上的政策會隨時調整，如果想及時了解蘋果生態的最新動向，歡迎關注我的公眾號「沙銘世界觀」，網站精品課程：App推廣實戰技能（含ASO），沙銘又一力作

我是沙銘，OOPSING諮詢創始人，推廣圈裡最懂編程，碼農圈裡最懂推廣的蘋果專家，著有《星座蘋果》系列連載及《App運營推廣實戰（含ASO）》在線課程。