Jordan Rose:
This post describes what binary compatibility means in Swift 5 and how it will evolve in future releases of Swift.
[…]
To remove this restriction, the library author needs a feature currently being implemented called module stability. This involves augmenting the opaque [swiftmodule] format with a textual summary of a module, similar to what you see in Xcodeʼs “Generated Interface” view, so that clients can use a module without having to care what compiler it was built with. You can read more about that on the Swift forums.
[…]
Swift already has an implementation of support for library evolution, informally termed “resilience”. It’s an opt-in feature for libraries that need it, and it uses not-yet-finalized annotations to strike a balance between performance and future flexibility, which you can see in the source code for the standard library. The first of these to go through the Swift Evolution Process was @inlinable, added in Swift 4.2 (SE-0193). Look for more proposals about library evolution support in the future.
Previously: Swift 5 Release Notes for Xcode 10.2 Beta.
Update (2019-02-11): Joe Groff:
However, as a result of this, the Swift runtime is now a component of the user’s target operating system rather than part of the developer’s toolchain. As a consequence, in the future, for a Swift project to adopt new Swift runtime and standard library functionality, it may also have to require new OS versions that include an updated Swift runtime supporting the added features. This tradeoff between adopting new language features and frameworks or maintaining compatibility with older OS versions has always existed for Objective-C and Apple system frameworks, and will now be a factor for Swift as well.
[…]
The language compatibility setting is a purely compile-time feature that is used to control source compatibility. It does not affect ABI. You do not need to migrate Swift 4 code to Swift 5 mode in order to use Swift 5’s stable ABI, and going forward, new language modes can be adopted without imposing a newer OS requirement if language features that require new runtime features are not used.
It will not be possible to update the shared Swift runtime from a copy bundled with an app. But apps can continue to ship newer versions that are self-contained, as this is the only way Swift apps can run prior to macOS 10.14.4 and iOS 12.2.
iOS iOS 12 Mac macOS 10.14 Mojave Programming Swift Programming Language
Juli Clover:
Multiple popular iPhone apps from major companies are using intrusive analytics services that capture detailed data like taps, swipes, and even screen recordings without customer knowledge, reports TechCrunch.
Apps that include Abercrombie & Fitch, Hotels.com, Air Canada, Hollister, Expedia, and Singapore Airlines are using Glassbox, a customer experience analytics firm that lets developers use “session replay” screen recording technology within their apps.
[…]
Some apps, such as Air Canada, don’t properly mask data that’s recorded, exposing information like passport numbers and credit card information. Air Canada employees with access to the screenshot database can readily see this data.
Previously: Apple Granted Uber a Background Screen Recording Entitlement.
Update (2019-02-08): Zack Whittaker:
Apple is telling app developers to remove or properly disclose their use of analytics code that allows them to record how a user interacts with their iPhone apps — or face removal from the app store, TechCrunch can confirm.
[…]
TechCrunch began hearing on Thursday that app developers had already been notified that their apps had fallen afoul of Apple’s rules. One app developer was told by Apple to remove code that recorded app activities, citing the company’s app store guidelines.
“Your app uses analytics software to collect and send user or device data to a third party without the user’s consent. Apps must request explicit user consent and provide a clear visual indication when recording, logging, or otherwise making a record of user activity,” Apple said in the email.
Apple gave the developer less than a day to remove the code and resubmit their app or the app would be removed from the app store, the email said.
Dave Verwer:
I’ve never talked about this before, but the only relevant sponsor who I’ve ever turned down for iOS Dev Weekly was a company focused on in-app screen recording analytics. It was a few years ago now and I had no idea this was even a thing at the time. I just couldn’t believe that they were doing it and they were incredulous that I had a problem with it. It made me really angry. Looking at the client list on their site was shocking too. Your screen is almost certainly being recorded by some of the apps on your phone. I didn’t want to support that, and I didn’t take their money.
The irony is that in a past job I had, the company I worked for used one of these screen recording analytics tools and I was asked to look at the results as part of my job. I protested and made a case they they should remove it from their app, but I failed and as far as I know they continue to do it. The irony? To my annoyance, the data collected from that tool was incredibly useful, and I found at least one really hard to reproduce bug because I could watch it happen for a user. Even so, I never felt comfortable with it and was happy to put it behind me.
Update (2019-02-12): Zack Whittaker (Hacker News):
In an email, an Apple spokesperson said: “Protecting user privacy is paramount in the Apple ecosystem. Our App Store Review Guidelines require that apps request explicit user consent and provide a clear visual indication when recording, logging, or otherwise making a record of user activity.”
“We have notified the developers that are in violation of these strict privacy terms and guidelines, and will take immediate action if necessary,” the spokesperson added.
John Gruber:
I think Apple’s doing the right thing here, and it’s an impressive display of what the App Store review team can analyze, but given that this has been going on for years, I think 24 hours notice over a weekend is a bit drastic.
iOS iOS 12 iOS App Privacy
Benjamin Mayo:
Security researcher Linuz Henze has shared a video demonstration of what is claimed to be a macOS Mojave exploit to access passwords stored in the Keychain. However, he has said he is not sharing his findings with Apple out of protest.
Henze has publicly shared legitimate iOS vulnerabilities in the past, so he has a track record of credibility.
However, Henze is frustrated that Apple’s bug bounty program only applies to iOS, not macOS, and has decided not to release more information about his latest Keychain invasion.
Why doesn’t Apple have a bug bounty program for macOS?
Rene Ritchie:
Garbage. Disclose to Apple to help protect users then use the follow up to push for when (not if) the bounty program is launching.
There absolutely should be one and yesterday but don’t hold users hostage for your entitlement.
(Especially if you’ve previously dropped 0days…)
Dave DeLong:
Eh, mixed feelings. Civil disobedience is a well-established form of protest, and @apple tends to gloss over Mac stuff publicly, because it’s minuscule compared to iOS
And until he releases the exploit, there are no “hostages”. This isn’t blackmail.
Patrick Wardle:
Got to play with @LinusHenze’s ‘KeySteal’. It’s a lovely bug & exploit
✅ works on macOS 10.14.3
✅ his payload dumps passwords, private keys, & tokens
Protect yourself by:
🔐manually locking your keychain
🔐or setting a keychain-specific password
Lorenzo Franceschi-Bicchierai (Hacker News):
On Wednesday, after a talk at the Black Hat security conference in Las Vegas, Beer tweeted a message to Apple’s CEO Tim Cook, challenging him to pay for each bug he has reported since 2016, and asking him to donate $2.45 million to to human rights group Amnesty International.
[…]
Apple’s bug bounty program had a lackluster start last year. As Motherboard reported at the time, the majority of independent iOS security researchers had not submitted any bugs to Apple as part of the bug bounty, mostly because doing so would hinder future research and was just not worth the trouble, given that those exploits can be sold for much more money in the gray market of exploit brokers.
Previously: Apple Security.
Update (2019-02-08): Benjamin Mayo:
It is pretty twisted that Apple will bend the rules of their own bug bounty program so much for the Thompson family because of the press coverage. Meanwhile, ‘real’ security researchers are upset that Apple won’t even offer a program — of any kind — for macOS.
Previously: Major FaceTime Privacy Bug.
Jeff Johnson:
I could continue to pester Apple Product Security by email, but I don’t feel like it. I shouldn’t have to. I shouldn’t have to do anything except report the bug, which I did. I can accept that a mistake was made when my bug was not credited along with all of the others on October 30. What I cannot accept is that it takes more than 3 months to fix the mistake and simply update a web page on their site.
On a tangentially related note, the scam apps in the App Store that I blogged about previously are still in the App Store today. I also reported these apps to Apple Product Feedback. I’m not sure if that’s where you’re supposed to report App Store scams. Should you email Apple Product Security? Who knows. Why isn’t there a clearly identified place to report App Store scams to Apple?
Update (2019-02-11): Linus Henze:
On Tuesday @Apple contacted me and asked me if I would send them the details about my exploit. I told them that I would if they accept my offer. However, I’ve got no response from them. Today I wrote them again. Attached is an image of what I wrote.
John Gruber:
Why in the world Apple only offers security bounties for iOS is beyond my comprehension. Of course iOS has the most users, but the potential for truly critical bugs exists on all of Apple’s platforms.
qwertyoruiop:
as much as the FaceTime kid deserves the money he got, it’s very sad to see that Apple will only do things under the threat of bad PR. The bounty program has pissed off so many researchers that it seems very tone deaf of Apple to bend rules like that.
I’m not supposed to share details, but at this point I don’t even care about being disqualified from the bounty program. I submitted two sandbox escapes, for a $25k payout each. Additionally I wanted to donate my payout to charity, which made me elegible for a match.
It’s been now 2 years of silence from them, but I did recently hear that supposedly they took my decision to donate to @MAPS as a “joke” and seemingly they’re unwilling to donate to them. I think it’s despicable and the bounty program can die in a fire as far as I’m concerned.
Jeff Johnson:
Yesterday I wrote a blog post about how Apple Product Security has failed to credit me for my previous discovery of another hole in Mojave’s privacy protections. Later that day, Apple updated their support article online. The article now credits me, but unfortunately it credits me for the wrong bug. Perhaps the update was a rush job in response to my blog post, who knows.
Update (2019-02-18): Jeff Johnson:
I finally got proper credit from Apple Product Security for the Mojave privacy protections bypass that was fixed in macOS 10.14.1 back on October 30, 2018.
Update (2019-03-04): Linus Henze:
I’ve decided to submit my keychain exploit to @Apple, even though they did not react, as it is very critical and because the security of macOS users is important to me. I’ve sent them the full details including a patch. For free of course.
Update (2019-06-03): Linus Henze:
Hopefully you all updated your Macs to the latest macOS version, because as promised in my talk at #OBTS, KeySteal is now available on Github.
Please, only use this exploit for educational purposes. Don’t be evil!
Apple Security Bounty Bug Exploit Keychain Mac macOS 10.14 Mojave Privacy
Juli Clover (Hacker News):
In the release notes for Safari 12.1, the new version of Apple’s browser installed in iOS 12.2, Apple says that it is removing support for the “Do Not Track” feature, which is now outdated.
[…]
The same feature was also removed from Safari Technology Preview today, Apple’s experimental macOS browser, and it is not present in the macOS 10.14.4 betas. According to Apple, Do Not Track is “expired” and support is being eliminated to prevent its use as, ironically, a fingerprinting variable for tracking purposes.
Kaelan the Tired:
The problem with it was that it all hinged on the option being disabled by default, so that only the rare unicorns who actually knew about it and wanted it would turn it on. Microsoft made the infuriating decision to blatantly violate this delicate contract by making Do Not Track enabled by default in Internet Explorer. So all that could happen from there was for the whole thing to come tumbling down. I vaguely remember some website trying to create a compromise where they would still honor the header if it came from a non-Microsoft browser, but I guess that kind of duct tape over the mess wasn’t sustainable. Advertisers were spooked and it all ended sadly-ever-after.
Previously: Intelligent Tracking Prevention 2.0.
Update (2019-02-11): Marco Arment:
The Do Not Track header trusted ad-tech to follow users’ preferences, getting less data and making less money.
But ad-tech can NEVER be trusted. It fundamentally violates trust for profit.
Our only option is to constantly fight it with countermeasures.
Advertising iOS iOS 12 Mac macOS 10.14 Mojave Privacy Safari Web
Ben Cohen:
My talk from Functional Swift Conf about some of the performance challenges with Collections of Copy-on-Write types, and how we’ve fixed this in the standard library in Swift 5.
Ben Cohen:
Here’s the code for Dictionary’s subscript _modify
What Dictionary does is find the key, then move the corresponding value out of its buffer temporarily into an optional it then yields. This leaves an uninitialized hole in the buffer memory – but that’s fine, because subscript call keeps exclusive access to that memory.
The caller can then modify that optional in-place, and the value inside it remains uniquely referenced. Then the caller returns from the yield, and dictionary can move the element back into its storage before returning.
This is using unsafe operations under the hood (to move the memory out of the buffer) but only the bottom layer needs to do this. You can then layer more yielding subscripts on top of it (as Dictionary does here – the unsafe stuff is isolated in _NativeDictionary).
And the unsafe ops are all regular std lib operations using UnsafeMutablePointer. No scary builtins involving pinning memory in place.
Previously:
Automatic Reference Counting (ARC) Language Design Memory Management Optimization Programming Swift Programming Language
