Soon we’ll need permission from the customer to access NSUserDefaults, file modification dates and disk usage. After all, it isn’t bug fixes that we want from Apple, it’s more “Allow” or “Deny” dialogs, obviously!
Back then was already nonsense, mac asked for the password on pretty much the same system changes than windows asked for an “Allow”
And now…
1 Like
I can’t wait for the day where we’ll have to give permission to move the mouse…
Reaching the “Allow” button won’t be that easy 
.
1 Like
Isn’t this in reaction to changes in the legal landscape, like GDPR, and the existence of data-slurping apps like Facebook?
Nope the GDPR has nothing to do with this…
Definiton of Trust… a personal believe in correctness of something. it is a deep conviction of truth and rightness and cannot be enforced. If you gain someones trust you have established an interpersonal relationship based on communication, shared values and experiences. Trust always depends on mutuality.
Apple (like MS and Google before) does not give the user full control anymore. Basically they decide what is trustworthy and what not. They decide what to run, when and where and they decide what not to run anymore when they see fit.
Hence, there is the misconception of trust. If they don’t trust you, the user… why you should trust them?
This Video is old but still valid
Use free (GNU/Linux) operating systems and software…
1 Like
We at APPLE respect your privacy, however we will soon be demanding to know why any/everything is being done with the data on your devices… Thank you and have a nice day
1 Like
This isn’t exactly correct.
First of all, macOS is not included. From the first paragraph of the linked document:
Describe the reasons your app or third-party SDK on iOS, iPadOS, tvOS, visionOS, or watchOS uses these APIs
That doesn’t mean macOS might not come later, but it’s not happening right now.
Also, I believe this is not related to more allow/deny prompts, but the app store’s privacy labels. If you look at the rest of the stuff in the privacy manifests, there is a LOT there that we don’t get prompted for: Describing data use in privacy manifests | Apple Developer Documentation
So this sounds worse than it is.
2 Likes
If I think of my mom it would make sense to add another few thousands popups asking if the user really wants to do this and that. Moving her to macOS was a good move a decade ago and I appreciated since then many things Apple introduced afterwards :-). All their “enhancements” are fine with me while supporting my mom though I don’t like those changes personally.
That’s probably the missing part. A functionality to disable all those security and privacy popups if you think you are a pro. A bit like in Linux. “You really think it is a good idea to work as root?” - “Sure, here you go - have fun but don’t complain!” 
The problem with that is the option to skip warnings is usually enabled by non-pros, then complain when they shoot themselves in the foot.
But again, this doesn’t look like it adds any new prompts.
3 Likes
exactly!
Annoying users with zillions of prompts is what gets everyone to turn this shit off
But Security !
1 Like
On of the APIs mentioned was USER DEFAULTS… and I thought… “Huh, how can that be a security issue?”, But I discovered where Apple is probably coming from
extension UserDefaults {
static let group = UserDefaults(suiteName: "group.your.identifier")
}
You can now access the shared group container anywhere by making use of the static property:
UserDefaults.group.set(["AAPL", "TSLA"], forKey: "favorite-stocks")
However, if this is the case, don’t require permissions at the TOP of this API,but only if “group” is used, as I would be that 99% of developers use this ONLY to store local app preferences.
Sandboxed apps require an entitlement to access other apps prefs or shared prefs, which on iDevices can be rejected from the store for trying to access other apps data.
The more I think about this, it is either a marketing stunt or I am seriously misunderstanding something.
It’s weird. I think the label for preferences is because you could store a uuid there and use it for tracking. But if I were trying to be sneaky, I’d just store that in a file in my app’s container. So what’s really the point?
I’m not even sure these new privacy labels are even seen by the user. It sounds like app reviewers will read them to make sure usage of preferences and file metadata is justified.
2 Likes
I posted on Twitter and got some useful information
Just read an article on The Register (Apple demands app devs explain the use of sensitive APIs • The Register) and it appears this is about preventing fingerprinting.
I can see how if two apps are on the same machine, both could create a fingerprint using the same details, like storage size, screen size, OS versions, how the user has their user defaults setup etc. Given enough data points, it would be really easy to get a unique ID out of it. Each app collects a little data about its user to be able to operate, but nothing that is too intrusive. If those two apps then send that fingerprint back to a server where it’s all collated together, all the little bits of data each app has can easily be amalgamated to form a very good picture of a particular user. I can see this becoming an issue if a lot of apps start using the same fingerprinting framework.
It seems that fingerprinting is becoming more and more common now as things like cross-site cookies are being blocked by default. The marketeers are desperate to find ways to link data to a specific user and a specific device.
So it appears that Apple is making it against policy to share a fingerprint of a device. Disallowing access to device information and user defaults unless you can explain exactly why you need it is a step in accomplishing this.
2 Likes
I still don’t see it based upon these details. How many devices have 128 GB of storage? User Defaults?, the apps can only see the data that the app puts in there (App Sandbox). The apps can’t access system files, so the only files it can get the modification date are from it’s own files or files it’s created on behalf of the user. As for availableCapacity of a volume, that thing fluctuates like crazy with modern versions of Apple’s OS, especially with Apple’s memory management, purgable space and there is no guarantee that it is going to be correct, I’ve highlighted a bug in Ventura where the macOS cannot even correctly calculate the size of a folder.
At the moment, it still smells like a marketing, more than anything actually beneficial.
Who? Apple? No waaayy. /s
1 Like
Okay.
So its not marketing. It is shocking real. I have seen information captured via NSUserDefaults on iOS. There is far more personal data there than even a un-sandboxed Mac App has access to.
Its actually a bit scary. My guess is at somepoint, Apple decided to use NSUserDefault on iOS like they do with the IORegistry, and now it would take a massive engineering effort to “fix” that.
I wouldn’t be surprised if you are correct to a degree, Apple will never miss a marketing opportunity. However, I’d also not underestimate how crafty these trackers can be.
I once had a client who contracted an analytics expert to help with his online store. The demographic data, and sometimes directly identifiable data he could tell you about the people who were visiting the website was incredible, even those who just browsed and didn’t purchase. That was several years ago and things have been tightened since then, but those tracking SDKs are always looking for ways to maintain that level of data.
Even things like what fonts you have installed on your device can be enough to uniquely identify you. When I visit My Fingerprint- Am I Unique ? the list of fonts on my machine is 100% unique out of all the visitors they have had. All trackers need however is an 80%(ish) uniqueness, because they will then pull together lots and lots of 80% uniquenesses. If they can find something that links several data sources that are fairly unique, collectively they become very unique. The one time I had a peep behind the analytics curtain, I was shocked at the tricks they were using and how effective they are.
I think this is more targeted at tracking SDKs like Firebase or Google Analytics. SDKs like Google Analytics have all sorts of data streams from all sorts of sources. It doesn’t take much to pull it all together and create data sets with user identifiable data. Search Google whilst logged into a Gmail account, Google knows what you searched for. Then visit a website that uses Google Analytics, Google can attach that website visit to your Gmail account. Click a link that opens an app on your phone, if that app also uses Google Analytics and the link passes tracking data, that app can now also know who you are, even if you haven’t logged into it. Then any interactions with that app can be tracked against you personally, even though you haven’t signed up for anything. Obviously there are laws around this, and Google isn’t sharing a lot of these linked data set with it’s clients, but Google itself is easily able to identify what you do and that extends to places that may surprise you (like apps on your phone).
I guess the UserDefaults stuff is because these SDKs will draw down data from servers and persist them to UserDefaults. So tracking data can flow into the app via deep links and out of it again if it has embedded browsers or outgoing links (or even just via the analytics SDK used). All of that tracking data will be persisted to UserDefaults and be shuttled around between the app and analytics servers. All it takes is for one small bit of data to link two data sets and suddenly you have a very clear fingerprint of who you are and the device you use.
From what they say in the documentation, it seems Apple is specifically preventing the use of UserDefaults for storing any tracking or fingerprinting data. I guess they’ll keep a close eye on what these analytics SDKs are doing and start rejecting apps that use SDKs they know are storing fingerprinting data that has no other use within the app. I’m not sure how they can prevent an app from just saving an encrypted text file on the device though.
I agree it’s annoying, but I think it’s targeted at these trackers, which are incredibly insidious. I doubt they will pay much attention to individual developers. It’s likely they wouldn’t do this unless it’s been spotted in the wild somewhere.