|
| firefoxd wrote:
| 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
| jasec57322 wrote:
| 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.
| gigel82 wrote:
| 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).
| shadowgovt wrote:
| 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.
| edrxty wrote:
| 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?)
| yoyopa wrote:
| 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.
| landgenoot wrote:
| 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.
| ImaCake wrote:
| 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.
| ryandrake wrote:
| 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.
| knallfrosch wrote:
| Apple allows Bloomberg even though it requires an account.
| alickz wrote:
| > 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...
| curt15 wrote:
| Policy is one thing, but enforcement is what really matters.
| Do Google Play reviewers actually reject apps that hold core
| functionality hostage?
| grishka wrote:
| > 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.
| flangola7 wrote:
| 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.
| chefandy wrote:
| 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."
| scarface_74 wrote:
| Or just not use the app...
| post-it wrote:
| 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.
| leshenka wrote:
| > 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
| rmorey wrote:
| else not be allowed in the App Store, a stick apple is more
| than happy to wield
| grishka wrote:
| 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.
| wruza wrote:
| So you and me have both worlds to choose from (not gonna
| reiterate pros/cons hundredth time). You are living in
| yours, but I have to lose mine.
|
| By me I mean all those people who chose Apple for what it
| is and ignore Android for what it is, with regards to
| what we're talking about.
|
| You have no real problem, only intrusive ideology. Please
| relax and leave us alone. We'll speak for ourselves when
| we feel wronged.
| grishka wrote:
| 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.
| [deleted]
| plorkyeran wrote:
| 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.
| NekkoDroid wrote:
| Google Play Store begs to differ
| grishka wrote:
| Google Play's rules on things like UGC are much more
| relaxed to begin with.
| idle_zealot wrote:
| 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.
| scarface_74 wrote:
| 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.
| pierat wrote:
| I've argued before that when companies retain control of
| the device after the sale, that it should not be legally
| classified as a sale.
|
| It should be enforced as a _rental_.
|
| Either I own my property and control my property, or it's
| _not_ my property. If not mine, whose is it? All we need
| to look is who controls it then.
|
| This is all first-sale doctrine stuff. And I don't
| believe any new laws need be made to enforce this.
| Dylan16807 wrote:
| They didn't say not allowed on devices, they said not
| allowed in the app store. Your complaint is valid but
| completely off topic.
| l33t233372 wrote:
| What if I (like so many others) want my device
| manufacturer to retain some kind of control of my device
| after sale?
| grishka wrote:
| You will act as if app store is still the only way to
| install apps on your iPhone.
| l33t233372 wrote:
| If you don't like a product, just buy a different one.
| bithaze wrote:
| > It's not okay to have to jailbreak the thing to make it
| usable.
|
| I guess we'll have to tell millions of users that their
| iPhones are all unusable, then. Imagine the shock!
| grishka wrote:
| 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.
| l33t233372 wrote:
| This sounds like a good thing; the sanctions are working
| as intended.
| curt15 wrote:
| >This sounds like a good thing; the sanctions are working
| as intended.
|
| Whether the effect is "good" depends on if you think
| someone's device should serve its user or some
| government.
| grishka wrote:
| Did sanctions really intend to affect regular people who
| have exactly zero say in the matter though?
| plorkyeran wrote:
| That is what sanctions do, so either no politician has
| ever thought about the implication of sanctions or it's
| an intended effect.
| realusername wrote:
| Unless you are some big name that they can't afford to lose
| Swanlyk2 wrote:
| 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?
| wruza wrote:
| I believe it's just a thread with "Ask/Show/Tell HN:" in its
| title.
| aftbit wrote:
| 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.
| skinner927 wrote:
| 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.
| plagiarist wrote:
| I also like the part where it is harder for a device to
| call home if it doesn't have wi-fi at all.
| qwerpy wrote:
| 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.
| progman32 wrote:
| Esphome is also good to learn about here.
| ilyt wrote:
| > 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.
| TechBro8615 wrote:
| > 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.
| rollcat wrote:
| > 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.
| eganist wrote:
| 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.
| gruez wrote:
| 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.
| davchana wrote:
| 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:
|
| http://spa.bydav.in/num2wa.html
| j1elo wrote:
| Alternatively on Android, the app "Click to chat" is a
| tiny utility that directly opens up a WhatsApp chat with
| any given number:
|
| https://play.google.com/store/apps/details?id=com.triangu
| loy...
| eganist wrote:
| The fact that this is necessary is _wild._
| pydry wrote:
| https://wa.me/+theirnumber
| LastNevadan wrote:
| 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.
| furyofantares wrote:
| > 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.
| [deleted]
| iamcalledrob wrote:
| 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.
| Wicher wrote:
| 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.
| rollcat wrote:
| > 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?
| riwsky wrote:
| > 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
| pmontra wrote:
| How that works with banking apps? What can they do without an
| account? Maybe a web view to the home page of the bank.
| danielhlockard wrote:
| 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.
| lldb wrote:
| 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.
| crazygringo wrote:
| 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.
| labcomputer wrote:
| 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.
| petesergeant wrote:
| Seems weird that an app needs to be able to tell if it got
| access to all or just some photos
| tobr wrote:
| 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
| spacebanana7 wrote:
| 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.
| omniglottal wrote:
| 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.
| wlesieutre wrote:
| 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."
|
| 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.
| Aulig wrote:
| 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 :)
| ksala_ wrote:
| 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 [...]
| ryandrake wrote:
| 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.
| amelius wrote:
| > 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.)
| duxup wrote:
| > 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.
| dodgson wrote:
| 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).
| duxup wrote:
| 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.
| wruza wrote:
| 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.
| kmoser wrote:
| 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.
| j1elo wrote:
| 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.
| freedomben wrote:
| 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.
| ryandrake wrote:
| 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.
| freedomben wrote:
| Yes, the comment I was replying to specified that they
| are like the map app with no other functionality:
|
| > _I am thinking of a logistics application that I wrote
| that requires location access. It effectively serves no
| purpose without location access._
| mormegil wrote:
| > 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.
| kccqzy wrote:
| 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.
| kilolima wrote:
| 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.
| ryandrake wrote:
| 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.
| jrumbut wrote:
| > 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.
| immibis wrote:
| Apple used COMMON SENSE? That's incredible. Google would
| never do that
| phreack wrote:
| Keep in mind GP mentioned this was over a decade ago.
| Common sense is way less likely to exist at scale.
| floomk wrote:
| > 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.
| matthewfcarlson wrote:
| If you were protesting a speeding ticket, I suspect the
| defense of "the guy next to me was going even faster"
| wouldn't go very well.
| marvin wrote:
| You're celebrating the possibility that EU regulation
| will remove Apple's ability to enforce good user
| experience?
| [deleted]
| Brian_K_White wrote:
| Yes. Of course. Apple do not enforce anything like a good
| user experience. They enforce a good Apple experience.
| V__ wrote:
| Is the user experience on Mac bad? Macs let you install
| non-store apps, and somehow it works out fine.
| floomk wrote:
| 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.
| Dylan16807 wrote:
| 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.
| pessimizer wrote:
| > 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.
| codeguro wrote:
| 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.
| riwsky wrote:
| If open doors did a better job of UX than apple, then you
| would have been using Android instead of iOS in the first
| place
| floomk wrote:
| 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.
|
| So in the end everyone loses, except Apple.
| yesimahuman wrote:
| 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.
| devilbunny wrote:
| Let me push back against that a bit.
|
| 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.
| extragood wrote:
| 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.
| andrekandre wrote:
| > 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
| Dylan16807 wrote:
| > rules for thee but not for me
|
| "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.
| ethanbond wrote:
| 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.
| Y_Y wrote:
| This has a nice demonstration at the following link
| (which was on hn recently):
|
| https://novehiclesinthepark.com/
| floomk wrote:
| 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.
| ethanbond wrote:
| 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?
| floomk wrote:
| 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.
| ethanbond wrote:
| The point isn't to strive for equality, it's to curate a
| healthy ecosystem.
|
| Sure, the world is rife with ethical concerns.
| EA-3167 wrote:
| 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?
| freedomben wrote:
| 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.
| mfashby wrote:
| Was that DaTuner? I got really annoyed by that too.
| jddj wrote:
| I only go to F-droid for these utility apps.
|
| Guitar tuners, flashlights, QR scanners, etc. Open source
| hobby-sized projects which are done when they're done.
| jadbox wrote:
| 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.
| Gareth321 wrote:
| I cannot wait for the DMA to take effect early next year so
| I can install ANY other app store.
| lilyball wrote:
| They're lying to you then, because "friends that work for
| Apple" have no say in the App review process.
| avar wrote:
| > 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.
| jollygoodshow wrote:
| 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
| samtho wrote:
| 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.
| zzo38computer wrote:
| > 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).
| 111111IIIIIII wrote:
| Impossible. Politically impossible.
| jasonmarks_ wrote:
| As an app developer I do not like this idea. You want to break
| the contract on what that permission is intended to be.
|
| ("Weather the Trip" road trip weather app for the U.S.)
| oh_sigh wrote:
| I'm going to write a free/no-ad version of this app solely out
| of spite for this kind of viewpoint.
|
| Be on the lookout for my app, "Weather Trip Report" app in a
| few weeks.
| jasonmarks_ wrote:
| anonymously? where is your honor?
|
| I think I'll win more share of the U.S. market _wink nudge
| nudge_
| grishka wrote:
| 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.
| jasonmarks_ wrote:
| > Heck, even the internet access
| (android.permission.INTERNET) should be a runtime permission.
| A fakeable one, too.
|
| That would be something for sure
| [deleted]
| Sophira wrote:
| 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.
| barnabee wrote:
| 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.
| jasonmarks_ wrote:
| Great :thumbs up: it does that
| [deleted]
| jeroenhd wrote:
| 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.
| rcstank wrote:
| 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.
| [deleted]
| halfstep wrote:
| 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.
| crazygringo wrote:
| 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?
| halfstep wrote:
| 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.
| jeroenhd wrote:
| 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.
| halfstep wrote:
| Yeah that's fair. It feels like we're in an anti-pattern
| arms race and choosing to not participate is a valid
| call.
| quickthrower2 wrote:
| 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?
| grishka wrote:
| 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.
| zzo38computer wrote:
| 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).
| jeroenhd wrote:
| 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.
| kevincox wrote:
| 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.
| OJFord wrote:
| 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?
| maxk42 wrote:
| I think he's saying the JavaScript nag message every time you
| visit one of these sites is annoying.
| latexr wrote:
| 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.
| hermannj314 wrote:
| 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.
| Misdicorl wrote:
| Similarly, I'd like all the scam emails to be auto responded to
| with fake data rather than black holed
| gigel82 wrote:
| 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.
| aembleton wrote:
| I think zoho does this
| immibis wrote:
| Sometimes I do this with emails in my spam folder, but nothing
| interesting ever happens
| Misdicorl wrote:
| 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
| dirkragnarok wrote:
| Brave does something similar but as a browser against websites:
| https://brave.com/privacy-updates/4-fingerprinting-defenses-...
| [deleted]
| d_sem wrote:
| 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.
| notsahil wrote:
| 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
| johnwheeler wrote:
| 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.
| 23B1 wrote:
| 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?
| rcstank wrote:
| Legislation will just hurt the little guys trying to start up.
| Once so much red tape is involved, it's very difficult for
| innovation and competition.
| 23B1 wrote:
| It's unclear to me how the inability to hoover up data and
| exploit users' privacy would prevent someone from creating an
| innovative experience.
| memeMaker wrote:
| 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
| OOPMan wrote:
| This is a nice ask, also completely unlikely to ever happened.
| sircastor wrote:
| 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"
| mr_frank_jaeger wrote:
| I love the idea of feed fake data!!! That would be an easy app to
| write, kinda like bouncer
| CalRobert wrote:
| lineageOS had this...
| sourabhv wrote:
| 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.
| zzo38computer wrote:
| 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.
| catchnear4321 wrote:
| > 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.
|
| shit in the ocean of piss? that's the plan?
| hvis wrote:
| Feeding actively random data can put you into a special category
| of users, though. If the recipient does any relevant analysis.
|
| So if one was looking to preserve privacy and reduce one's own
| track-ability, sending ambient sounds and 5x5 island location
| might work against that.
| ineedasername wrote:
| 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.
| fnord77 wrote:
| any browser plugins do this for fingerprinting mouse movements?
| corn13read2 wrote:
| Jailbreaks on iOS have this, I wish apple would allow us to have
| more control.
| activiation wrote:
| "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.
| techwizrd wrote:
| 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.
| thaeli wrote:
| 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.
| gameman144 wrote:
| 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.
| viraptor wrote:
| 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.
| jwr wrote:
| 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.
| sircastor wrote:
| >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)
| gavinhoward wrote:
| 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.
| jklinger410 wrote:
| Yeah man, totally.
| karaterobot wrote:
| 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.
| beefield wrote:
| 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)
| paradite wrote:
| 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...
| theawless wrote:
| 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. ```
| theawless wrote:
| 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.```
| hoffs wrote:
| All apps seems like not very useful
| thaeli wrote:
| It's not ideal, per app would be preferable, but at least
| global can be a toggle in the global quick settings UI.
| Havoc wrote:
| Unfortunately this approach makes you quite unique for
| fingerprinting
| enriquto wrote:
| > Unfortunately this approach makes you quite unique for
| fingerprinting
|
| As opposed to sharing your actual latitude,longitude and
| microphone readings?
| awegio wrote:
| 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?
| kevincox wrote:
| Exactly. Just pick a random location on the planet and have
| it randomly wander. Have a consistent but (statistically)
| different location per-app.
| immibis wrote:
| 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.
| PaulHoule wrote:
| Or can. Numerous anti-Fingerprinting systems have been
| discovered to make you more fingerprintable.
| sleepybrett wrote:
| not if its an os feature.
| nonplus wrote:
| 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.
| Havoc wrote:
| >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
| balaji1 wrote:
| it seems a bit of unrealistic expectation, users spoilt from the
| freemium generation
| [deleted]
| thih9 wrote:
| Is that practical though?
|
| 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.
| str3wer wrote:
| 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".
| zzo38computer wrote:
| 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.
| charcircuit wrote:
| 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.
| firefoxd wrote:
| 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.
| charcircuit wrote:
| >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.
| immibis wrote:
| Fine, then don't make an app. Your loss, not mine.
| charcircuit wrote:
| 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.
| jeroenhd wrote:
| 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.
| charcircuit wrote:
| >Apps want to milk users for all the data they posses.
|
| No, they don't. Please go and actually talk to app developers
| for their motivations. Look at the mission statements of the
| companies making the apps.
|
| >Those apps deserve to be fed fake data.
|
| Or you can just not use the app if the experience it offers
| is not something you want.
|
| >Clicking the "feed fake data" button is an explicit
| alternative to denying permissions, it's not a replacement.
|
| It's a worse alternative because apps can not properly handle
| this case unless they detect the data being fed in is fake.
| zzo38computer wrote:
| > 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.
| codetrotter wrote:
| > 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*
| easterncalculus wrote:
| 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.
| shadowgovt wrote:
| 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.
| easterncalculus wrote:
| 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.
| pavel_lishin wrote:
| I'm savvy, but I'm also lazy.
| afavour wrote:
| 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.
| oneeyedpigeon wrote:
| Maybe just seed it with very sensible default settings like
| "send real data when asking for directions"?
| internetter wrote:
| 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.
| bdcravens wrote:
| Then make the setting a power-user opt-in, so that the
| uninitiated wouldn't even see the option.
| fmx wrote:
| 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.
| chongli wrote:
| 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.
| 0ld wrote:
| 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
| hattmall wrote:
| 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.
| chongli wrote:
| 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.
| OJFord wrote:
| So is Google Maps (on Android at least, or at least it was 10
| years ago when I last did that).
| gruez wrote:
| >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.
| jsnell wrote:
| > 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.
| chongli wrote:
| 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.
| ianburrell wrote:
| 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.
| GravitasFailure wrote:
| >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.
| lexicality wrote:
| 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
| oneeyedpigeon wrote:
| 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.
| [deleted]
| lexicality wrote:
| 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...
| davidjfelix wrote:
| That feeling when hacker news user endorses eugenics as long
| as its just stupid people.
| _Algernon_ wrote:
| Eugenics is _artificial_ selection. This would be _natural_
| selection. Clear difference.
| GravitasFailure wrote:
| 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.
| evandale wrote:
| 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.
| rhn_mk1 wrote:
| It's not natural selection if you help it.
| [deleted]
| evandale wrote:
| >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?
| davidjfelix wrote:
| 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.
| _Algernon_ wrote:
| 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.
| [deleted]
| pavel_lishin wrote:
| > _This seems like a learning opportunity. Or a Darwinian
| opportunity._
|
| Not for the passengers.
| GravitasFailure wrote:
| It was when it happened to me, though yes, Darwinism for
| the passengers is much less valuable.
| severino wrote:
| 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.
| dumdumchan wrote:
| That's the guy who made the first successful indie games within a
| deep forest and knytt. https://nifflas.ni2.se/games/
| enachtry wrote:
| Am opinion so naive it's harmful.
|
| 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.
| aembleton wrote:
| 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.
| zzo38computer wrote:
| 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.
| squarefoot wrote:
| > 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.
| kubik369 wrote:
| 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.
| JimDabell wrote:
| > 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.
| epoch_100 wrote:
| > 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/ph
| authori...
| ciex wrote:
| 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.
| atorodius wrote:
| 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.
| rappatic wrote:
| 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
| JimDabell wrote:
| 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.
| H8crilA wrote:
| 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.
| jackson1442 wrote:
| 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.
| plagiarist wrote:
| I think they're just full-on mistaken, and it is possible for
| the app to distinguish between access levels: https://develop
| er.apple.com/documentation/photokit/phauthori...
| fbdab103 wrote:
| 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.
| safeimp wrote:
| 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.
| abrax3141 wrote:
| "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...)
| blincoln wrote:
| 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.
| Animats wrote:
| Someone had that on Android a decade ago. I saw it demoed.
| Whatever happened to that?
| crazygringo wrote:
| But why?
|
| 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?
| tredre3 wrote:
| 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.
| eredengrin wrote:
| 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.
| progbits wrote:
| 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.
| charcircuit wrote:
| >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.
| NoRelToEmber wrote:
| 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."
| aftbit wrote:
| >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.
| spockz wrote:
| 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!
| charcircuit wrote:
| >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
| kerkeslager wrote:
| > 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.
| AmericanChopper wrote:
| 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.
| charcircuit wrote:
| >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.
| AmericanChopper wrote:
| > 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?
| dagmx wrote:
| Netflix won't send your browser high resolution video
| unless your browser supports Widevine. Typically it'll
| restrict you to 480p iirc.
| AmericanChopper wrote:
| Which doesn't prevent you from taking screenshots... (and
| doesn't make it especially difficult to just capture the
| whole stream either)
|
| This whole screenshot point is silly to begin with,
| because screenshots aren't a form of piracy or copyright
| infringement.
| dagmx wrote:
| It prevents you from taking high resolution recordings ,
| whether they're screenshots or video.
|
| You either take a low resolution capture or the DRM layer
| prevents content from being displayed when recording.
|
| The legality of the subject is not something I'm talking
| about. You just asked for examples and I provided them.
| AmericanChopper wrote:
| 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?
| progbits wrote:
| Yes it does. HD Netflix in Chrome, Edge or Safari will
| result in black rectangle when you screenshot it.
| dagmx wrote:
| 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.
|
| Neither are "trivial" as you say.
| petesergeant wrote:
| 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.
| Nereuxofficial wrote:
| 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
| jcul wrote:
| 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.
| flutas wrote:
| 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.
| e4e5 wrote:
| 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.
| Groxx wrote:
| 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.
| rocho wrote:
| 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.
| jcul wrote:
| I think you need to hide root for Google wallet and some
| other Google services app(s).
|
| And wipe their storage / cache too so they start from a
| clean slate.
| kevincox wrote:
| 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.
| [deleted]
| fmx wrote:
| 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.
| anotherhue wrote:
| 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.
| LovinFossilFuel wrote:
| [dead]
| sspiff wrote:
| 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.
| kevin_thibedeau wrote:
| LineageOS already had this feature in Cyanogen as the Privacy
| Guard. It was taken out because of pressure from Google.
| jeroenhd wrote:
| 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.
| luca020400 wrote:
| Pressure from Google?
|
| I myself removed that feature because the effort to have it
| was more of an hassle than anything else.
| scrps wrote:
| You have a source on that? I used to be a lineageOS user
| and I always wondered why privacy guard disappeared.
| jeroenhd wrote:
| I found this:
| https://news.ycombinator.com/item?id=28096873
|
| Looks like Privacy Guard was dropped because the rewrite
| wasn't worth the effort.
| luca020400 wrote:
| Thanks for digging it up.
|
| Sometimes I can't comprehend how people come up with that
| stuff when it was already publicly explained how/why it
| happened :/
| scrps wrote:
| Thanks for that. Indeed, doesn't sound worth the effort
| to pursue it if google was mostly going in the same
| direction anyway.
| pciexpgpu wrote:
| 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.
| sircastor wrote:
| 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.
| dreamcompiler wrote:
| 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.
| dredmorbius wrote:
| 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 Beyonce 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 , 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.)
| YmiYugy wrote:
| 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.
| scarface_74 wrote:
| Yes because we need more government involvement because people
| don't have agency just not to use an app.
| jstummbillig wrote:
| 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.
| dweinus wrote:
| 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.
| cmdli wrote:
| 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.
| jstummbillig wrote:
| > 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)
| oliverulerich wrote:
| 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#:~:....
| jeroenhd wrote:
| 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.
| immibis wrote:
| Apps can use GeoIP to get an approximate location most of the
| time, and there's nothing Google can do to prevent it.
| aembleton wrote:
| 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.
___________________________________________________________________
(page generated 2023-07-08 23:00 UTC) |