關於iOS元旦http,https的規定,官方論壇迴應

先貼原文地址:https://forums.developer.apple.com/thread/48979#146140  

原文:

eskimoAug 2, 2016 4:17 AM(in response to RLKingSoftware)

First up, there have been no changes to the technical behaviour of ATS (other than the addition of NSAllowsArbitraryLoadsInWebContent and NSRequiresCertificateTransparency).  From a technical perspective, ATS exceptions in the newly seeded OS releases work the same way as they do in the current OS release.

 

What has changed is that App Review will require 「reasonable justification」 for most ATS exceptions.  The goal here is to flush out those folks who, when ATS was first released, simply turned it off globally and moved on.  That will no longer be allowed.

The impact of this will depend on the circumstances of your app.  I don’t work for App Review, so I can’t give definitive answers as to what constitutes a 「reasonable justification」 in their minds.  However, I can recommend that you do the following:

• watch the WWDC session where we announced this change (WWDC 2016 Session 706 What’s New in Security) so that you can get a feel for the rationale behind it

• carefully audit your app’s use of HTTP and HTTPS

• construct a minimal ATS exception dictionary

• if you have ATS exceptions, keep notes about your analysis so that you can refer back to them when you need to submit your justification to App Review

Finally, if there are places where ATS has limitations that cause you to specify wider exceptions than one might reasonably expect, file an enhancement request against ATS for more appropriate exceptions.  Make sure to note the bug number to use in your justification.  And I’d appreciate you posting your bug number here, just for the record.

[I’ve removed the following example because we introduced NSAllowsLocalNetworking in iOS 10.0b4, partly based on the feedback we got from developers like you.  Thanks everyone!  OTOH, the general advice from the previous paragraph still stands.]

For example, right now ATS has very poor support for dealing with accessories on the local Wi-Fi.  An app that needs to deal with such an accessory may well need to set NSAllowsArbitraryLoads.  In that case, it would be wise to file a bug that describes your app’s requirements and requests better support from ATS, and use that bug number as part of your justification.

Share and Enjoy 
— 
Quinn 「The Eskimo!」 
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 
let myEmail = "eskimo" + "1" + "@apple.com"

 

谷歌直翻譯文:

首先，ATS的技術行爲沒有改變（除了添加NSAllowsArbitraryLoadsInWebContent和NSRequiresCertificateTransparency）。從技術角度來看，新種植的OS版本中的ATS異常的工做方式與當前操做系統版本中的相同。改變的是，應用程序審查對大多數ATS異常須要「合理的理由」。這裏的目標是清除那些誰，當ATS首次發佈時，只是把它全球關閉，繼續前進。這將再也不容許。這將取決於您的應用程序的狀況。我不爲App Review工做，因此我不能給出肯定的答案，什麼構成一個「合理的理由」在他們的頭腦。可是，我建議您執行如下操做：觀看咱們宣佈此更改的WWDC會議（WWDC 2016會議706安全性的新增功能），以便您能夠了解其背後的理由仔細審覈您的應用程序的HTTP和HTTPS的使用構造最小ATS異常字典若是您有ATS異常，請記錄您的分析，以便您能夠在須要向App Review提交您的理由時參考它們最後，若是有某些地方ATS有限制，致使您指定比合理指望的更寬的例外，請針對ATS提出加強請求以得到更合適的例外。確保記下在您的理由中使用的錯誤號。我很感謝你在這裏發佈你的bug號碼，只是爲了紀錄。[我刪除了如下示例，由於咱們在iOS 10.0b4中引入了NSAllowsLocalNetworking，部分基於咱們從像您這樣的開發人員那裏得到的反饋。感謝你們！ OTOH，上一段的通常建議仍然存在。]例如，如今ATS對於處理本地Wi-Fi上的附件的支持很是差。須要處理這樣的附件的應用程序可能須要設置NSAllowsArbitraryLoads。在這種狀況下，明智的作法是提交一個描述應用程序需求的錯誤，並請求ATS提供更好的支持，並使用該錯誤編號做爲您的理由的一部分。分享和享受- - Quinn「愛斯基摩！蘋果開發人員關係，開發人員技術支持，核心操做系統/硬件let myEmail =「eskimo」+「1」+「@ apple.com」