List of APIs that require declared reasons
developer.apple.com
developer.apple.com
App Store to require developers to describe why their apps use certain APIs - https://9to5mac.com/2023/07/27/app-store-describe-app-api/
Apple cracking down on 'fingerprinting' with new App Store API rules - https://www.engadget.com/apple-cracking-down-on-fingerprinti...
(via https://news.ycombinator.com/item?id=36905295, but we merged that thread hither)
After I put in the VIN of the car, I received an error, and inexplicably I was banned from the app. No notification as to why, no "we don't accept rebuilt title vehicles," nothing. Naturally I scoffed, deleted the app and forgot about it.
Last year a friend rented a few cars on Turo for a trip and added me as a driver to one of them. I had switched phone numbers but kept the same phone. I downloaded Turo again and signed up with a new phone number and new email.
Before Turo even asked for my driver's license information, I was blocked again. It must be due to fingerprinting, which persisted over years.
I'm unsure how much apps can learn about your user profile, other apps you have installed, and other uniquely identifiable data. I've assumed it was limited, but perhaps I've been naive.
I guess these new rules are generally good? But I can imagine for every nefarious usage of these APIs, there can be a plausible cover reason...
https://developer.apple.com/documentation/devicecheck/access...
That makes some people feel really secure, like the company is a loving parent, although companies don't love. They decide what is profitable and what is not.
This isn't a feature that is actually costing them sales but a lack of DRM/etc affects what apps will be in their store.
Service providers need to ban people sometimes. This includes people who are savvy enough to know how to delete and reinstall an app to clear its settings. Never permanently banning anyone simply isn't a thing that's happening.
If Apple didn't provide DeviceCheck, or something similar to it, service providers would use some other means of deterring abuse. There's a couple directions they can go in, but they're all generally worse for users (e.g. using invasive tracking, requiring users to pay for service, etc). DeviceCheck is about the least invasive way I can imagine this being implemented.
Does resetting your iPhone (Erase All Content and Settings) clear out data like that?
Does doing a restore from backup put that data back on your iPhone?
I.e. they could persist even if the device were bit-for-bit reset to factory state.
I’ve had a few apps I’ve redownloaded months later, the only one from the developer, and my auth state was preserved.
I keep hearing that the Keychain data should be deleted, but my iCloud Keychain is filled with long-dead data
I have a specific debug setting to wipe the keychain.
Sign in with Apple also generates a persistent ID with each app. That could be used to fingerprint the user, but not the device.
After some iOS release though, every app started doing "new phone, who dis" regardless of the restoration strategy, so I stopped wasting my time.
At one point, google authenticator started marking its entries as "this device only". I don't know if they've backed off on that since then.
Apple needs to get their shit together with these two APIs.
Great! I just hope the same will be introduced on Android. From the very beginning of the smartphones history, I immediately noticed apps put pointless requirements to be given permission for everything and I wanted such a policy to exist. No permission besides those strictly necessary to fulfill the very function of the app should ever be given or even asked for.
Nevertheless I'm afraid such clauses increase the power of the vendors like Apple to fight the apps which do whatever they hate even if that is what the user wants.
Unfortunately, there isn't a way provided to the average user to say that an app can use Bluetooth, but not GPS.
https://developer.android.com/about/versions/marshmallow/and...
To that last point, I am curious: is there any good comprehensive open sourced and audited alternatives to eg Tile or Find My?
I am indeed surprised by that. I would have expected the location permission to just control whether or not the app can use the system's location APIs or access GPS (if the system provides low level access to the GPS that doesn't require going through the location APIs).
Having it control access to something that is not specifically a location service but that might sometimes be usable to obtain information that can be used to figure out location does not seem wise to me, because all kinds of things that you might not expect to provide such information do. For example internet access can provide location information indirectly via IP geolocation.
If they try to stop all of that through the location permission then a bazillion apps that the user does not think of as having anything to do with location would have to require location permission, and users would learn that if an app asks for that they have to give it to them.
Using Bluetooth beacons you can get the location of a user accurate to a couple of meters, possibly granular enough to identify the individual. Continuous tracking can track your movements with the same scale. IP geolocation will at best be a radius of multiple kilometers. There's a big difference between "I know where you're standing at this second" and "I can guess what part of the country you're in".
They are actively hostile to user control.
These lines are wild. Android has great privacy controls and has had them as long or longer than Apple has.
Android gives 0 permissions by default in an app. Android requires 1 by 1 permission granting following a standard of least-required. Android's default permission selection is "Only this time" and not "Forever", meaning most users only grant temporary permission to the app. Android then automatically removes "forever" permissions that are unused after a period of 30-90 days without user input. Android is so aggressive about it that most "background" apps (widgets/battery monitors/weather) silently stop working as Google ruthlessly rips permissions away.
Heck -- unlike Apple, Google distributes nearly all of their apps and even system components through the App Store and still relies on standard user permissioning! You still have to grant Google the same permissions you grant any other app, even though it's "OS level". Imagine Apple authentically asking you for permission when you open a first party app and respecting it!
It's basically impossible to have an app use a permission you didn't know about on Android these days.
And in light of the great reality we live in, you have some crazy Apple stans in here saying "Google is actively hostile to user control". That line is wild considering almost every major iOS UX or hardware enhancement was ripped straight from an Android device that debuted it years prior... Between Apple and Google, there is no argument that Apple is the most hostile device company to "user control" in history. That's their thing! There's one way to do it, the Apple way, and if you want to customize it differently, you're the problem! ("Hostile to user control")
> Android has great privacy controls and has had them as long or longer than Apple has.
These can both be true. Android can have great privacy & permission controls, and also be better at many of these things than Apple, and also have systematically cut back on users control of their own devices, time and time again (Android 7 making it impossible to manage your own CA certificates, Android 14 tightening that further, sideloading restrictions, SafetyNet/Play Integrity making custom OSs & rooting unusable, etc).
There's a lot more to user control of devices than just app permissions, and "Better than Apple" on this stuff is not a high bar.
I don't remember the Maps app asking for permission to get my location or the Contacts app asking for permission to read my contacts. They do this?
That's clearly the big difference between both. Who knows what the internal apps are using on iOS, certainly not anything standard. That's also why it's usually the first attack vector on zero days.
Targeting NicheApp275 is not going to target as many ppl
https://www.securityweek.com/android-security-updates-patche...
I really liked the xprivacy concept and it should be extended to full scripts.
Sure there's security issues with this concept but it's so powerful that it's worth it.
The biggest recent pain point that comes to mind is cracking down on accessing the pasteboard without prompting the user for access first. The pasteboard was an essential piece for enabling seamless universal links in many apps. Universal links allow us to give our users the best possible first impression and make things easy for them. Mind you, most users _need_ to be guided along most experiences, don't read things, and blame you for when they can't read. At some point the value prop of apps is going to be completely negated by how difficult they are to use.
People just want privacy. App developers are not entitled to every piece of information on a user. If I have sensitive information in my pasteboard, you're not entitled to it. I just want an app to serve a singular purpose then I want to close it and go about my day. I don't need an app to glean my personal info in order to show me ads.
Apple has turned popular opinion against startups and the little guy so much that we're saying these things out loud to one another. Seriously?
Apple has too much power. Just like Google on the web.
Dealing with a little more pain and friction from marketing, in exchange for freedom for our devices and a healthy distribution of power, would be worth it.
We're being told to be afraid of "marketers", when we're actively being put into computing straightjackets by the biggest thugs of them all. Every move these gigantic companies make is to make you further reliant upon them.
We're moving to a world where Apple and Google decide who can execute what, and where there is no hope of leaving. And that's terrifying.
As to the rest of your post: the app developer in this thread is saying Apple should give him and his friendos special permissions ("trusted certificates") to not ask the user whether the user trusts them, and you're saying it's Apple's decision to require a user to affirmatively consent to having their pasteboard read by an app that is thuggish?
One of these is actually on my side as a user, and it's not the marketer and it's not you.
But trying to deter such app developer to gather as much PI as possible is even better as it is preventive.
This is like chrome saying you can’t go to anything other than the root path of a site the first time you go there.
I don’t want a direct relationship with developers. I don’t want to go to their website to subscribe or to cancel my subscription and I don’t want to give them my credit card information.
I want to be able to use “Sign in with Apple” and not give them my real email address.
Diligently creating a business which turns a healthy profit for a fair exchange with the customer is less profitable than developing a large customer base that could be sold to someone.
Say what you will about the big players... there is no exit strategy. They are in the endgame.
Unless this is a reference to the fact we are having the conversation on the Y Combinator website specifically, it's is a fallacious argument to suppose that the only way any of our current technology could happen through the historical accidents that have occurred.
The nature of complex systems mean that larger systems process more information relevant to their continuance are more successful.
I do agree with the point underlying your rhetorical question. I am just not so certain we should be grateful for naked self interest.
Surely there's a compromise solution here? I don't see why Apple couldn't grant trusted certificates to good actors and revoke certificates from bad actors in regards to pasteboard access?
You already have a compromise: you can, if you insist and if your user consents--not Apple through some "trusted certificate" granting process but the user themselves--choose to not follow standard system flows. Or you can follow standard system flows and receive implicit consent by the user when they click 'Copy' in the share sheet.
Why is seeking consent so terrifying a prospect? And why should anyone privilege "your flows" over that consent?
It's important to note that this is not an issue for apps that are already installed: we get those links and their data; this is just a first-ever launch issue.
We're not afraid of marketers at all. We simply despise them.
The more roadblocks Apple puts between us and the marketers, the better it is. You have no right for our eyeballs.
People were spoiled on the old Internet, like pre-2010, where a simple adblocker meant you could just see all content, ad-free, with virtually no paywalls. It seems like because that’s changed now, they feel they have been robbed of their birthright.
If you don't trust me, just look at the web. How it lost the cache for static asset; visited link css; popup window, etc
By “start up” and “little guy” you of course are referring to complete strangers with close to zero reputational risk at stake who are handling my private data? Those people?
Apple had nothing to do with my distrust. Plenty of bad actors just like them have done that all on their own.
Otherwise, accessing UIPasteboard should require permissions. Sorry for Your Flow, but like--the app needs to be transparent about what it's doing, and dirtbags exist, so.
I want my tech-averse relatives to bail out of an app when they see that unless they're hand-held through it and the reasoning is made sufficiently apparent that they can parse it. If they can't, it's not clear enough, and they (and the OS) should default to no.
There has to be a common sense compromise on this, like a revokable certificate for access without a prompt.
I completely reject your whole premise.
No, you're not. And that's good. It's a bad pattern! It's a bad pattern whether one app or a million use it.
> There has to be a common sense compromise on this, like a revokable certificate for access without a prompt.
You seem to think this is the extreme position, and it's not. The extreme position is "you cannot access the pasteboard directly, at all, under any circumstances, and only user-triggered actions through OS-served and unintermediated controls can do so."
You have your compromise already: "ask for permission and be sufficiently clear about why you want it to get people to say yes".
> I completely reject your whole premise.
That's fine. Apple doesn't. That's why I like them. You started this thread with what sounded like a reasonable objection, but you've kept digging to the point where it sounds like you're kind of the reason they're doing it.
It doesn't seem like they do believe that, and even if they did, that's not the point.
The point is that allowing this access without explicit user consent enables various "scummy things" that neither Apple nor the user can then stop or easily detect.
It's really not that different from the person at the bank saying, "But you know it's me! Why can't you give me all my money without seeing my ID??!"
As a developer, I sympathize with you, but as a user, you can get bent. I appreciate that Apple makes it difficult for you to use potentially dangerous APIs with large risk surfaces, and forces you to ask me for permission to take that risk. It's why I continue to buy Apple products and will never switch to Android as long as it's owned by a user-hostile advertising company.
No, I don't give a shit about your "seamless experience".
> No, I don't give a shit about your "seamless experience".
Is way more respectful than the situation calls for.
The pasteboard is critical to protect from bad actors.
If your mobile apps don't make money without invasive ad targeting, that's OK: others clearly can (see the sibling commenter), and we can get by with fewer mobile apps that don't when they are are presenting so thin a value proposition as to be unable to get users to pay for them through conventional means.
The "hard men / strong times" line in your profile (which, to be candid, is a pretty gross pretext for a lot of bad-actor politics, but you picked it not me) echoes deep here: there are plenty of endeavors that sell something people want enough to pay actual money for them, and you can always do that instead. I haven't worked for an ad-supported tech business since my first job out of college in 2010, and most of their business was actually in air travel and hotel bookings, the ads were tertiary. The jobs and the products exist.
Let's unleash the hot take cannon for a second: users basically don't need apps. Businesses do--and there's a ton of money in LOB mobile apps even--but almost every B2C mobile application I can think of is some form of luxury good. Making the case for a luxury good is harder than making one for one of self-evident value. Congratulations--you picked hard mode, and nobody is obligated to make it easier.
Optimize for making value to people who will pay for it, not virality or shareability, and perhaps you have a path to not needing to play with edgy patterns.
What value, in a sane system, does selling advertising that targets people who "can't even afford decent housing or food" actually do? How are the goods you are selling--human attention--actually turning into revenue for the advertiser if the user has no money to act on the advertising? Or is it just one more iteration on a mutual deception that exists to create a predicate for "any of these mobile apps are worth creating in the first place"?
You're building a bigger house of cards with every post.
In fact, the more desperate, the more willing they’d be to click on an ad, which gives a perverse incentive to advertisers and developers to worsen their financial position.
But please, show me examples of these good targeted ads because while in theory they could exist, something tells me they very much don’t.
The median iPhone user in the US is making $53K a year (https://www.marketingdive.com/news/survey-iphone-owners-spen...).
And most people in the US are neither starving or homeless.
“Sensor Tower data reveals that U.S. iPhone users spent an average of $138 on apps in 2020, up 38% from 2019.”
This, not simply "doesn't have money", is the thing about mobile apps that it feels like most people in that most things a user wants to do on a phone don't actually need an app, and if they do it's probably because they're buying something or talking to somebody and neither of those are categories that need more entries with a lower security barrier.
[1] https://racketmn.com/rackets-year-in-review-august-2022-july...
Journalism is evolving and changing, but it isn't dying or going away. Hyper-targeted ads will not "save journalism".
App Store developers generated $1.1 trillion in total billings and sales in the App Store ecosystem in 2022.
Small developers on the App Store grew revenue by 71 percent over the past two years.
People are absolutely willing to pay for apps and in-app purchases.
I was already starting to think you're full of it from your responses to other posters, but now I'm sure of it.
That does not track with my experience at all. Ad prevalence has only increased over time.
That's hardly unique to this site, and hardly as recent as 2016.
I would say that we can trace people with an understanding of technology being anti-ad back to at least 1989: https://en.wikipedia.org/wiki/Adbusters?useskin=vector
This isn't a problem after the first launch, as the app delegate gets an event to open and route the user from the URL.
It’s there for people like you and me who want to change it. It’s buried enough that my older family members aren’t likely to do it on a whim, which is good.
It includes file time stamps, system boot time, disk space, active keyboard, and user defaults.
In each case, it says which specific APIs will be checked and what are allowed and disallowed reasons for apps to use them.
UserDefaults... really?
Let's give Google more control over the web so they can finally the destroy it in the same way and there can no longer be anything for me to care about.
UserDefaults is also app-scoped so I'm not sure I understand the reason for this as a privacy concern.
"This API has the potential of being misused to access device signals to try to identify the device or user, also known as fingerprinting."
The reason is because UserDefaults is device scoped. Even within the context of a single application, the developer could use the API to build a list of user devices and identify the particular device the user is accessing the application from. Absurd? Perhaps. But it falls within the definition of what they are aiming to eliminate.
[1] https://developer.apple.com/documentation/foundation/userdef...
(1) Nearly every app in the App Store uses UserDefaults. It's such a basic, fundamental API.
(2) App Store apps are sandboxed, so they cannot access the UserDefaults of another app.
(3) UserDefaults is more or less glorified key-value storage. It's true that you could store a UUID in there, but you could just as easily store a UUID in a text file in your app's container, an API usage that is not covered by this.
(4) According to the docs, there's only one allowed "reason":
> CA92.1
> Declare this reason to access user defaults to read and write information that is only accessible to the app itself.
> This reason does not permit reading information that was written by other apps or the system, or writing information that can be accessed by other apps.
But again, as I said in (2), "reading information that was written by other apps or the system, or writing information that can be accessed by other apps" is not even possible for sandboxed apps.
In other words, almost every app in the App Store will have to declare "CA92.1" in a privacy manifest, and if every app has the same response, then nothing is accomplished except privacy theater and some unjustified good PR for Apple.
I disagree. It gives Apple a tool to refer to when an app says A but does B. If you are a malicious app and you lie about any of these things then kicking you off the App Store is a simple decision.
In the past you could get away with just doing it in code. Now you have to declare that your usage is non malicious. That is a huge difference.
That's not even what you're declaring! I already quoted Apple's docs: "Declare this reason to access user defaults to read and write information that is only accessible to the app itself."
But sandboxing already makes this impossible, so the only thing you're declaring is that your app only does what the operating system allows it to do. Nothing about maliciousness or fingerprinting.
Moreover, the only way that Apple can actually detect fingerprinting is to reverse engineer the app, which Apple could do anyway regardless of whether developers self-report. Self-reporting is basically useless, because violators will simply lie.
Apple can already kick you out of the App Store for any reason, or no reason. And they could make a public rule against fingerprinting without requiring developer self-reporting, which is mostly a sham.
The Keychain persists between installs, so you can just add the fingerprinting data there instead.
Also, I guess you could write some values into UserDefaults to uniquely identify users.
I already said this: "UserDefaults is more or less glorified key-value storage. It's true that you could store a UUID in there, but you could just as easily store a UUID in a text file in your app's container, an API usage that is not covered by this."
[1] https://developer.apple.com/documentation/foundation/nsubiqu...
There is no magic here. I see a lot of complaining here but for 99.9% of devs it is a one time two minute check mark exercise.
For devs, is Apple going to now audit your `UserDefaults` usage and deny an app update because you forgot to enumerate that you _also_ store preferred start page in your new release? Why even add this mental energy to the process unnecessarily?
1. https://developer.apple.com/documentation/xcode/configuring-...
> This API has the potential of being misused to access device signals to try to identify the device or user, also known as fingerprinting. Regardless of whether a user gives your app permission to track, fingerprinting is not allowed.
I think this is mostly aimed at MacOS apps, where the scopes are much more relaxed for backwards compatibility reasons? My guess is that iOS apps will be automatically approved.
Onboarding screen? Persist. Saved Token after login? Persist. Save Last selected X? Persist.
If you want to write data without providing a reason, then go do that. Until Apple requires reasons for file writes.
It’s literally a 2 second process, and it’s meant to provide transparency into what the developer is doing. That seems entirely beneficial to users. Sorry that being honest and taking a few seconds of your time is such a heavy burden.
What transparency? Almost every app in the App Store uses UserDefaults, and the only allowed reason to use it is, literally, "CA92.1". How is that transparency?
> That seems entirely beneficial to users.
How, exactly?
> Sorry that being honest and taking a few seconds of your time is such a heavy burden.
The dishonest developers will give the exact same "reason" as the honest developers. It's security theater.
That's not how I would characterize it. Per the link above, they've provided a way for developers to declare the reasons their app uses API categories that can be used for fingerprinting.
> Data saved there is already scoped to the app itself, not to other apps or system information
Per the link, it appears that bad actors are somehow using it to violate App Store anti-fingerprinting policies: "This reason does not permit reading information that was written by other apps or the system, or writing information that can be accessed by other apps."
Is that considered fingerprinting? I really don't care who it is, I'm just trying to make sure the features I'm building are actually being used.
With some exceptions (such as social media apps) I don’t think it’s generally first party devs who are doing this, but rather third party SDKs that are popular with devs, e.g. Google Analytics, Firebase, Facebook SDK, etc.
To help this along the app can do things like kick the user out to their main browser to do some routine thing, where cookies can be accessed. The user doesn’t need to deep link back to the app in that case, the app can pull down whatever tracking info was harvested during the page visit and persist it.
The author of Overcast, Marco Arment, did that specifically so he wouldn’t have to store usernames, passwords and emails on his server - increasing privacy.
You can add a username and password to your account if you need to log in to the website. But he really wants to get rid of that requirement too.
I don't think Apple are aiming to change that with this
There is something about the way it’s presented (or maybe a bug in my brain) that keeps reading it as the age of the app.
(And IMHO that would be a lot more useful thing to show in that prominent position too)
It feels that developing apps for Apple is more akin to being an Uber driver where there's very strict guidelines to being an operator. There's zero room to build any platform software [e.g. no side loading, no 3rd party browser engines allowed, no alt payments methods, no emulation, no platform mods, etc].
Also, if you are pushing some kind of software to a platform you are beholden to the platform. This has been argued to the beginning where software repositories run by corporations can get you kicked off of it. All of what you are saying in the second paragraph have been rules for a long time on the App Store and it is the most lucrative for the App Store to develop for which supports developers . If you want to do what you want using android is an alternative but then you have to remove the shovelware or buy a Pixel. Also the google Play store has less to offer and isn’t well policed since the App Store is more lucrative with more rules.
I don’t agree with this. Google is implementing many restrictions, checks and rules too. Just like Apple. Their play store rules are equally comprehensive.
It is true that Google has a different approach to Android APIs and extensibility but they face many of the same problems as Apple has on their platform and you can see that they react to that every Android release by adding new security and privacy features or policies.
We often have developers complaining about certain restrictions on iOS but never ask if users care? For me a key reason I choose iOS is because of the restrictions given to developers.
Just to be clear I also find myself annoyed at some of the restrictions, like I find it particularly annoying that given all of their talk about the iPad (and Vision Pro) being a computer I will likely never be able to do my job on one since I can't run my own code there.
BUT I don't push too hard for it since I recognize that adding the ability for that opens up other issues that would affect me when just being a normal user.
I am wondering if we will be seeing another situation where certain apps delay updates like with the previous app tracking permissions.
Also curious if they would ever go so far as to add a notice of something like "this app could possibly be fingerprinting you" in the App Store or if they are confident enough in asking about these permissions that they will feel they won't need to alert users.
With the earlier privacy crackdown that upset Facebook and Google so much, it only applied to new and updated apps.
According to people on HN, that's why it took Google months and months to issue an update to its apps, and during that time it continued Hoovering up people's information.
There are lots of apps on the app store that haven't been updated since the last round of privacy rules came out, which tells you a lot about those developers.
It's not a big deal if you're GoogFaceSoft and can throw people at it, but for a solo developer the list of things to deal with is ever increasing.
Feels sadly like Apple don't care much about indie developers anymore.
The beauty of the web still remains that you can launch something to the world in minutes.
They got proven wrong, and had to invent policy after policy to try to fix things. Google has been restricting permissions while Apple has gone even further.
Most developers don't need all that much special treatment. Picking between three codes in a few categories isn't really that much work. At least they don't require you to manually email the app reviewers!
This stuff only seems to be a major issue for developers trying to use APIs in way Apple does not allow them to be used.
True, but it's not just that. These changes are just another item to add to the already very long checklist.
I'd much rather they add to the App Store ToS "I will not use the following APIs/syscalls for fingerprinting users: [stat, UserDefaults, etc...]" rather than all this busywork. Since these restrictions are enforced by the review team (vs. the OS), the end result is the same.
So if they implement policies that increase the average quality of apps and decrease the total quantity, that's an improvement for users twice over.
By that same token a public CloudKit implementation should need a reason as well?
V confused.
You can't, because App Store apps are sandboxed.
> V confused.
M too.
I love/use them very much, but we really should stop being so naive, it only takes a single bad apple..
At least that's what I used to hear all the time. We've now seen that was hogwash.
Linux will let you have the most locked down box in the world if you want.
Linux sandboxing scene is completely broken for end-user usage, it’s only good for CICD pipelines. If I want to open a file with a program, I don’t want to see an empty drive, neither do I want to kill the program - there should be a proper interaction between the user and the program, like mobile OSs do. Flatpak does have something like that, but only for files and not even that is seamless (plus flatpaks mix packaging with security for no good reason, imo).
You literally run basically everything as the same user, every document, family photo is saved, and thus available for r/w by any process, as those share the exact same privilege. This includes that npm install with millions of dependencies as well, that could literally install a screensharing malware with clear access to any internet site and you wouldn’t even notice.
The age-old xkcd is still true: the only thing secured is being able to install a video driver.
Or I just run it in docker and only mount what I want. No VM overhead since cgroups are native.
"I don't want to make that decision! I want total privacy!" - Great, use Tails which is a distro that goes all in on privacy.
Regarding AppArmor, how do you write a policy that would allow a text editor to open only files that user has chosen in Open dialog?
In this case we can say that Windows is also absolutely secure - you can just write a kernel driver that would protect sensitive data from applications.
Your distro already has AppArmor files for your distro software.
You can also kick it into learning mode if you desire.
You could also just stick to flatpaks/snaps - totally sandboxed.
You could choose Whonix where every app is an isolated VM.
Or choose tails where any egress is locked down and monitored.
I don't know, Apple is trying to stop bad actors from fingerprinting users and violating privacy etc. Or maybe you're into that?
I also have to pay apple £80 for the privilege of having my app available for free on their platform.
I would just like to be able to provide users a file and say "here you go, install this" so I don't have to pay apple to bless my software.
Meanwhile, from just today: https://arstechnica.com/security/2023/07/android-malware-use...
They may also install porn, gambling, lgbtq apps or whatever else you don't approve of.
Apple lets the CCP access Chinese iCloud data. They takedown dissodent apps in foreign countries. They block perfectly legal non-malware apps.
Though I do note that one of these apps was on the curated store anyway!
With them being forced to allow for 3rd party app stores, they will go all in on trying to convince people that their App Store is the one for privacy and safety and that people are risking their privacy and safety by installing another App Store.
By having to compete against other potential app stores, they are incentivized to lean in further into privacy to set themselves apart.
- File timestamp
- System boot time
- Disk space
- Active Keyboard
- User Defaults
Makes sense but I imagine some of them will also be very annoying, it depends how strict Apple are about giving permission. If you have to maintain a separate record of file change time stamps for example that’s going to get pretty tiring.
I predict a flood of app rejections due to developers unknowingly using these APIs as part of a dependency.
Things like stat() are so fundamental that you'll pretty much always find them somewhere in a moderately sized code base.
But free space (if being used for caching purposes): Why not just try to save to .cachesDirectory? If there’s no space the file save will fail, which is fine, your app should handle that anyways. If there’s low but sufficient space that fine, the OS will evict the file soon enough.
For free space, it's pretty common for iOS apps to restrict functionality when your device is critically low on space -- because having most disk writes fail can be very difficult to handle.
You also might want to implement a cache policy that's "greedier" when there's plenty of free space. I think there are plenty of reasons to want to know how much free space is available.
I feel like offering lower fidelity values may be a better of handling these privacy concerns rather than adding further complexity to the already onerous app review process.
For example, for files your app doesn't own, round timestamps to the nearest second, and free space to the nearest 100mb. Most legit use-cases won't need more than this level of fidelity.
Mark my words, this goes two ways: 1. Apple rolls it back, devs feel like they have power, Apple does security/Dev theater over the whole ordeal. 2. Massive App store review issues for 99% of apps on the store.
From "just get an android" in response to someone complaining about having to pay $100/yr to publish a FOSS app on the App Store to "I take it you don't use apple products" or "That's all going to the government! I ain't gonna use that!" when someone only mentioned not setting up Touch ID or Face ID.
Maybe read, think, and then don't reply with snark.
While I do agree with this change, this restriction also clearly serves to further entrench Apple to be the gatekeeper over users. They can fingerprint you, they can serve ads to you, but oh anyone else no no no, that's evil and against your privacy™
That could change at the drop of a hat and a change in their TOS though, so it's best to be ever vigilant.
ok...
While you should never trust any corporation in the sense that you might trust a person, you can trust that they will do the things that they believe will make them the most money.
What financial incentive do you believe that apple has to steal your fingerprints?
Read up on things before you shit on them or you'll look like an idiot.
Of course, the make command must be spying on you. rsync. cp. tar. find.
"I need to see if this inode has S_ISDIR set, so I can walk the directory tree." "How dare you invade the user's PRIVACY!"
I can't see why anyone would willingly choose an "app" when they can still run normal software on macos.
Apple isn’t banning the use of these APIs. It just requires you as a developer to actually be transparent and honest about the things that could potentially fingerprint a user.
To make that sound like a bad thing because you’re lightly inconvenienced is an interesting take.
I think Apple's an awful company slowly enclosing the commons that is general purpose computing, so that it make phat bank by forcing itself as a middleman between anyone who uses their hardware and anyone who writes software for those people. I don't encourage anyone to use Apple products so I write software that can be used on almost any platform, but can also be used on Apple if you compile it correctly. Hence why stat() piques my interest, and some obj-c/swift nonsense does not. I resent any further restrictions on distribution or usage.
I should not have to justify myself or my code to Apple. I should have to justify myself to the users that be run it, and the user should have all the tools necessary to see what I'm doing in my code (e.g. wouldn't it be nice if macos hadn't crippled dtruss by default)
I don't think it's a light inconveniencing. I think it's further encroachment on the freedom to run any software on your computer for any purpose, being done to privately enrich Apple, under the marketing guise of benefit to their users.
People are much more likely to just self-fingerprint themselves.
Anything else is bound to not be in the users interest.