WWDC 2015 Session 706 (video, PDF):
If you link your app against OS X El Capitan or iOS 9, by default it won’t be able to make any unprotected HTTP connections; they will simply fail, and any TLS connections that your app makes will have no adhere to these best practices that I just described. And that’s TLS 1.2 with forward secrecy. Cryptographic primitives that are known to be insecure are not allowed, and there are minimum key size requirements put in place.
Now, you may not be able to comply with all of these restrictions immediately, and that’s okay, you can specify exceptions in your Info.plist either on a case-by-case basis for each domain or as a global override. But, as an industry we have to very soon get to a point where no user information hits the network unencrypted, and we need your help.
What’s New in iOS 9:
App Transport Security (ATS) lets an app add a declaration to its Info.plist file that specifies the domains with which it needs secure communication. ATS prevents accidental disclosure, provides secure default behavior, and is easy to adopt. You should adopt ATS as soon as possible, regardless of whether you’re creating a new app or updating an existing one.
If you’re developing a new app, you should use HTTPS exclusively. If you have an existing app, you should use HTTPS as much as you can right now, and create a plan for migrating the rest of your app as soon as possible.
WWDC 2015 Session 711 (video, PDF):
Essentially all you have to do is declare which domain needs to load over HTTP and NSURLSession will still allow that cleartext load.
Now we also know that some of you may be supporting a general purpose web browser or another app that loads URLs based off dynamic user input, and we’ve allowed for that case.
[…]
So, do note that ATS is only active if you build against a current SDK.
[…]
NSURLSession will transfer all HTTP resources or loads URLs to HTTPS automatically.
App Transport Security Technote:
All secure http (https) connection follow the App Transport Security default behavior in apps built for iOS 9.0 or later, and OS X 10.11 or later. Connections that do not follow the requirements will fail.
[…]
You can specify exceptions to the default behavior in the Info.plist in your app or extension. Keys in the plist are used for specific exceptions or to turn off App Transport Security. Table 1-1 shows the keys and their types.
Blake Gentry (comments):
The ideas behind App Transport Security are great. It’s essentially HTTP Strict Transport Security for apps, making it much harder for developers to inadvertently disclose private user information. The feature that will benefit the privacy and security of millions of Apple customers. The writing is also on the wall that Apple intends to make this feature mandatory at some point, essentially deprecating plaintext HTTP altogether.
Apple, however, has yet to take their own advice. There are many OS X components and Apple apps that still do not use encryption exclusively, relying on HTTP over port 80. Here’s an example from the brand new Photos app, communicating with AWS S3 over port 80 […] So far I’ve encountered 9 separate OS X services or first-party apps that are still relying on plaintext HTTP.
See also: The Rush to “Deprecate” HTTP.
Cocoa Conference iOS iOS 9 Mac Mac OS X 10.11 El Capitan Networking Privacy Security SSL/TLS Web WWDC
Chris Adamson:
Because here’s the difference — and you figure there has to be a difference for it to be worth Apple’s time to develop an supplementary standard to what they already have and everyone’s using. The point of “FairPlay Streaming” seems to be to plug holes in the server-to-viewer chain where the media could be copied in some way.
[…]
The standard seems particularly interested in preventing you from AirPlay’ing content to other devices.
[…]
So the first part here is that when AirPlaying to an Apple TV, FairPlay Streaming basically turns the Apple TV into a Chromecast: it transfers responsibility for downloading and playing the stream to the AppleTV, rather than having the iOS/OSX device fetch the content and then re-stream it to the Apple TV. Good in one sense, because this effectively halves the amount of data being sent across your network.
But look at that last point: FPS content cannot be captured by the user if they’re, say, streaming it to their Mac. It’s not clear if this is also the behavior when playing an FPS stream directly in OS X or iOS. It’ll suck if it is, because this basically would mean that streams would behave the same way DVDs do when you try to get a screenshot: you get a blank rectangle.
[…]
So this seems like a feature that’s likely to do little to prevent piracy, while taking away the ability to do things we already do, like grab screenshots, livestream group viewings, or screen-record things like reaction videos. And even if it works, we’ll just seek out workarounds[…]
AirPlay Apple TV DRM FairPlay iOS iOS 9 Mac Mac OS X 10.11 El Capitan Video
Chris Adamson:
We’ve found we have to fall back to the software encoder because the hardware encoder (kAppleHardwareAudioCodecManufacturer) would cause ExtAudioFileWrite() to sometimes fail with OSStatus -66570 (kExtAudioFileError_AsyncWriteBufferOverflow). So I asked about that and was told “oh yeah, we don’t support hardware encoding anymore… the new devices don’t need it and the property is just ignored”. I Slacked this to my boss and his reaction was “would be nice if that were in the documentation!”
[…]
Enter Tim [Monroe], and the new AVMovie. This is a new editing API, an alternative to the AVComposition stuff, and is much more strongly influenced by the old QuickTime APIs (and, in turn, by the QuickTime file format itself). This brings back some of the important concepts of the old QuickTime API, such as modifier tracks: tracks that consist only of instructions to modify other tracks at certain times. AVComposition offered some support for this with opacity ramps and affine transforms (in the hideously-named AVMutableVideoCompositionInstruction class) but QuickTime was always able to offer a much broader range of functionality, and could save those instructions in the file itself until they were needed for a final export.
[…]
And yes, I did say “headers”. The new QuickTime-inspired editing APIs aren’t in the OS X 10.11 docset yet, and they don’t exist at all on iOS.
I’m certainly happy to see this new approach to editing video, although it’s going to be hard to clarify when to use AVMovie versus AVComposition. For example, doing compositing work with affine transforms and opacity, or pulling in Core Animation graphics, may work better with the AVComposition APIs, at least until AVMovie is built out and understood. And for the hardcore, there’s always the low-level approach of doing your own rendering, perhaps with Core Image, and writing samples with AVAssetWriter.
[…]
I wonder about the internal design and architectural politics that led to this about-face on AV Foundation editing, after holding to the company line for so long on the AVComposition stuff.
Audio AVFoundation Core Audio Documentation iOS iOS 9 Mac Mac OS X 10.11 El Capitan Programming QuickTime Video
Manton Reece:
Just acknowledging this publicly is progress. It’s now been almost 3 years since my last tweet. I don’t expect to return to Twitter, but I’m still very interested in whether there’ll be a noticeable change in direction from the new CEO.
Update (2015-07-20): The source of the quote is here.
Twitter
Matthias Gansrigler:
The bug itself is described fairly easily. You have a .webarchive file you’d like to move using Yoink. So you drag it onto the app and then move it from Yoink to the actual destination. Business as usual.
Only that now, instead of opening the webarchive in your standard browser when double-clicked, above’s warning is shown.
[…]
There are two ways a security-scoped bookmark can be created – either with read and write access, or read-access only (NSURLBookmarkCreationWithSecurityScope or it plus NSURLBookmarkCreationSecurityScopeAllowOnlyReadAccess).
I don’t know why this causes the issue, but changing the bookmark creation options from read and write access to read-access only fixed the issue (and moving the file is still possible with Yoink). It definitely looks like a sandbox bug to me.
Why should an app-internal bookmark (mind you, it’s only a reference to a file, not the file itself, created from an NSURL object) write to and change the webarchive’s file so that it a) can’t be opened anymore and b) shows the bookmark-creating-app as its creator?
Minor correction: all the .webarchive files I’ve seen are binary property lists, not bundles.
Bug Gatekeeper Mac Mac App Store Mac OS X 10.10 Yosemite Sandboxing Security Scoped Bookmarks
Laurin Brandner:
About two weeks ago, Apple released the first beta of Xcode 7 which comes with shiny new features like built-in UI testing. Apart from Swift, this was easily the feature that excited me the most. I couldn’t wait to try it out. Not that UI testing is anything new; KIF has been around since 2011. It’s a great tool but it has its limitations: it’s slow, it’s not 100% reliable and it depends on private API. Therefore, an official solution seemed like a good idea.
[…]
Because Xcode 7 was constantly crashing, I had to decrease the number of iterations to 5 times and then multiplied it by 4.
[…]
XCTest makes it easy to write simple UI tests. More advanced tests are difficult or just not possible. KIF is a lot more flexible.
Compared to KIF, however, XCTest is slightly faster at finding the UI elements. With animations disabled, XCTest is really fast.
Bug iOS Programming Swift Programming Language Testing Xcode
