I’m all for the “fake data” idea, but also: Apps should be required to gracefully handle the cases where users deny permission to access real data. I know last time I developed for iOS, it was Apple’s policy that apps cannot punish users or exit() the app in retaliation for them denying a permission. Apps must gracefully handle it and continue running.
Also, and this was even longer ago, apps could not require users to have “an account” in order to run. I remember (this was over a decade ago) my company making a product change that forced users to have an account in order to function and we got (rightfully) rejected by the AppStore for this. It seems they must have softened this stance because I am seeing more and more apps that require an account to function.
> apps could not require users to have “an account” in order to run
There is some big qualification missing or I don't understand what does that even mean. How could a banking app run without an account? An online game? The Twitter app nowadays? Dropbox/Nextcloud/...? Etc.
Yeah, I agree that for a lot of apps, requiring a account is just a marketing gimmick, but I don't think such a general rule could work.
Good question! We actually asked Apple exactly this when appealing the AppStore de-listing. How come others can require an account and we can't? What was it about our app that made us have to spend the engineering effort to add a guest login (this was a disingenuous argument that I advised against, since we deliberately spent engineering effort to require the login)?
Their response, not the exact wording since it was over a decade ago, was along the lines of: "1. We're reviewing your app, not theirs, so what they can do is irrelevant. 2. Your app core use case clearly functions without an account as evidenced by the previous versions having full functionality not requiring an account."
1. Is a standard Apple reply when you compare your app's treatment to others'. Everyone gets this when they bring another developer's app into the argument.
2. Called our bluff and is pretty hard to argue against unless we changed something core to our backend such that it now requires an account. Even if that was the case, I would expect Apple's response to be "change it back".
Throughout the whole exchange with Apple, I had to be Devil's Advocate, since I advised against the change to require an account from the start, being apparently the only person in the company who had actually read the AppStore guidelines. Nobody listened to me, of course.
Being the voice of "this is never, ever going to be accepted into the AppStore, it is a perfect example of what you can't do" can be a very lonely journey.
as long as you aren't the person who will ultimately pay for said failure, it doesn't matter if nobody listened to you. You just need the cover-your-ass evidence that you presented this evidence to the stakeholder (who is ultimately responsible for said failure).
> We're reviewing your app, not theirs, so what they can do is irrelevant
rules for thee but not for me
Apple has never been fair with its review, sadly.
> I would expect Apple's response to be "change it back".
Companies should not have to bend over to apple's whims just to get their software in end user hands. Hopefully upcoming EU regulation will reign apple's overreach in a bit.
"not for me" isn't what's happening in a comparison between two third party apps.
> Companies should not have to bend over to apple's whims just to get their software in end user hands. Hopefully upcoming EU regulation will reign apple's overreach in a bit.
Maybe in general, but I think a rule against requiring unnecessary accounts is a good rule. The EU should consider making that a regulation.
Apple doesn't get to dictate what constitutes a good user experience. Especially for me - that is my prerogative and mine alone.
So yes, I will be extremely happy with it. This opens doors to all kinds of software that can compete with one another, and if I don't like it, I can simply uninstall it myself.
Just one more bit of anecdotal evidence to support your view.
Our app was rejected after review until we updated an external support doc to which the app linked. The doc contained system requirements for both iOS and Android devices, and we were specifically rejected for even having mentioned the competing operating system.
> The doc contained system requirements for both iOS and Android devices, and we were specifically rejected for even having mentioned the competing operating system.
same, for us we just open all links in safari now, so if mentions of android show up its not "in the app"... an arguably worsened user experience for no good reason except to keep apple happy
You're confusing first party apps with third party apps. Also you're forgetting that this is a forum which is heavily biased to developers. I use Android because my phone isn't a fashion piece. Some of my users sadly use iOS. They want the software on the devices they purchased and own, but Apple is preventing us from delivering this to them unless we do exactly as Apple commands.
My phone is not a fashion piece. AFAICT the blue bubbles will show up with an old 4S just as well as with a 14 Pro Max.
I have an iPhone - which I got after many years with Android - because iMessage is an essential app for me. I live in the US, so my business partners do not have [choice of alternative messaging app] installed and they are not going to install it just for me. I'm a doctor working in a hospital that has two complete dead spots for cell reception, and whose IT department blocks WiFi calling. So I can't make phone calls on either service, and only on iOS can I get messages that are really, really important over the hospital WiFi.
I could talk until I was blue in the face about how other methods are better. Or how Apple is being a gigantic bunch of assholes by not using something other than vanilla SMS if you're not an iMessage user. But it's sitting at about 30:1, and you can either go along and be aware of important things going on, or you can be left out.
When business decisions are being made over those conversations, I'd be a fool to ignore it. I don't much like the iOS way, having gotten used to Android and LineageOS, but after my experience with the Nexus 6P that suffered the infamous "battery goes to shit overnight one day" problem that Google wouldn't fix, as well as being dropped from updates after two years, five years of security updates from model introduction sounded pretty nice.
But on Android, you can replace the default messaging app, and that app can have access to SMS as a fallback, so it's really easy to convince people to switch. "Hey, uh, plain messaging is annoying some of us, please install this app, we can all use it, but it will work even with people who don't have it over the regular text service."
It's still getting rolled out a lot of places. Google sees it as the successor to SMS and it's built into native messaging apps. I recently saw cross-carrier support get enabled locally and that made it universal enough that so far anyone I message that's running Android is already connected via RCS.
Apple intentionally doesn't support RCS in order to keep imessages from interoperating with android.
a system that can deliver messages through SMS or wifi is better, especially one that was a protocol, not a product, and would allow multiple platforms to access
You’re being downvoted (clearly by multiple people) for having a valid opposing opinion in a subjective debate. Hate to see that kind of behavior on HN. Upvoted you to balance it out.
No one is forcing you to install anything you don't want to. The only thing I want is having the ability to install anything I want to. If you don't want to install those things the solution is simple: Don't. You don't need Apple to make that decision for you.
While I wish I lived in a world of perfect competition, I also realize that I don't. System-wide rules against bad behavior are a lot more efficient.
> You don't need Apple to make that decision for you.
I also don't need an app making the decision of whether I need an account. Apple preserves that choice for users. And they're not making any decisions for the user about installing. Effectively zero apps will leave the store over this rule, so the user retains full choice over installing.
> System-wide rules against bad behavior are a lot more efficient.
I don't want Apple making many system-wide rules on behavior, even on Apple's own systems (which they share with their users.)
That being said, they're very right about this. Making the distinction between, on one side, apps that are useless without accounts (like banking apps) or apps that are made to help with already existing accounts, and on the other side apps that are just forcing accounts to capture and control the users, is a smart and thoughtful move.
Or (1) is: it’s impossible to create codified rules that have no false negatives and no false positives and we’re smart enough not to act like it’s possible.
You know, this is how almost every rule system on the planet operates. Ultimately there’s an arbiter whose job is to look at the totality of the case.
A better response would be: "Thank you for making us aware, we will revisit their evaluation or update the guidelines" (and then they would actually do so)
This isn't what's happening though. If you're a big app you get to do whatever you want, and if you're small then you have to do as you're told.
That would not be a better solution because it would entail either “solid” rules that are actually always fluctuating and/or people having prior assessments overturned after the fact.
As opposed to… humans working through a specific situation for a specific solution?
It would at least strive for equality, instead of letting the big boys do whatever the hell they want while punishing everyone else (and making it impossible to compete).
There's also the ethical concern about how apple (or their reviewer) can bully you specifically which means there is no other way to delivery our software to your users, other than complying with a bully.
Perhaps the standard should be, "If you are required to have an account to use this service, on or off the app, then you can require it on the app."
For context that would mean that to browse a site like Hacker News, you couldn't require an account, but to post you could. It covers things like Banks or Steam, etc.
That seems like a great policy to me. I bought a guitar tuner app in the past and that's exactly and all it did: act as a tuner. But it then got acquired by a company that sells guitar lessons and other things, and they completely f-ed up the app and it requires an account and a subscription now if you want to tune your guitar. Fortunately there are other options in the Play Store, but I paid like $15 or $20 for it at some point. This tempts me at a side comment about why I hate automatic updates, but I'll refrain. Luckily it was Android so I was able to backup the APK before they ruined the app, and I sideload it now. Along with old Pocket Casts, Audible, and a couple of others.
I use two banking apps that have a FAQ feature that's just a fancy wrapper for their respective online knowledge bases.
It's only due to laziness on their part that the entire app needs a login. Even if the only thing I'd like to do is browse the knowledge base.
Similarly, you shouldn't need to be logged in to queue up an arbitrary number of transactions. To execute them sure, but every banking app I've tried makes you login from the outset for no discernible reason.
How do you nominate which account to 'queue' up those transactions against? And what benefit does not logging in have when you have to login anyway to do actually do something? I'd rather everything be kept (relatively) secret and secure
For example, Gaia Maps. It's just a navigation app using publicly funded USGS or crowd sourced base maps, but by switching over to a user account requirement, they can con people into paying a monthly subscription for map "updates".
If you're going to rip people off with "software as a service" then you need to require an account.
There are many exceptions to the rule with Apple's policies. I knew a few app developers that could skirt many of the official rules, because they had friends that worked for Apple.
You are not creative enough. A banking app can run without an account by showing you interest rates for deposits and mortgages, and show you a map of their branch locations. An online game can run without an account by showing you a tutorial and videos of other people playing the game. The Twitter app should show you tweets without an account.
> it was Apple’s policy that apps cannot punish users or exit() the app in retaliation for them denying a permission.
Meanwhile, WhatsApp still "punishes" users for denying contacts access by hiding everyone's names (only the phone numbers are shown), including for contacts that have their own names set in their own profiles.
> Meanwhile, WhatsApp still "punishes" users for denying contacts access by hiding everyone's names
Huh, had no idea that's why I only see numbers.
If I do allow contacts, does it show the name from contacts, rather than whatever display name
they chose?
If so then I guess that's kind of a "technically we need contacts to display names, which are resolved locally" deal. But Apple could push back "you're big enough to plumb a display name through, not just resolve
locally, and deal with spam implications" if they wanted to take a hard stand.
The iOS shows a phone number input if you try to initiate a chat and have contacts permissions disabled. I'm not sure whether that's because it's to comply with app store regulations, or the product owners on both sides prioritizing different things. On both platforms you can still initiate chats without contacts access by using the wa.me domain, eg. wa.me/12125551234 for +1 (212) 555 1234.
Sometimes I need to contact somebody on Whatsapp one time or such, and I don't want to save their contact. But Whatsapp on Android shows only my own contacts to initiate chat. Like you said, wa.me is a way. I made this quick page for exactly this:
WhatsApp has always done this (to my knowledge). Phone numbers -> name resolution is done using your contact list. At least last time I checked.
Usernames are not given much weight in the UI--there's no guarantee that my username reflects who I really am. Feels rightly more suspicious IMO to see a message from an unknown number than from "~Elon Musk".
I believe this happens regardless of whether the app has contact permissions or not.
The Whatsapp app could easily let you assign your own locally saved aliases to those phone numbers, when you're not sharing your address book. "Frankie" is a more usable moniker to me than "+12822745113". They could give us that ability in an afternoon. But they just won't. Because they want your address book. ALL OF IT.
I wish there were some kind of "modern tech" technical review panel on board in, say, EU and US regulatory institutions. Not to impose or forbid certain changes, but to curate an evilness score. Publicly.
And then if a monopolistic company consistently enshittifies things, when the time comes to apply a penalty (for some anti-competitive legal reason), the regulators will apply the reputation ("evilness") score as a multiplier (or divider, if you will) on the sum of the fine.
Evilness can't be measured and expressed fully objectively. So citizens should be able to override a reputation score mutation (remember, they're public) through a referendum.
An advantage of this approach would be that it could increase citizen awareness that things don't have to be this shitty.
I'm occasionally amazed by how friends and colleagues put up with being pushed around by their OSes, their apps, their phones, sometimes to the point that cognitive dissonance makes them into apostate apologists.
> Phone numbers -> name resolution is done using your contact list. At least last time I checked.
Nope. With contacts permission granted, unknown numbers turn into ~names (per user's own profile) automatically. When you revoke the permission, the ~name is hidden to punish you.
> [...] there's no guarantee that my username reflects who I really am. Feels rightly more suspicious IMO to see a message from an unknown number than from "~Elon Musk".
It's an entirely separate problem, and as old as mail itself (which predates computers by many millenia). Would you know whether to trust elonmusk@twitter.io, without looking it up?
I discovered the other day that WhatsApp (on Android at least) will not let you start a conversation with someone without selecting them from your contacts.
I don't mind fake personal data, like contacts or photos, but once you get into locations I'm iffy.
If it's being used locally for showing your location on a map, or searching for nearby businesses, sure, give it fake data.
But if you're talking about an app that does internet speed tests and maps the speeds for different cellular providers, or lets users report local weather conditions to improve forecasts, then I have no problem with those apps being able to say "Either give us an accurate location, or give us no location, we don't want your fake location."
The platforms would have to be an adjudicator of which apps get an exemption for users contributing back data that will affect other people rather than just influencing their own browsing experience.
I think Apple has come up with some good middle grounds on this, you don't have to grant an app "precise location," and you can grant photo access via a system provided image picker that only shows the app photos that you've selected.
Worst offender is google photos on iOS - you can’t even open the app without giving it all photos access. Selected photos doesn’t count. Even just to view photos already saved in the cloud.
Discussed recently on ATP[1] - this is a huge security hole. If you give access to all photos, apparently the app can search through the EXIF data to extract locations and timestamps, and build up a very accurate timeline of your whereabouts.
I wish Apple stripped sensitive metadata from photos by default when interacting with third party apps/sites. The few services that actually need this data could request an additional permission.
As an app developer I don’t want users to send me location metadata with their photos, but there’s no easy way to communicate this to non-technical users.
When you open it, it defaults to the "Photos" tab which has a message (not a dialog) asking for all photos access. But if you switch to any other tab (like Search or Library) you've got access to all of your photos in the cloud.
On the one hand you wouldn't realize that if you never tried tapping another tab. But on the other hand, the main "Photos" tab is designed to access all of your local photos and show whether or not they're backed up. Most (although not all) people are probably using Google Photos for this (to save local photos to the cloud), so it at least makes some sense for it to be the main tab with a prominent request.
Here's a screenshot [1] showing how the permissions prompt originally blocked you from navigating to the other tabs, and some additional reports of the issue [2] [3]. What's worse is that very old versions of the app worked fine in view-only mode without these invasive permissions demands, but then Google decided to update the app to be completely useless unless you surrendered all your photos.
I'm surprised Apple allowed the app on their store for over a year, with what appeared to be a clear violation of their policies.
This shouldn't have even been possible. iOS should have never given apps a way to tell whether they've been denied permissions to any photos. From their perspective, it should just look like you don't have any photos if you deny them all.
Just checked and it appears they’ve fixed this. For years it would occupy the entire screen and not permit accessing any other tabs. (You can find threads from last year discussing this).
However they still don’t offer a way to upload specific photos, and if you attempt to share only selected photos in the ios settings app they detect that this isn’t all photos.
It’s partially correct. I installed the Google Photos app with the intention of sharing some photos from my phone to a shared album. As far as I can tell, it is not possible to give Google Photos access to a limited selection of photos. The app just tells you to go back and give access to all photos.
You can access all your cloud photos without granting access to any local photos -- that was the main point.
Yes you're correct that there's no way to give access to only selected local photos, but that permission also doesn't really make sense for the app. Its main purpose is to back up all of your photos automatically.
If you want to upload individual photos just do it directly from photos.google.com. It's a single click. There's no reason to install the app at all.
Almost as bad is the FLIR app. You have to give it permission to view all photos, or else it won't let you save a photo. iOS specifically has an API that allows saving photos without photo access.
> Apps should be required to gracefully handle the cases where users deny permission to access real data
Or else? You're suggesting an organizational solution to a technical problem. This can't possibly work. Fake data is the only practical solution to this, such that the app would see the permission as granted when it is not actually granted.
I don't think those things are mutually exclusive— lots of policies are affected by technical requirements and lots of technical design and development is affected by policy. CAN-SPAM did a great job of keeping legal businesses with aggressive marketing (within the reach of American law) from trapping people in email subscriptions, and technology has done a great job of tamping down the rest. Neither is perfect but they're both effective at the level they need to be. If a software company requires signing in without needing it for their core service, or requires you to link a social media account even though it's entirely unnecessary (e.g. Kinja,) I'd argue that those are more policy than technical, and a technical solution would probably struggle with them.
And sure, what's "necessary" for the app is nebulous, but the law has tests for differentiating between two nebulous states. Even a policy that had way too much grey area, like fair use, would still protect users more than "app developers can do whatever they want as long as it's in the privacy policy."
The technical solution is to make the output of having denied permission identical to the output of there being no data. On iOS, if you deny permission to access devices on the local network, the app has no way of knowing - it just sees that there are no devices available.
But it is possible to not have photos on your phone, e.g. if it is a new one, or if you prefer to use a separate camera, or you are not the person to take pictures.
It should be illegal for a device manufacturer to retain any kind of control over devices after sale. Some governments are finally realizing this.
So no, this is not a viable solution in the long run. Besides, Android is a thing. I personally have never used an iPhone as my real phone precisely because of this — I can't install modded apps, I can't install pirated apps, etc etc. It's not okay to have to jailbreak the thing to make it usable.
As an app developer, I do have a very real problem. I don't want Apple to impose their agenda on me and act like they own the relationship between me and my users. In particular, Apple should have no opinion on what kind of UGC my app contains if it's rated 18+. Apple should also stop protecting their own products by rejecting apps that cut into their market. But of course, Apple would do none of these things voluntarily, so that's where regulators need to step in.
If you want your device to be controlled by Apple, keep installing apps exclusively from the app store when the sideloading inevitably comes. Just like you can already choose to do on macOS.
So which app does Apple reject that cuts into “their market”?
Office apps (iWork)? There is Office 365, GSuite
Storage providers (iCloud)? All third party storage providers show up next to iCloud when you use the file dialog box - DropBox, Box, Google Drive, One Drive
Streaming apps (AppleTV)? There are dozens and when you search for a TV show or movie, the AppleTV app will tell you which subscribe services have it?
Streaming music (Apple Music)? Spotify, Tidal and Pandora are all on the App Store?
Etc…
> do have a very real problem. I don't want Apple to impose their agenda on me and act like they own the relationship between me and my users
Guess what? I as an end user don’t want to have a “relationship” with you. When I pay for an app, I don’t want to give every Tom, Dick and Harry my credit card information. When I get ready to cancel my subscription, I don’t want to have to deal with you.
> So which app does Apple reject that cuts into “their market”?
Netflix's "you can't sign up through the app" is a prime example of this that immediately comes to mind but there are many more.
An argument can be made that hey.com is, in a way, competitor to the paid iCloud subscription. Yet Apple acts as if they own that relationship and that the app store was valuable in bringing the users to the app: https://www.hey.com/apple/iap/
Do you really think it's fair that all competing services have to be 30% more expensive than Apple's own ones if they play by Apple's rules?
There used to be lots of iOS apps that allowed streaming pirated music. Everyone, including Apple, was seemingly fine with that and never asked where the music came from. But then, suddenly, when Apple Music was preparing to launch, all those apps started magically getting rejected for breaking the rule on "illegal file sharing".
> When I pay for an app,
Stop right here. No one was talking about paid apps. My initial point was about free apps. But if you so insist, in a FREE market, app developers would offer two options: pay through Apple with their 30% tax, or pay directly without it. I'll let you figure out which option most people would choose.
> Netflix's "you can't sign up through the app" is a prime example of this that immediately comes to mind but there are many more.
He said the app was “rejected” as in not allowed in the store.
> Do you really think it's fair that all competing services have to be 30% more expensive than Apple's own ones if they play by Apple's rules?
Well seeing that neither Netflix, Hey or Spotify allow in app purchases and don’t pay Apple 30%…
> There used to be lots of iOS apps that allowed streaming pirated music. Everyone, including Apple, was seemingly fine with that and never asked where the music came from
When has Apple ever allowed apps that focused on pirated music?
And Apple has been selling music on the iPhone since the day it was introduced - well to be pedantic, three months after it went in sale.
> But if you so insist, in a FREE market, app developers would offer two options: pay through Apple with their 30% tax, or pay directly without it.
And there is nothing stopping you from doing that. In fact, Spotify did that for awhile.
in a FREE market, app developers would offer two options: pay through Apple with their 30% tax, or pay directly without it
In reality they will make scummest apps possible and ignore the AppStore completely. Only very big players and those whose primary target is AppStore anyway will offer two options.
>I don't want Apple to impose their agenda on me and act like they own the relationship between me and my users.
That will be solved if/when they need to allow alternate App stores. But even then, The App store is Apple's own store, right? They make their own rules on what's allowed or no on their store.
I have no issues with them controlling their store (as an android user, Google does the same despite having much less care). I'm just glad they are seemingly being forced to open up for stores that want different rules.
Yes, some ios devs have a problem using dark patterns and peeking into where their nose doesn’t belong, but it’s not a problem anyone wants to solve or consider as such.
We choose it because it repels this “me wanna you should they need to” attitude. Please make apps that obey the rules or ignore the platform. Don’t tell anyone what they have to do for you without a contract.
No, you can't choose to only install apps exclusively from the app store on macOS because the macOS app store is a barren wasteland. The MAS makes it very clear that the only reason app developers put up with the iOS app store restrictions is because they have no choice.
The Mac is from a different time and has a very different user base than phones. By your argument the Play Store on Android makes it clear that the reason app developers put up with app stores is because of user patterns. On phones users are used to getting apps from the built-in store, so that's where they look for apps. Trying to sell an app via a website and APK download just doesn't work; users don't bite. There are alternative Android stores, most notably (outside of China) Amazon's and Samsungs. But both are wastelands, and devices with those stores typically also ship with the Play Store.
I don't think "app store competition" is going to be much of a factor for iOS post-DMA, but I do expect hobbyists and open source developers to congregate around AltStore or something and create a repository of free utility apps without having to pay Apple's developer fees.
It might not be as much of a problem in the US, but it is a real pain in the ass people have to contend with, for example, in Russia. I've seen it myself. Apple is enforcing US sanctions against some Russian companies, which means they can't have an iOS app. At all. I heard stories about how a sanctioned bank would load some kind of shadily signed copy of its app onto people's iPhones in branches. For Android, that same bank just hosts a self-updating apk on their website — with no intermediates to tamper with their app distribution.
Besides, being able to install modified apps is an important leverage against companies that don't act in their users' best interest. This way you can still use their services, but do so on your own terms.
1. They don't think about these kinds of second-order effects. They see that this company is somehow involved with the government and that's it. Their electorate won't care about these kinds of details because they're "doing something" to supposedly stop the war sooner.
2. They think that Russians would somehow revolt against the government. This doesn't work — the Russian government lacks any meaningful feedback mechanisms. By protesting, you'd expose yourself to immense personal risks for no discernible effect. Unless you're a heavily armed private army heading straight for Moscow.
I strongly disagree that these are the only 2 possible explanations. The first is clearly not true — these second order effects are well known and often discussed, and the fact that sanctions are used in circumstances when the population is not expected to revolt shows that the second one isn’t the only remaining reason to use sanctions.
The guideline to be able to access apps without an account still exists, but the enforcing might have become lighter - or it's just the random fluctuations in review qualities we all know by now :)
Both of them still exists, but of course in some situations it doesn't make sense, so there is a lot of leeway depending on the reviewers. My experience is positive here, I can't remember the last time an app did not allow me to not have an account or manually provide data when it made sense.
(iv) Access [...] Where possible, provide alternative solutions for users who don’t grant consent. For example, if a user declines to share Location, offer the ability to manually enter an address.
(v) Account Sign-In: If your app doesn’t include significant account-based features, let people use it without a login [...]
Thanks for doing the work by digging up and linking to the actual guidelines! That's pretty close to how the wording was all those years ago. Like all things AppStore, the enforcement is what ends up being uneven and subject to Apple's discretion and judgment. Which is a good thing IMO. Without publisher discretion, you just get scummy developers who rules-lawyer their way onto the app store.
Every smart home app seems to want an account on Android. Maybe they have a different path on Apple, related to HomeKit or similar, but I'm a bit skeptical.
Tasmota + CloudFree + Home Assistant and never make an account again and have full control over the devices in your home. No accounts and your lights still work when your internet is down.
I love my home assistant installation and didn’t even know about Tasmota/Cloudfree. Thanks for sharing, this is the next logical step to fully detaching from subscriptions/accounts.
> Apps must gracefully handle it and continue running.
Would this include… not doing anything? A notice that to use the app that you must grant access?
I hate apps that do that … BUT:
I am thinking of a logistics application that I wrote that requires location access. It effectively serves no purpose without location access.
It’s a small app that we offer to our clients. Not an app for the general public. But it is a situation where I don’t want the app to continue doing anything without location access.
It depends on the app. For example, I can’t view my balance in my banking app if I don’t sign in to an account, but I can find nearby ATMs or pull up the number for customer service.
The logistics app could offer some features like phone numbers, support hours, or even account management features without location access, so users can still get access to those things even if they can’t enable location (or are in Airplane Mode, for instance).
And then the core part of the app could have a message explaining why location access is essential. Perhaps with a link to a privacy policy or other document to explain how it will be used and handled safely. I love apps that do that and even have a button I can tap to go straight to the proper settings screen to grant access (or in some cases I can tap and the app will request again, so I can say yes this time).
Your case is special, but think about a maps app that requires login and location, when you want to simply measure the walking distance between two points.
I believe there’s a special publishing mode for yours, but not sure how it works irl.
I would imagine they just mean "you can't crash or abruptly exit." Telling the user "please grant location access to use the app" and providing a button to try again is probably fine.
I think it depends on the function that the permission access provides. If permission use is core to the app (like your app is a map with a dot for the user's location that has no other functionality like business searching), then, you're probably allowed to just sit there with an empty map doing nothing until the user consents.
If location access is peripheral to the core function of the app, it's a different story. Like your Yelp and one of many functions of your app is to "search nearby" then you can't just have a screen that does nothing until the user consents.
EDIT: Yes, for OP's use case, you'd just appeal to Apple and prove that the app has no other purpose besides the use case that requires location. I've done this in the past successfully.
One middle ground between requiring location access and failing to run at all would be to ask the user to provide an address. That way the user would have some control over what info they provide.
Agree. Any app that requires location access should be able to accept a manually introduced location as a fallback when the user doesn't desire to grant location permission.
Which is consistent with what would happen anyways with the above idea of providing fake data when the permission is rejected.
I wish I could use apple products without an account. But an apple id is required for running apps, because you can only get and install apps through the app store.
I would like the equivalent of a "de-google'd android phone" on ios.
The point of civil disobedience is often to ensure the non-graceful handling being protested results in a very non-graceful effect. Companies soften their stance real quick when the hard positions they hold cost them a lot more.
Apps punish users - there must absolutely be a feedback effect of users punishing apps.
As someone who works in banking - We don't show anything other than login and enrollment (and maybe a link for account opening, if the FI has it). Apple has yet to complain.
> It seems they must have softened this stance because I am seeing more and more apps that require an account to function.
On Apple they compromised by requiring that apps with a login support "Sign In with Apple." Since you can signup with an anonymous iCloud email, this is almost as effective as not needing to create an account.
XPrivacy for rooted android could do this 7+ years ago and there are other modern alternatives (but I haven't rooted my phone for a long time so I can't vouch for them): https://github.com/M66B/XPrivacy
Obviously that is not mainstream, I agree it should come built in. But then both Android and iOS allow bullshit like region-locked apps or preventing screenshots from DRM content, so good luck with that.
I used it in this way, and experiencing first hand how much the deck was stacked against me as a user let to me abandoning any belief that phones are computers.
They are vendor content delivery devices and you are at their mercy.
XPrivacy was incredibly cool. But on modern phones rooting and installing Xposed has either gotten massively more complicated or disabled ougright. GrapheneOS wasn't working with banking apps, Google broke rooting via Magisk multiple times on the Android Beta and at some point and i stopped bothering.
Maybe GrapheneOS or similar Projects could do this
You pass basic safety net. You do this by claiming that your device is an older device that doesn't support hardware attestation. I can only assume that in some small number of years hardware attestation is going to be required and will require software exploits to work around.
Last time I tried to use magisk on my pixel it was a complete fustercluck (about a year ago). I ended up having to patch together multiple fixes in multiple forum threads, and manually pick apart and patch the firmware package, because nothing worked at all for months on end, on a completely stock device.
I have kinda lost faith in it. And it doesn't help that it tries to do everything internally, so you can't e.g. download your pre-patch blobs or upload them after it loses track of them, because it does everything exclusively in complicatedly-magically-named internal folders. There is some seriously bonkers decision-making going on in it.
Last time I tried this I wasted many hours but couldn't make Google Wallet work. SafetyNet was passing but Wallet was still disallowing any card operations.
GrapheneOS has implemented storage and contact scopes. Users can set a program's permitted storage environment. Similarly, contact scopes allows users to limit access to contacts that are tagged with a keyword. On my phone the 'special' contact group includes Djimn Hovnbg, with a number in Egypt, Blin Futtum'ch with a UK number, and so on.
XPrivacy was great, but apps would regularly crash when I denied some permissions - so apparently it was not faking data well enough. It got so bad that I would never just click "deny", but always "temporarily deny" first. Then, if the app worked, I would deny permanently. If it crashed I'd have to figure out the minimum set of permissions I could get away with granting.
This would never land in a factory image or upstream Android, but it has a reasonable chance to become part of projects like LineageOS, given enough user demand for it.
Do you have any reference for that pressure from Google? I thought it was because during one of the major version merges the underlying code changed so much that the entire feature would've needed reimplementing from scratch, like many other Cyanogenmod era features.
Privacy Guard also wasn't as complete as XPrivacy (and its evolutions) were. It's a shame that the feature disappeared, but I don't think it mattered much to begin with.
There is no such thing. The respective app stores allow you to distribute apps in select regions. This is an important feature for app stores because an app may not be a good experience in all countries. The app may not be localized to all languages, there may not be content moderators for those languages, those countries have a multitude of laws that you need to comply with, your app may include copyrighted content which is only licensed to be distributed it certain countries, etc..
>preventing screenshots from DRM content
This is a feature requested app developers due to the legal requirements when licensing content such as movies. Movie studios don't want people streaming or recording their movies so app platforms need a way to surely show this content.
>This is a feature requested app developers due to the legal requirements when licensing content such as movies. Movie studios don't want people streaming or recording their movies so app platforms need a way to surely show this content.
Of course, but if our industry had any chutzpah, we would have simply said "no, that's impossible" and continued to distribute operating systems where the user has ultimate control over the hardware and recordings. If movie studios want people to watch their content, they'll have to accept the risk of piracy. It's not like clipping and recording from your phone is how the pirate rips appear anyway. Even imagining that a movie was released only for one model of super-secure phone, someone somewhere will either break the security or simply stick their phone in a dark box and record it with a camera. Once they've done so, they can share the un-DRMed version online on pirate sites and everyone else can download it.
As long as the analog hole exists, DRM is anti-consumer without reducing the likelihood that copyrighted content will be reshared freely online.
Don’t share this too hard. I’m afraid for a future where we are only able to watch content that is being streamed to our ocular implant directly. This has the nice benefit that it allows for hyper personalisation and always visible hyper relevant ads!
When you are a platform owner it is important that you evaluate the needs of all stakeholders and not just the needs of the users of the platforms. Telling app developers that you are not willing to compromise is not a great way to convince them to create apps for your platform. Also as a platform you want your platform to appear as a safe place for content owners to have their content on. You will have trouble convincing content owners that your platform is safe if it's security is much worse than everyone else's
> When you are a platform owner it is important that you evaluate the needs of all stakeholders and not just the needs of the users of the platforms.
I disagree. The literal entire purpose of every single non-user entity involved in this situation is to serve users, and if it's not serving users, then that's a systemic failure. If corporations want a place at the table, they should be serving users, and if they can't serve users, there should not be a table for them to sit at, period.
In the cases referenced, that means DRM should be illegal, period. Platforms shouldn't have to allow DRM to attract content creators, because there should not be competitors that have DRM. If the option to have DRM doesn't exist, then platforms don't have to compete to attract content creators with user-hostile misfeatures like DRM.
Our economy should be designed to serve people, not corporations. Anything else is a failure.
I understand the law says corporations are people. I'm saying the law is wrong.
Bringing content users want to watch is serving users.
>DRM should be illegal, period
Why? It is preventing users from doing illegal things. Saying that DRM should be removed so that users can make illegal copies of the media they are watching is not a strong argument to me.
>Our economy should be designed to serve people, not corporations
People make content and people want to be able to have their copyright not be infringed. Computers by default make it way to easy to violate the copyright of creators which in why making it possible to secure content is such a valuable idea.
DRM also prevents users from doing legal things. Such as making copies for personal use, which is legal in France. Or when done by library or archive, in the US. Or copying short clips, which is legal as "fair use" in many jurisdictions.
> People make content and people want to be able to have their copyright not be infringed.
Tough shit. Copyright is entirely arbitrary, and it's bad actors have ruined it for everyone else. DRM will be evil for as long as "buying isn't "owning"; until then piracy will be strictly superior.
> Computers by default make it way to easy to violate the copyright of creators
And my kitchen knives by default make it way too easy to violate homicide laws. You can argue it is overall more beneficial to the consumer to disadvantage themselves so the market can thrive, but that's still an anti-consumer market.
Even if copyright wasn't a thing some creators do not want their work to be copied.
>And my kitchen knives by default make it way too easy to violate homicide law
If kitchen knives were made impossible to use for homicide, but could be made for the same exact price in the same amount of time and were just as effective at everything else there would be no reason for people to sell homicide capable knives.
> If kitchen knives were made impossible to use for homicide, but could be made for the same exact price in the same amount of time and were just as effective at everything else there would be no reason for people to sell homicide capable knives.
If content were made impossible to pirate, but could be made for the same exact price in the same amount of time and were just as effective at everything else there would be no reason for people to sell piracy capable content.
But, homicide-incapable knives and piracy-incapable content aren't real. They're a fantasy, which does not exist.
All DRM does is make it harder for legitimate users to access content they have paid for.
We cannot create homicide-resistant knives because it is indistinguishable from lawful slaughter and butchering knives. Similarly, computers have a powerful native feature - the ability to infinitely copy digital content until you run out of storage or electricity. This can be used for legal and nonlegal purposes, but neutering it's capabilities is unthinkable.
Copy protection tries to put the genie back in the bottle, and then blames the community when things go wrong. It's a circular process that resists advancement and protects exploitative parties.
> It is preventing users from doing illegal things.
It's not, clearly. Search your favorite DRM'ed TV show name followed by "torrent S01E03" (to indicate season 1 episode 3) and see how well that DRM is working.
> Saying that DRM should be removed so that users can make illegal copies of the media they are watching is not a strong argument to me.
I didn't say that.
DRM should be removed so that users can access content they've paid for. DRM nearly always effects legitimate users.
> People make content and people want to be able to have their copyright not be infringed. Computers by default make it way to easy to violate the copyright of creators which in why making it possible to secure content is such a valuable idea.
It's not a valuable idea, because it's an impossible idea. If you can view the content, you can pirate it. Period. DRM has done absolutely nothing to stop pirates and has consistently harmed users.
It's worth noting that content creators are often totally on board with releasing without DRM: it's content distributors who are worried about this, generally.
I worked for a couple years at a company that delivered electronic assessments. Their use case makes sense for control of the device ( these assessments were usually delivered to a classroom environment where proctors could observe physical cheating ). It took a lot of pushback with Apple to be allowed to “not allow screenshots”. Which, I think, is pretty great that they originally pushed back, but then understood the product.
The way Apple have implemented region localisation on the App Store is very bad. You basically have to nuke your whole account to change regions, and that includes losing all your subscriptions (if you have any annual subscriptions that’s just too bad for you). So if you spend time between two counties, and need a region locked app in each one, there’s actually no workable solution.
Your explanation for the anti-screen shot DRM doesn’t hold up very well either. I don’t know of any streaming app that doesn’t also have a website that I can take screenshots (as well as full screen captures) on, so it’s clearly not a content licensing requirement.
Yah, this works terribly for expats. A warning should be sufficient for non-DRM content, and for DRM content just use the Netflix model of “we’ll show you content you can see based on where you are right now”.
Being locked out of Starbucks Thailand app because I don’t want to change my whole iTunes account is ridiculous.
>I don’t know of any streaming app that doesn’t also have a website that I can take screenshots (as well as full screen captures) on
Your browser does not have DRM support which typically means you are not sent the full quality videos. And not all media apps have a website. Not every app that I am talking about are from massive companies that can support making apps and a website.
> Your browser does not have DRM support which typically means you are not sent the full quality videos
To take this argument seriously I’d need you to provide some examples. I use some of the bis streaming services, and they all stream full high quality media to my laptop. Which are the ones that don’t?
> And not all media apps have a website.
Again, examples? Every streaming app that’s ever blocked me from taking a screenshot has also had a streaming website. What portion of the market licenses content with a requirement to use DRM to block screenshots?
For starters, it does nothing at all to prevent taking screen shots. Which is what this thread is about.
As for high quality video capture, it is trivially easy to do. How do you think high quality copies of Netflix-only content ends up on the pirate bay they same day it comes out?
Yes it does prevent taking screenshots of high resolution playback. Your options become low resolution capture or nothing.
High quality captures are still possible if you connect an external capture device coupled with something that provides the necessary drm authentication or you need a software based drm defeat.
An HDMI splitter completely removes HDCP, so if you want to do a hardware approach, that doesn't require any software at all. If you don't want to use some cheap product from amazon, just run Netflix in a desktop VM. Both of these options are very trivial to implement, no complicated software bypass at all. Also remember that for piracy to occur, you only need one person to go to this very small level of effort to get a torrent uploaded. These protections are useless, and achieve nothing other than bothering legitimate users.
Also, here's a screenshot I just took of a Netflix show (it's 1080p, but still...) https://imgur.com/a/evJjf06
Your answer amounts to "Yes, both those things exist to the detriment of the user, but they were requested for the benefit of corporate app writers, so it's okay that the device the user supposedly owns obeys someone else."
Except these features are not to the detriment of users. If apps were not region locked at the store either they just won't be in the store or they will implement the region lock themselves. Similarly DRM is seemless for users. The users get the same media watching experience they expect, but the content is securely played to stop people from making illegal copies.
>the device the user supposedly owns obeys someone else
The user may own the device, but they don't own a movie that the device is playing. Your device isn't obeying someone else. DRM is a feature that lets your device handle other people's content in a safe manor.
> When an app asks for permissions, the OS should not only let you answer yes or no. Every category should have a "yes, but feed the app fake data" option.
A significant amount of people don’t even know how to forward an email.
Imagine the havoc that would ensue when people try to use Google Maps for navigation, and they choose to feed it fake data because they don’t understand what it means.
This is an entirely UX problem then. You could bury the data faking deep in the settings, clearly explain what it does in plain language before enabling it as well as plainly telling the user onscreen that the application is being fed information for privacy reasons that they themselves enabled (and can easily disable).
There is always someone who will end up enabling this erroneously, but it would provide a lot of value to a lot of users that didn't.
Right, locking the functionality off to only people with a deep understanding of it would work but it’s sidestepping the problem. People without understanding would still benefit from it so it’s a shame to lock them out of it and it’s harder to justify a feature only 0.5% of your user base will use.
It's impossible for the OS to know the intent of the app requesting location with certainty. That being said, android at least has options for "Approximate" and "Precise" locations and locations in the background or only when the app is open.
Personally, I think it’s great that both options exist. Some problems really do require location info, as well as other strict controls ( like no screen-shots).
There's truth to that, but jailbreaks to install those on most smartphones depend on exploits for those systems to install your own software. It would be nice if some of this stuff came stock.
I'm not even remotely suggesting eugenics. What I am saying, in a rather tongue in cheek manner, is that sooner or later your own judgement needs to come into play and driving into the water because the voice told you to is probably a self-inflicted injury. There's only so much hand holding you can do to protect people from themselves, and coddling isn't a long term solution for anything.
What makes you think GP is talking about eugenics?
If anything, they're talking about natural selection which is not eugenics. Eugenics is when you select fitness at birth.
GP would be endorsing genocide, or maybe epigenetics if anything, based on the small out of context comment. I highly doubt either was the intention and wonder how you got to the eugenics conclusion.
>This seems like a learning opportunity. Or a Darwinian opportunity. Either way, self-solving.
I took either as meaning a learning opportunity for one or all of the 1) GPS app makers, 2) the person who blindly followed the directions of a robot, or 3) the rest of us who learn about the event.
What interpretation did you have that suggests they were referring to eugenics?
I think you're selectively ignoring parts of the comment. "Darwinian opportunity ... [which is] self-solving" is clearly referring to the death of a person who blindly followed GPS directions for a mis-configured app. GP was saying that anyone who dies because an app told them wrong information was not "fit" (darwinian fitness) for survival. Expressing no remorse or desire to prevent preventable death with the justification that it's allowing the species to become more fit is eugenics.
There is a limit to the extent that functioning adults should be protected against themselves by the government. As long as the feature is designed with UX in mind, and explains what it does in plain text, I do not see the issue. Individual autonomy should be prioritised as long as third parties are not harmed. Anything else is infantilization, which is not a role the government should take.
Am I high right now? I think you're selectively ignoring parts of the comment. It's 13 words: "This seems like a learning opportunity. Or a Darwinian opportunity. Either way, self-solving."
You're turning the comment into 3 words: "Darwinian opportunity ... [which is] self-solving"
Small reminder that on HN you are supposed to steelman comments when you reply, not strawman. Clearly those 3 words refers to the death of the person, but you can't ignore the remaining 10 words and say the entire comment was about eugenics. So which of the 13 words am I ignoring that you aren't?
Also natural selection and killing off dumb people who are already alive is not eugenics. It's either epigenetics or genocide but like I said in a previous comment: eugenics is used to select fitness _before birth_ not after.
Eugenics aside, people very regularly follow satnav directions completely blindly, the most recent one I can think of being the person who drove directly into the sea in Hawaii.
If there's an opportunity for learning, it's not being taken
You say "very regularly" but when was the last time you saw/heard about that happening? I'm in the UK and I saw that Hawaii story and I can't remember hearing about anything similar for years. So my conclusion is that, out of an 8bn population, one or two making such a mistake once every few years is nothing.
I'll grant you that people driving into the sea is not a regular occurrence, but local news of people driving the wrong way up one way streets or onto unpaved roads and getting stuck happens way more often.
I guess on a planetary scale that's vanishingly rare, but most things are at that scale too.
If we're going to think at those levels, nothing that happens in the UK really matters as we're less than 1% of the world's population...
No, the whole point of the original post is that a lot of users see (and use) the option, so that the app's database of personal data is full of rubbish.
I don't think the GP's scenario is realistic. A user would see that their location on the map is wrong before they even get a chance to begin navigation.
Besides, Google Maps already sometimes tells people to drive through roadblocks and locked gates and such (which it isn't aware of), so it already requires the driver to think for themselves to some extent.
In that case, people who are driving the car are failing to see properly which way they are going. That problem is a different problem.
> the OS should not only let you answer yes or no. Every category should have a "yes, but feed the app fake data" option
Well, I think perhaps "Yes", "No", and "Custom". If you select "Custom" then perhaps there could be a warning message displayed in the "Custom" menu if that would help, but it should not block you from customizing it as you want to do.
Do a lot of people use Google Maps on iOS? I ask because the “feed fake data” option is something I could imagine Apple doing but never in a million years would I believe Google would do it.
Apple Maps wouldn’t have this issue. It’s capable of running offline (without a data connection) because it can download maps to the device.
>Apple Maps wouldn’t have this issue. It’s capable of running offline (without a data connection) because it can download maps to the device.
This is a strange point to make considering that google maps had offline maps available forever now, and ios only added it in the recently released ios 17 beta.
> Apple Maps wouldn’t have this issue. It’s capable of running offline (without a data connection) because it can download maps to the device.
Why would that matter? Even if the map data is cached locally, a navigation app obviously needs a GPS location from the phone, which requires it to be granted permissions. And the fake data would be equally disastrous to any navigation app.
Or are you suggesting that if Apple were to add a feature for generating fake data, it'd only apply to 3p apps and not their own? I'll admit that it would be totally on-brand behavior.
If you don't have a data connection then it's fine to give location data to an application because there's nowhere it can send it. With properly designed APIs, the app shouldn't be able to store the location data either, only display it to the user by calling the map API.
Location can, and is, stored in the local device and uploaded when connected. Location data is tiny compared to something like video.
All apps can store data because most need to store data if just for settings and cached. Especially any offline navigation app. There is a difference between app storage and general storage.
If you don't give the location data to the application, how is it going to do navigation, finding restaurants near you, and all other similar features?
a lot of people do, for example me. apple maps sucks badly where i live (eu). say, it has no idea my house (built 6 years ago) exists, it builds routes via non-existing roads, is not aware of road works, detours or most of the businesses around
apple maps is completely useless here, even though i don’t like using a google app, there’s no alternative
Apple maps sucks badly here in the US as well. Just last month it took me down a road that had been closed and diverted many years ago, we almost missed a wedding.
I am surprised no top comment mentions this — on iOS, you cannot distinguish if you were granted a permission or not. As an example, if an app asks you for access to your photos, it will always get an array. The trick is that when you deny this permission, the array will be empty, so you cannot know if the user simply has an empty library or if he denied you access. I like it, simple and elegant.
Naturally, in the case of photos, you can use a heuristic, because basically everyone will have at least some pictures. However, in the case of other types of data, say, health data, it is not so clearcut.
Photos is a special case because the user has the option of denying access, giving limited access, or giving full access. You can determine if the user has denied access, but you cannot distinguish between limited access and full access.
Sorry, you’re correct. I was thinking of the case where older applications receive PHAuthorizationStatus.authorized when the user has selected restricted. There are newer APIs to handle the restricted access changes.
I recently tried using Sony's (frustrating) Imaging Edge app to transfer photos from a camera to an iPad and gave it limited access and it refused to transfer images! When I changed the permissions to full access it worked. So there must be some difference, maybe not an obvious one.
Not sure how they do that, but I’d say that on most iPhones in the wild, having the API return <25 images is probably a pretty good indicator that that’s not all pictures.
If nothing else, no photos is likely blocked permissions, but if there are no photos, contacts, location, health data, etc the sum of those parts is a very strong signal.
I suppose they could select a random location within the country/state. Even select it with population weight so that the app would struggle to infer if it was being spoofed. As with any spoofing, it would be necessary to store some state for each app, and generate locations similar to the last one (but not too similar. Random weighted walk maybe, weighted towards some randomly chosen "home" and "work" and hangout places, ideally based at actual buildings in the right districts?)
If you want to go even harder you could try to do the same with images. Generate some basic images of typical snapshot scenes with some AI model, and further postprocess the pixel data to try and give it a statistical distribution that looks like a real camera rather than AI. Add some realistic EXIF too. Doing this on demand may be quite expensive, so the phone could pre-fill a cache of fresh images during quiet hours or something
This all sounds very excessive, but I will give Apple credit and say they're one company who I could actually see going to these lengths if they decided they wanted it
Almost certainly isn't good enough if your app has tens of thousands of users, what if someone got a new device and didn't restore a backup? I've met many people who wouldn't know how to transfer data from an old device
What about other permissions where you can't realistically send an empty object? For example, if the user grants permission to view location, the location object passed to the app will obviously have the pertinent information. Would the OS simply pass an empty location object and wouldn't that make it obvious that permission was denied? Or is it hidden behind some kind of error
In any case, the iOS location services don’t work that way. You can’t call them and get a location back due to the way the system works. It simply doesn’t have location data at times and needs to wait for it to become available. You tell the operating system you want to receive location updates and then it delivers zero or more when that information becomes available and when it becomes more accurate or changes. So if iOS needed to withhold information, it wouldn’t have to give an empty object back, it would just not deliver any location updates at all.
I think that "feed fake data" is the wrong way to do it. The good way should be something like "feed data from alternate source", where the alternate source can be any other program. This other source could be anything that the user wants to put in by that other programs, such as: empty data, random data, fake but consistent data, data from an alternate file (e.g. a separate contacts list, or a picture from a file instead of from the camera), transformed in some way (e.g. turning a picture from a camera upside-down), filtered, logged, or asking the user every time for each individual piece of data, feeding error codes instead of data (and allowing the user to specify which error codes), etc. (This should include everything even the current date/time access.)
This is useful for better user control and for purposes of testing and accessibility purposes.
(My own idea of operating system design, one of the ideas involved (there are many other ideas, but most of them are not relevant here) is the "proxy capabilities", with capability-based security including proxy capabilities; all I/O uses it, and it can also be used in a better way than the UNIX pipes (using the command shell), and in other ways. This also includes even the date/time. No system calls other than Yield and Quit can be used without being given a capability key.
I think this is the best approach, and the only really workable approach. Very often it's too hard for an app developer to play nicely with an unavailable permission, and it makes testing vastly larger and harder for a relatively marginal set of users, so smaller commercial apps mostly won't care to play nicely.
Granting the permission bu feeding an alternative data source is easiest for both parties, the developers and the users.
It, of course, will make some scams easier, too. Prepare for banks to use more complex device-enlisting procedures, for instance.
Why do we need to be awful? Here is a simple rule: No is an option, unless it's really not an option. If it's not an option, you need to be very clear about why (in the app application process maybe), otherwise your app gets declined.
i.e. if tiktok/ig asks for permissions on camera and microphone, no is an option, because you don't need either to use either. If parts of your app can feasibly be used by a user without certain permissions it is on you to design the app in a way where that is possible. No camera or microphone enabled? Conditionally disable the functionality that would require those.
To make this simpler, the burden is on the asker. If you are not clear or trying to be clever, the answer is no. If that sounds draconian, keep in mind, that the app creator has the option to completely forgo this additional step by creating an app that makes permissions optional.
Focusing on enforcing that would make a petty army race unnecessary, and it's the better call for humans anyway.
Sounds good, but enforcing it how? The only party here that can do the enforcing is the Google/Apple/Microsoft App Store. I'm not sure they all have the right incentives to expend the effort to enforce that in a consistent and user-friendly way. Otherwise would have already.
Apple already enforces this, at least to some extent. If you just tell the user “you cannot use our app without allowing us to track you”, your app will get denied from the App Store. Apple is incentivized to do this because they get their value charging access to the ecosystem, and so it’s in their incentive to make sure their ecosystem is nice to users.
> The only party here that can do the enforcing is the Google/Apple/Microsoft App Store
Sounds good to me, though I think there should be a second component, which would be app sdks: Make designing with conditional permissions in mind a first class citizen, and create clear guidelines, as to how to do that, and why you really, really should do that.
> I'm not sure they all have the right incentives to expend the effort to enforce that in a consistent and user-friendly way. Otherwise would have already.
Alas, this is probably where legislation would so some convincing (see gdpr)
Samsung phones have a camera access and microphone access toggle.
Here's what I get when I turn it off:
```
Turn off Camera access?
All apps will be blocked from using the camera. Apps
will still work, but they will only be able to access an
empty black screen. For example, you can still make
and receive video calls, but the other person won't be
able to see you.
```
```Turn off Microphone access?
All apps will be blocked from using the microphone
Apps will still work, but they won't be able to access
any sounds from the microphone. For example, you
can still make and receive calls, but the other person
won't be able to hear you.```
> Every category should have a "yes, but feed the app fake data" option.
I would prefer it to be per app and not category. I may not want to feed positional data to pretty much everything but Google Maps and any app that calls for help in case of emergency. Same for contacts, personal data etc.
I'd however expect an app like that to meet fierce resistance from Google and other businesses that profit from users profiling.
I agree, although it should be both per app and per category. For example, one app can have real data available for one permission but fake (or customized or manually entered data) for another one and denied permission for a third one, for example. You might also want to be able to temporarily change the setting, e.g. for testing purposes, or if an app gives you weather for your location and you want to temporarily change it to another location to view that location's weather before changing it back to use the real location afterward.
This makes a lot of sense. If an app needs my data to improve my experience (and only mine), then feeding it fake data should only degrade my experience. It shouldn't matter to the app developers/authors/owners.
But if (as in most cases) the goal is to data-mine me, fake data should work nicely to impede that.
Of course it won't matter for things like WhatsApp, where people happily sync their entire list of contacts with Facebook/Meta just to have a slightly nicer messaging experience.
>Of course it won't matter for things like WhatsApp, where people happily sync their entire list of contacts with Facebook/Meta just to have a slightly nicer messaging experience.
I was very unhappy to have to do this, but it wasn’t a slightly nicer experience. The app and the service are only marginally usable until you do this. (At least on mobile)
When you authorize a third party mini program in WeChat to access your personal information, you can choose to generate a fake profile for the mini program instead of supplying your real information.
Here's an article in Chinese describing the feature:
That's funny, I was just asking for that a few days ago on a similar thread [1]
> There needs to be a feature on android to give fake gps data on a real device. This would be useful for any app that requires gps for no good reason.
> If your flashlight app needs gps to turn on, no problem. You are currently on mount Kilimanjaro.
I really wish browsers would take this approach with notifications.
If a website asks if I have notifications enabled, tell them yes, and send them all into the oblivion.
Edit: to clarify, I already disable all notifications in Firefox. I was referring to websites that check via JavaScript whether you have notifications turned on and trigger a pop up to ask you to enable them.
How's that different from just having it globally disabled? I've never had a site refuse to work at all because I haven't allowed it to send desktop notifications, does that happen?
Just disable notifications. There's a setting for it in Chrome and Firefox, I'm sure there's a setting for Safari and the various Chromium forks as well. Set the notification permission to "deny by default" so you can manually opt into notifications later on a per site basis.
Yup. I have this on Firefox. Makes the web so much better. The only indication that the site asked for notifications is that there is a subtle "notifications denied" icon in the location bar. For the maybe two sites where I have enabled notifications I just click it and allow them.
Some websites will check whether you have notifications enabled and spawn an in-page pop up requesting access before they trigger the actual, native browser request.
The best response to those websites is closing them and blocking them in your DNS blacklist to be honest. Either that, or full their newsletter subscription box with a million fake email addresses.
On macOS you can disable notifications for any app in System Settings. When an app first requests it, you’ll get a system notification asking if you want to allow the app to send any.
On Safari you can even disable the option for websites to request notification access. It’s on the Websites tab in Settings.
Well, the user should be allowed to easily program it to send the notifications (or any other stuff that the web page may do) to a file (e.g. /dev/null) or to a pipe (e.g. a program that filters notifications).
I'd love to see this generalized to a toolkit in mobile and desktop/server operating systems. A year or two ago, I suggested calling something like it a "hellban" add-on, because my main use for it would be to improve the UX for software I can't really avoid by putting that software in an invisible cage. It would basically be a "swords into plowshares" version of a rootkit.
One could implement the same effects using Frida, but I imagined something more like a browser add-on repository, where users could submit modules for specific software/apps, or that would gatekeep device/OS-level functionality, instead of everyone having to create custom rules in a lower-level general-purpose toolkit like Frida.
There are lots of possibilities in this area for taking back some control of what's happening on one's devices by feeding procedurally-/ML-generated data when software tries to query sensors, GPS, camera/mic, etc. It would also often be useful for software testing, to make certain test cases more practical and reproducible by looping through recorded data.
I think this is a technical solution for a social problem.
Compare it with the "unsubscribe" button in spam newsletters that does nothing. Sure, fuck you, I will just block the unique email address you are using and you won't be able to contact me at all.
If everyone was playing nicely, we would not need it.
I think the fake data is more like “block and report spam”. Which is what I do for every email that I don’t want to see. I agree that there is no need to play nice. Companies are not respecting my time so they can suffer the consequences.
It's frustrating that the app knows you haven't provided it with exact location. Approximate location is usually sufficient and I wish android could just feed that into the app as an exact location.
So I'm building a build system with a permission system.
The permissions are checked at runtime and each time the permission is needed. (For example, if a build script tries to phone home twice, the build system will run the permission checker twice.)
In addition, the permission checker will have the option of delivering fake data and making the requester think they got permission when they didn't.
This is why I added that, even though it is much more complexity.
For now, all laws are location based because sovereignty is defined by geographical boundaries for historical reasons.
If you use "feed fake data" to avert those laws, I think that is ok. As an example, I am the criminal if I lie to an app to say I am in Pennsylvania to bet on sports. I don't think my phone manufacturer should conspire with law enforcement to prevent me from being able to lie to commit that crime.
I really like iOS’ “only while using the app” option for location data, or “give the app access to only these photos” and I wish that premise extended to other things conceptually, like “give access only to this subset of contacts”
Why? Only if you would reuse the same data multiple times, or if you use a unique random generator that is easily distinguishable from other data. So maybe don't use the 5x5 island, but when done right the approach shouldn't help fingerprinting?
I don't think this assessment is correct. No one said completely random data. It certainly could make fingerprinting possible (or, easier than no spoofing at all) if the right considerations are not taken.
In general any sort of intervention that moves you away from Joe average is bad news for fingerprinting.
More sophistication in this context often makes things worse not better. e.g. In this context volunteering info on every request (fake or random doesn't matter) certainly makes you unique, because the average user doesn't do that
I took issue with your use of 'makes'. Your statement incorrect. It could open someone up to fingerprinting if done incorrectly. It could also provide utility to a user.
The draconian rhetoric you are using is the same logic someone uses to advocate for no symmetric encryption because it can be implemented incorrectly.
Reiterating your basic fact about fingerprinting doesn't change this, or negate the rest of my statements you ignore because you think nuance and user requirements can be reduced to a binary.
GrapheneOS has features that allow this to various extents, for example storage scopes which trick the app into believing it has all the storage permissions it requested, or contact scopes which give an app access to whatever subset of contacts you decide on (including none). Similar feature exists for sensors and possibly others I've forgotten or am unaware of.
I think the more important thing is coming up with a better way to do these things _without_ permissions.
The core issue of permissions systems in my mind is the user. All of the pop-up permissions boxes on phones are really nice, it's helpful that Android now removes permissions from apps if they're unused.
But that doesn't stop the average user from just hitting "yes" to permissions without reading them because they just want to use the app they just installed. It's exactly the same problem as nobody reading Ts&Cs etc. Our species has an apathy for this stuff.
We should really just be sandboxing the shit out of everything. On Android (as an example) if I install a file manager app, I can only give it access to _everything_. But also as a user, even if I could give it granular access, it's easier to just give it access to everything because it's...easier.
The location pop-up is nice, I usually hit "only while using the app" but I'm sure plenty of other people give their apps access to fine location data at all times. Is this a platform problem? Maybe Apple is right in being so strict about usage of data, even though privacy is just marketing/a selling point to them (I laugh if people think the world's richest company _genuinely_ cares about privacy on a human rather than financial level).
Feels like something a third-party password manager could handle. I would not expect Apple or Google to ever do this on their own initiative though. In fact they would probably disallow the third-party app from doing it, as it would likely violate some term of service or other. Neither Apple nor Google has any incentive to make it easy to pollute data, or foster the expectation that you have a right to obfuscation. If you started expecting it from apps you installed, I think you'd eventually start to expect it from Apple and Google themselves, and that'd be bad for them.
That's good because either way it costs them money.
Also fake data being more chaotic would be good because it would ultimately cause them to over filter and throw out real chaotic data, effectively over fitting their marketing efforts to slightly more average people.
Additionally, a good arms race would be fun here. Keep making the data more and more realistic each generation. Add an option to use plugin datasets so wallstreetbets can crowdsource fucking with investment banks (ie why is everyone suddenly spending all their time at targets?)
I was mulling the idea of building a "garbage telemetry producer" thing for Windows. It's a losing battle trying to keep up with new endpoints to block more and more often, and I imagine it's easier for folks to build and run a small program that constantly pushes out telemetry events.
If we poison the data maybe Microsoft will realize providing a true "all telemetry off" option would be easier (and cheaper for their bandwidth and storage budgets).
Here's an idea:
(medium-complexity) port of android to TCB which partitions /hardware/ (cpu-cache, RAM), on a per app basis. Android's app-based permissions API doesn't require too much work to do this.
My perspective:
Either cheap-monolithic-SOCs get really cheap, (for low end devices), with long-term-support, and low power, or compartmentalised architectures start to gain the traction that will kill of SOCs.
I used to share this sentiment until I offered similar to customers and it was rarely used beyond a quick glance to almost immediate, ‘I really need to see my x here to have a better sense of it…’
I found that people just generally lacked imagination for the most part and screenshots coupled with quick videos and/or demos did enough to incentivize them onto installing/evaluating using their environment.
I can see why this would be useful, but we already spend a lot of time chasing down data quality issues in AI/ML models and statistics as-is. We may be requesting permissions to workaround/correct GPS accuracy issues, comply with local regulations, or turn on a feature flag. For example, if you're on your home network I should hit HomeAssistant via a different route than if you're away from home. Or maybe local regulations require me to limit certain features, deny access, or confirm age. Or it may be necessary for fraud prevention, such as determining whether your account is being accessed from an unusual device or location.
I could see this leading to more data quality issues, legal liabilities, and difficult bugs. We should be able to deny access or provide coarser information (e.g., an age range rather than an age or a county/state rather than fine-grained GPS), and applications should be designed to handle those gracefully.
I understand all of those concerns, but... as a user they're not my problem.
For example I don't care about where I am and neither should you for legal issues or features. This results is situations like me going no holiday and the bank app failing to work/install because they don't have presence in X country. Wanna know if the usage complies with regulations or I want a feature? Ask me, don't guess.
Wanna know how to access my HomeAssistant? Ask me, because there's a ZeroTier network making HA available directly wherever I am.
For fraud prevention it's not necessary to know more of my tracking info. It just makes it easier for the company at the cost of privacy issues for me.
I get the developer's view here, it's harder when someone feeds you wrong data. Tough, we're supposed to deal with that as devs and maybe just ask the question directly rather than guessing through other means. You should be doing that already, because GPS is not always reliable, contacts change, people have complex lives in terms of which laws apply to them.
As a user, I don't care about your ML model. I care about not sending you personal info. Coarser info isn't good enough - you can convince me you actually deserve my real info, or you can get no info (preferable), or you can get fake info (alternative if you degrade or break my user experience because I wouldn't give you that info).
I understand there are some legit use cases for validated info. Unfortunately, targeted advertising and other types of profiling are also common use cases for the same info. It's a lot like MAC randomization on public wifi - it sucks, it breaks legit use cases, but it was needed because too many companies were using it to track people.
You should care. My point is give me coarser info or no info, but not fake information—and I say this as a researcher working on synthetic data generation methods to improve privacy. Fake information is a pain for developers _and_ users. Unreliable fake data has real, significant (and potentially disastrous) consequences that are often difficult to anticipate.
It sounds like the assertion here is that the data is used for reasonable purposes and improves the user experience. That's likely very true.
If I prioritize privacy over that better user experience, though, that should absolutely be something I'm allowed to do.
I might not want to give a stranger at a bar my real phone number, so I give them a fake one. Maybe this leads to a worse experience than if I just said "no thanks", but I really value the fact that I'm allowed to do that.
I recall holding off on WhatsApp for so long because they wanted access to my contacts to do anything really useful. With Exchange students it really became critical to have it, so I caved and gave Meta the data. I’m still a little mad about it. Clearly they could’ve made an app that did not require access to my contact information, but they wouldn’t.
I have long thought there should be a virtual sandbox available for apps that generates fake data to apps according to preset stories. Like, tell one app I am a rich bachelor spending time in french riviera and another I am homeless in New york. Spoof gps, wifi and whatnot data that fits the pattern to the app. (I know, it would be hard)
Point is to make the signal to noise on response too low for the scammers to deal with. Today, they can feasibly have a person look at every response and choose the most promising targets.
If auto respond to even 0.01% of scam email, they suddenly need to have tools to weave through ridiculous amounts of data. Expensive. Scam becomes negative ROI
That doesn’t seem like a good idea unless your goal is to burn down the current paradigm. And I’ll grant some people have arguments for doing so, but this doesn’t seem a productive way to go about it.
Either advocate for tearing the status quo out by its roots, hopefully with some inclination of what to put in its place lest something worse grow instead. Or demand transparent control w/ easily revocable consent ( or something along those lines.) Maximizing chaos and distrust and belligerent behavior beyond the already intolerable levels isn’t going to get a net improvement in things anytime soon.
I'm sorry, but I really don't hope this catches on. Fair that you don't want to share your data, and yeah, a Flashlight app should not need access to list of contacts, but please don't mess it up the data for us developers.
Example: We use information about the devices that access our web site (screen resolution, browser versions) to figure out how best spend our limited resources. This data is important to us.
On iOS it would be nice to have the possibility to enter a fixed/fake position so apps like Google Transit or the Weather app just work, without the need to turn on GPS.
Just this moring I was reading through the app permissions for the 51% state owned postal service package delivery tracking app they wanted me to install.
Not only would they collect my 'sexual orientation' (how I wonder?) but they also would 'share it with 3rd parties'.
GrapheneOS implemented this feature for the filesystem—called “Storage Scopes”—and a similar feature for contacts is in alpha. Apparently camera, microphone, and location are in progress.
This will only start a cat and mouse game between app developers and users feeding junk data. There will be statistical tells or artifacts in fake data that will be identified which will prompt vendors to improve the entropy or patterns it creates.
The only solution (for a non development/testing uses) is for applications to accept no as an answer.
> The only solution (for a non development/testing uses) is for applications to accept no as an answer.
Agreed; feeding fake data is not a substitute for writing good applications. However, that does not mean that feeding fake data is worthless. There are many uses (including, but not limited to, programmers/companies that have failed to write good applications; like you say, testing is also a use of such a thing).
I thought of this years ago and even tried implementing this but my knowledge that time was very limited. So eventually I gave up.
I think before android implemented their permission system, os like Xiaomi’d implemented their permissions by feeding fake data to the app in case user reject a permission.
I think that feeding fake data by default in case use reject a permission is not appropriate. There should be an option to do that (or, like I suggested, a way for the user to write programs to program it to feed whatever data they want), although I think that by default if a permission is rejected it should just provide empty data (e.g. an empty contacts list) or an appropriate error code (e.g. network error or disk error or cannot acquire satellite, just as though that error had actually occurred), rather than making up fake data.
Using top down regulation by app stores seems like a better way to deal with the issue of apps refusing to work without a permission that don't really need.
Imagine the amount of needless support requests that will be triggered by people accidentally pressing the wrong thing.
I would make the case that fake data isn't a sustainable model as it spend fuel and energy to support an activity that does not have meaningful contribution to society and the economy.
We should base our state of the art on best use of the finite resources we have.
Apps could just accept that and break. Food delivery app could show suggestions from the fake island, social media app could let your friends know you’re 6383km away, calculator app might switch to local currency conversion, etc.
Sometimes doing such things are deliberately what the user intended, which might be necessary if the app does not have its own options to specify what location you want, whether to avoid the social media publishing your location, or to specify your own currency conversions.
just put some warnings like "by selecting this option this application won't be able to access X, therefore some applications might not work properly".
Google will NEVER harm itself by supporting fake data feeds. The only reason G exists at all is because they can exploit the data they harvest from you. If you're given the power to poison that data Google implodes and the whole Android platform becomes extremely unattractive to other massive companies that live off of leeching your private data one way or another.
Yes, an OS built first & foremost for its users/customers would have LOTS of options like that. A mobile web browser built the same would support plugins from day 1. Etc. Etc.
But Android, Chrome, Windows 10+, iOS are ABSOLUTELY not built for their users. They're built as vehicles that enable other services from a slew of big names and it's essential for these platforms to ensure users are NOT given the power to fight against those services.
It would be beneficial to Google if they were to get your information but not just hand it out to any app that gets installed. Google can have my contacts and location information. But if I download some random app, it doesn't need my exact location.
Maybe it needs a rough location like within 100km of my real location. Android could feed it a fake location and say its exact.
> when a bad thing posing as a good thing asks if you want to let it do bad things or not, it should also ask if you would rather just do bad things to it instead.
I've advocated this for a long time, with the added proviso that it must be impossible for apps to figure out whether you chose to feed them fake data or not.
An unfortunate characteristic of data fuzzing is that given sufficient alternative sources of information it's actually reasonably easy to filter out the noise. A key issue is whether the noise refers to subjects which are entirely generated or which exist in the world, though even this only incrementally adds to the noise level.
Take the case of contacts. If I were to use a random ID generate to create contacts and feed those to an app, then with sufficient independent sources of data the app could choose to reject any contact which appears only once. If you happen to be the One And Only True Friend of an Orphan Hermit, then yes, that rule would exclude that data, but if you happen to be personal BFFs with Beyoncé Giselle Knowles-Carter, the system could not only independently validate that such a person exists, but even that your own reported contact information is, say, directly personal rather than a mass-media point-of-contact.
The other problem is that even with generated data, so long as that is intermixed with authentic data, it's often possible to tease out signal from noise. A case here might be with browser history. There are Web browsers which generate spurious traffic. This is "real" in the senses both that it refers to actual online Web resources, and represents traffic generated by your browser, but is generated in the sense that it does not represent volitional activity on your part. However, so long as both activities are present, your actual browsing patterns exist (so that if a concern is that you did in fact visit <https://example.com/xyz>, it would be possible to determine that some entity (genuine or simulated) did so, and that if the URL were simply randomly generated or visited, odds are reasonably low that that URL would appear within a browser history.
Similarly, in a combination of actual and faked contacts, if the question is "did the subject include Known Individual in their contacts", that fact can still be determined, and if statistically improbable, particularly amongst a group of individuals all including Known Individual in their contacts, the general inference of an actual relationship is strong.
The case of being able to entirely separate actual and generated information changes this dynamic ... slightly, but not overhwhelmingly.
My own upshots:
- Data chaffing and fuzzing are hard.
- The signal one wishes to obscure often leaks.
- Entirely-fabricated data is usually reasonably evident, especially in aggregate.
- Whilst some degree of chaffing has some value (signalling, protest, cost-increasing), the most effective course of action is likely effective privacy legislation and regulation.
I really wish there were more effective individual actions. I increasingly feel that there aren't, other than opting out entirely. (Something I increasingly practice myself, FWIW.)
This will just make app developers angry at your platform. If this is just some hack users are doing apps will increasingly use attestation to make sure you are not feeding them fake data.
Apps want to be able to give users a good user experience and if they are given fake data users will get angry that the developer's app is broken and leave 1 star reviews. Denying permissions and letting apps know something is denied is much better because they can adapt their app's experience to work around it.
This doesn't make sense. If the dev asks permission that creates good experience, the user is incentivized to give real data. Example, gps is required to navigate or find near by service. The user will happily provide.
But if you require gps to make a post, the user does not benefit from it. Unless they have an incentive to share their location, they do not need to give real data. Maybe the dev should give an explanation. If they receive a one star review, the developers should use it as feedback.
>But if you require gps to make a post, the user does not benefit from it.
This behaviour would get an app rejected from the app stores. The app stores require you justify doing things like that and they require you to gracefully degrade if a user denies a permission.
Apps don't want to give users a good experience. Apps want to milk users for all the data they posses.
Denying permissions remains an option, but some digital trash will refuse to work unless you give them your address book and location history. Those apps deserve to be fed fake data.
Clicking the "feed fake data" button is an explicit alternative to denying permissions, it's not a replacement.
> Clicking the "feed fake data" button is an explicit alternative to denying permissions, it's not a replacement.
Yes, it should be a separate option. However, instead of "feed fake data", perhaps the options should be "Allow", "Deny", and "Custom"; if you select "Custom" (which you can do also when installed or in the settings menu, even when the app is not running) then the user can program their own handler of the data requests, and can also choose from a list of such programs which have already been programmed before.
If you are building an app platform the whole point is to get as many quality apps on it as you can. Telling app developers to go pound sand and not make an app for your platform is your loss.
this is what i don't understand about browser fingerprinting. why would you design a browser to allow fingerprinting in the first place? there's no legitimate reason for a website to know what plugins or fonts i have installed, etc.
As another app developer, I don't care. You aren't meant to request permissions you don't legitimately need for the app to function. Everyone understands that a map or weather app needs access to precise location, or that an app that takes pictures needs access to the camera. But games requesting storage or location or microphone or contacts, and refusing to run without these permissions? They should rightfully get what they deserve.
Heck, even the internet access (android.permission.INTERNET) should be a runtime permission. A fakeable one, too.
GrapheneOS, at least, does make Internet access a permission you can turn off. It even goes one step further in that you can turn it off at install time. This is something that should be in stock Android.
For devices which don't have GrapheneOS installed but can be rooted, a firewall like AFWall+ is an option. It's not entirely as secure as just not granting the permission in the first place (I know of at least one way to bypass AFWall+, if an app is prepared for it), but it's still a good option.
As an app user, I want you as an app developer to have no control whatsoever over how I use your app and no way whatsoever to know if any data it gets from my device is real.
For Android versions 8-12 there's XPrivacyLua, which will override the system APIs to feed apps fake data if you wish to do so. It requires a rooted device, obviously, but its predecessor worked like a dream last time I've tried it.
These days I'm more of a "one star review and uninstall" kind of user but I've had good experiences with XPrivacy.
Sadly, XPrivacyLua has been discontinued. I don't know any alternative for modern Android releases.
If users see value from your product after providing real data, they won’t provide fake data. There’s no reason for certain apps to request for permissions to data that in turn provide no value to the product.
I think it's probably illegal to grant an app permission to access contacts in Europe or the UK as it's GDPR covered personal data about others who have not given consent.
Just don't grant it permissions if you don't want to. And if it refuses to function without (for no good reason), then don't use the app because it's scammy.
Is there some other situation I'm missing here? Like is there some legitimate app people need to install that won't work if you don't grant it unneeded permissions?
On Android I've had so many apps crash, get stuck in a loop, or refuse to run when a unnecessary permission is denied. And it's not just scummy apps, things like the Fitbit app used to go ballistic if you denied them access to your contacts. In an ideal world Google would force the developers to handle such cases gracefully. But for whatever reason, they don't care.
Though like any technical solution trying to fix a culture problem, the fake data generation won't be all roses either. Users will inadvertently enable it and then the app won't work properly and they won't know how to fix it; Think a calendar app where you enabled the fake calendar access by mistake, so you see random crap instead of your expected schedule. Where do you go to fix it? The app doesn't know you're feeding it lies, that's the whole point, so it can't help. So in Android fashion you have to dig twelve levels deep in convoluted menus to revert that. Assuming you even know where to look or what the problem is.
Unpopular opinion: No, it shouldn’t. That would be unethical. Aggregating cohorts of data to determine what you might or might not like to buy, and vigorously safeguarding that data since you know it will cost your business billions in market cap if it is exposed is far more reasonable. Yours is just a passive aggressive way to “ruin Facebook”.
If you want to ruin Facebook, push for legislation. Do it the right way.
Gosh, you mean big corporations will be forced to compete on the basis of the quality of their products – instead of their ability to aggregate, destroy, and exploit the privacy of their users?
Also, and this was even longer ago, apps could not require users to have “an account” in order to run. I remember (this was over a decade ago) my company making a product change that forced users to have an account in order to function and we got (rightfully) rejected by the AppStore for this. It seems they must have softened this stance because I am seeing more and more apps that require an account to function.