When an app asks for permissions, it should have a “feed fake data” option | Hacker News Reader

When an app asks for permissions, it should have a “feed fake data” option

mastodon.gamedev.place

1,102 pointsjanandonly395 comments

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.

> 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.

Apple used COMMON SENSE? That's incredible. Google would never do that

One time Apple asked us why we needed bluetooth permission for an app that had the singular purpose of using bluetooth "iBeacons".

> 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.

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.

Would that be workable?

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.

    > How could a banking app run without an account?

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.

Just because maps are based on public data doesn't mean that making them doesn't cost money.

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.

They’re lying to you then, because “friends that work for Apple” have no say in the App review process.

I cannot wait for the DMA to take effect early next year so I can install ANY other app store.

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.

Many online games do not require an account. Ones that do not store things like level progression or inventory between play sessions.

You need an account for WoW, but not Unreal Tournament, to use 90's examples.

> 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.

Facebook^W Meta is scum.

> 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.

Worse, you can't even initiate conversations; if you've denied contacts access, the other user has to message you first.

At least for me on Android, which is wild.

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.

That's not true for me on iOS. I denied it access to my contacts, and I can still start a new conversation by entering a recipient's phone number.

https://wa.me/+theirnumber

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?

> Would you know whether to trust elonmusk@twitter.io, without looking it up?

I would hate to dismiss someone for a troll only to realize they are not the real elon musk

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.

True freedom is freedom to do things that others might not like.

Like the freedom to operate a service that only accepts real location data?

As long as I have freedom and means to feed it fake data as real data :)

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.

1: https://atp.fm/542

Is it though?

If you want Google Photos to back up your photo library… it needs full access to everything to do that.

Very very few apps should need full photo access. But photo backups/cloud libraries are the one I can think of that do.

I was actually surprised no one on ATP brought that up.

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.

That's incorrect, I just tried it on iOS.

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.

Those tabs are new as of a few months ago.

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.

[1] https://imgur.com/a/l2sErQQ

[2] https://support.google.com/photos/thread/1939628/use-ios-goo...

[3] https://old.reddit.com/r/googlephotos/comments/rhoyb1/google...

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.

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.

Seems weird that an app needs to be able to tell if it got access to all or just some photos

Agreed, so obnoxious, especially since as you say the OS has a “select some photos” permission setting that they should be able to play nice with.

> 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.

> being no data

"but sure you have photos on your phone, if your phone tells me there aren't any then it's lying"

Yeah, fake data. I remember there was an Android Xposed(?) mod that did that, was quite funny to see heaps of fake names in contact list

else not be allowed in the App Store, a stick apple is more than happy to wield

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.

Unless you are some big name that they can't afford to lose

It's not a tech problem though, and tech culture is already too eager to find technical "solutions" to societal and organizational problems like this.

Or just not use the app…

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.

https://developer.apple.com/app-store/review/guidelines/#dat...

  (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.

I also like the part where it is harder for a device to call home if it doesn't have wi-fi at all.

> 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.

That lies in gesture of app developer and that will not happen for the apps you'd want to use that feature (or the fake data feature) with.

> 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).

In this case the users of the app are our clients employees. No location access is not an option for them.

Nobody wants to call in their location, nor do our clients want to setup some process for that.

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.

> it was Apple’s policy that apps cannot punish users or exit() the app in retaliation for them denying a permission

It's been the same since runtime permissions on Android, which was like Marshmallow i believe

https://developer.android.com/training/permissions/requestin...

Policy is one thing, but enforcement is what really matters. Do Google Play reviewers actually reject apps that hold core functionality hostage?

If apps are threatened with fake data, they will quickly find it's better to let users opt out gracefully, no regulation required.

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.

Couldn't find another place to put this comment but how do I get the privilege of posting an Ask HN discussion starter thread for startup advice?

I believe it’s just a thread with “Ask/Show/Tell HN:” in its title.

How that works with banking apps? What can they do without an account? Maybe a web view to the home page of the bank.

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 was Apple’s policy that apps cannot punish users or exit() the app in retaliation for them denying a permission.

Sounds a lot like EU's GDPR: you must show a cookie popup but if the user denies it then you must still serve the content.

(When companies grow large enough, they become suspiciously similar to governmental regulators.)

Apple allows Bloomberg even though it requires an account.

> 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

FWIW: Rooting seems fairly easy at this point in time, at least for pixel devices.

Flash with magisk, install Universal Safetynet Fix (https://github.com/Displax/safetynet-fix/) and you're passing safetynet / play integrity API.

I haven't come across a single app that doesn't work due to root currently, but I limit my installed apps.

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.

Thank you, I rooted my phone a few days ago and have been putting off fixing safety net.

But that worked and was absolutely painless.

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.

FWIW,I just installed GrapheneOS this week and banking apps have been working fine (though no Google pay).

Also, as a sibling comment mentioned, I have used magisk + safety net fix in the past, and had no issues with banking apps or Google pay.

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.

LineageOS already had this feature in Cyanogen as the Privacy Guard. It was taken out because of pressure from Google.

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.

Edit: source here https://news.ycombinator.com/item?id=28096873

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.

Pressure from Google?

I myself removed that feature because the effort to have it was more of an hassle than anything else.

You have a source on that? I used to be a lineageOS user and I always wondered why privacy guard disappeared.

>region-locked apps

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!

>no, that's impossible

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

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 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."

>to the detriment of the user

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.

“If someone asks you a question they’ve got no business asking, you’re under no obligation to tell them the truth.” — Leonard Schiffman

(From: “Blend me in: Privacy-Preserving Input Generalization for Personalized Online Services” https://drive.google.com/file/d/10OmoqMmHFcb7PsQtaU_GW4aCAJe...)

> 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.

Google Maps: “Turn right”

Guy driving alongside the ocean: “ok”

Car: *splash*

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.

Maybe just seed it with very sensible default settings like "send real data when asking for directions"?

The people who are savvy enough to jump through those hoops are savvy enough to rock a phone that is modded to feed fake data already.

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 savvy, but I'm also lazy.

>Google Maps: “Turn right”

>Guy driving alongside the ocean: “ok”

>Car: *splash*

This seems like a learning opportunity. Or a Darwinian opportunity. Either way, self-solving.

That feeling when hacker news user endorses eugenics as long as its just stupid people.

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.

Eugenics is artificial selection. This would be natural selection. Clear difference.

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.

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.

> This seems like a learning opportunity. Or a Darwinian opportunity.

Not for the passengers.

It was when it happened to me, though yes, Darwinism for the passengers is much less valuable.

Then make the setting a power-user opt-in, so that the uninitiated wouldn't even see the option.

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.

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.

That makes sense, though that's highly specific to where you live. Where I live it works perfectly so I have no reason to use Google Maps at all.

So is Google Maps (on Android at least, or at least it was 10 years ago when I last did that).

Well, you don't really need to feed fake GPS data to have Google Maps make you drive into the ocean or things like that.

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.

> on iOS, you cannot distinguish if you were granted a permission or not.

This isn’t correct. For instance, accessing location services provides CLAuthorizationStatus:

https://developer.apple.com/documentation/corelocation/claut...

…and push notifications have UNAuthorizationStatus:

https://developer.apple.com/documentation/usernotifications/...

…and health data has HKAuthorizationStatus:

https://developer.apple.com/documentation/healthkit/hkauthor...

…and contacts has CNAuthorizationStatus:

https://developer.apple.com/documentation/contacts/cnauthori...

…and photos has PHAuthorizationStatus:

https://developer.apple.com/documentation/photokit/phauthori...

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.

> but you cannot distinguish between limited access and full access

I believe you can check whether you received limited photos access: https://developer.apple.com/documentation/photokit/phauthori...

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.

How does that work for location?

Also, an empty folder with photos is almost certainly implying lack of permissions. Very few people never took a picture.

I think they're just full-on mistaken, and it is possible for the app to distinguish between access levels: https://developer.apple.com/documentation/photokit/phauthori...

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

You can also select a subset of pictures to grant the app access to, which makes the heuristic fall apart if you properly manage it as a user.

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

They are wrong; you can determine whether you have permission in iOS. For location, you have CLAuthorizationStatus:

https://developer.apple.com/documentation/corelocation/claut...

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.

This is obviously untrue and can be seen by almost any app that asks for notification access.

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. ```

For microphone access:

```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.```

All apps seems like not very useful

It's not ideal, per app would be preferable, but at least global can be a toggle in the global quick settings UI.

> 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)

WeChat has this feature.

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:

https://www.woshipm.com/pd/2612572.html

Another article with slightly worth page experience:

https://jingyan.baidu.com/article/c275f6ba22f54ca23d7567c6.h...

Wechat itself asks for GPS data upon startup. On Android if you deny the permission the app closes.

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.

[1] https://news.ycombinator.com/item?id=36486587

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?

I think he's saying the JavaScript nag message every time you visit one of these sites is annoying.

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.

You can disable notifications globally. I did it. Zero regrets. My browser is a hypertext document viewer, not an operating system.

Here's also a userscript that removes the service worker API from Chromium browsers:

    // ==UserScript==
    // @name         Remove service worker API
    // @namespace    http://tampermonkey.net/
    // @version      0.1
    // @description  try to take over the world!
    // @author       You
    // @match        https://*/*
    // @grant        none
    // @run-at       document-start
    // ==/UserScript==
    
    delete Object.getPrototypeOf(navigator).serviceWorker;

In Firefox, iirc you can disable that API somewhere in about:config.

Why?

I don't enable notifications and it's fine, I've never had a problem.

If you don't want notifications, why would you still want the website to send 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.

So ideally this would stop that from happening.

It is so common that r/assholedesign has a specific rule not to post that kind of asshole design (because it is now boring).

But sites that do it are hostile and should just be blocked. What other shenanigans are they pulling?

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).

There is an app for creating data-poisoning contacts: https://f-droid.org/en/packages/me.billdietrich.fake_contact...

Source code: https://github.com/BillDietrich/fake_contacts

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.

Android introduced the approximate location option (I believe it was in version 11) as a per-app toggle in the permission settings. https://support.google.com/accounts/answer/6179507?hl=en#:~:....

That only disables the permission or increases the uncertainty, it doesn't really feed fake data.

If apps refuse to work unless you provide detailed location info or other permissions, there's no "provide fake data" option like the post suggests.

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.

Apps can use GeoIP to get an approximate location most of the time, and there's nothing Google can do to prevent it.

There's a significant difference between "Your ISP's IP block suggests you are near Stockton,CA" and "Your exact location +/- 5 meters"

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.

I love this idea.

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”

Unfortunately this approach makes you quite unique for fingerprinting

> Unfortunately this approach makes you quite unique for fingerprinting

As opposed to sharing your actual latitude,longitude and microphone readings?

Or can. Numerous anti-Fingerprinting systems have been discovered to make you more fingerprintable.

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?

Exactly. Just pick a random location on the planet and have it randomly wander. Have a consistent but (statistically) different location per-app.

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.

>No one said completely random data.

It doesn't have to be random to be a problem.

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.

That might be fine. He's the guy who says he's on Mount Kilimanjaro. Where is he actually? Don't know. IP address looks like France.

not if its an os feature.

maybe we can also provide another option: feed this shared pool of fake data instead.

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.

Hell yeah, fake data should totally be an option!

This could be achieved with something like Xposed, a cool project is https://github.com/M66B/XPrivacyLua.

I actually made a "clone" with the option to generate data per permission as a school project, good times

That's the guy who made the first successful indie games within a deep forest and knytt. https://nifflas.ni2.se/games/

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.

This wouldn't stem the requests; it would just lead to data analysts figuring out how to algorithmically filter the junk data.

... which is fine. Incentives to refine data analysis are always welcome.

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.

Jailbreaks on iOS have this, I wish apple would allow us to have more control.

"Apple knows what's good for you" has been their motto since the beginning of times which is why I never had an Apple device.

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)

Similarly, I'd like all the scam emails to be auto responded to with fake data rather than black holed

I'd prefer to have an option for the provider to send a genuine "invalid recipient" (554) auto-reply for addresses we mark as spam.

I think zoho does this

Sometimes I do this with emails in my spam folder, but nothing interesting ever happens

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

Someone had that on Android a decade ago. I saw it demoed. Whatever happened to that?

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.

I am surprised there isn’t a browser that opens shadow webpage(s) that is unrelated but a peer to a website you are visiting.

Perhaps it’s the ad companies that need to be fed fake data not the app / site.

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'.

https://play.google.com/store/apps/details?id=be.bpost.mybpo...

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.

https://grapheneos.social/@GrapheneOS/110382189104598979

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).

Brave does something similar but as a browser against websites: https://brave.com/privacy-updates/4-fingerprinting-defenses-...