@Tedspence @TheAtlantic revenue – I can see that, from a commercial perspective; actually, you'd aim at profit, not revenue, and yes, having ads costs you (if just through disgruntling customers, but also in administration, development and IT ops).
But there's no reason that *usage* is but a very weak proxy. Yet, I've uninstalled apps just because they kept adding new notification categories each update.
Who will happily follow a *new* notification after suppressing the last five categories?
@Tedspence It should go further, basically anything a decent test-mocking framework can do, this permission system should do. Not just null data, but your choice of random- or user-specified garbage. Not just routing notifications or outbound messages to the void, funneling them to a logfile.
It pays for itself when you can see what the "invite your friends" message actually says before committing, or teleport to San Jose when an app only allows online-cancellations for California residents.
Sounds like a good fearure for #GrapheneOS to work on 😁
@Tedspence Things like notifications are finally opt-in, unfortunately it's always all or nothing.
I need Android to save my settings so that I don't have to redo it when I switch phones and I need a bulk, yeah nah, option.
I see the point and agree - just adding some nuance:
In the authentication realm, relatively authentic location is pretty useful. As a defender, reducing the cost of an attacker faking the location of an MFA prompt trigger ... makes things worse. (May still be worth the trade-off, though - YTMMV)
Totally agreed - the tricky part is that an attacker can use the same layer to lie to an authentic app. (But that use case may be more rare than the ones you're advocating for!)
@Tedspence
To clarify, I'm thinking of the use case where the legitimate user who is being presented with an MFA prompt is also presented with the location that the original authentication request came from, as a rough way to discern MFA triggers initiated by an attacker who has guessed or stolen their password. The user is shown a location name, and/or map where the request came from. This is an MFA fatigue/bombing countermeasure (that isn't perfect, but does raise the cost to the attacker).
And to further clarify, I suspect that what you're after is worth this trade-off. It's just something that defenders need to keep in mind as well.
@tychotithonus @danieldurrans @Tedspence @revk
I think part of the issue is the paradox that the "only trustworthy companies" are also the ones most heavily engaged in surveillance, ads, and sales of data... sort of like "Hey that's a nice phone you've got there, it'd be a shame if anything happened to it. Just give us ALL of your data, You can trust us"
@Tedspence XPrivacyLua does this on #Android AFAIK
https://github.com/M66B/XPrivacyLua
It is similar in status to uMatrix: no longer supported, still working (for now)
However, it has a barrier to use in the form of requiring an unlocked, rooted Android device, which thus may imply a bit of technical know-how and comfort to do so...
I doubt Google would ever deliver a fake-data option, but I could see something like GrapheneOS do this (as Lineage is too mainline/AOSP directed).
$ sketchy_app --with-notifications > /dev/null
@Tedspence this is an interesting idea also from a defenders' perspective.
It raises the idea of 'honey-authorization' roles that do nothing, have no legitimate use, but instantly trigger security alerts when assumed by any account
@Tedspence I daydream mostly about a mobile OS that grants me this capability.
But also for notifications, filters. They wouldn't be perfect, but you could let some through.
GPS would be huge.
Contacts, but only some would be huge.
Eyv
@Tedspence Always wondering what I'm missing out because of my decision to install only free software from F-Droid on my LinageOS. (With the exception of the odd messenger.)
Some apps feel randomly unfinished. But even those with declared "anti-features" don't ever seem to act up. This thread makes me go nope. I have no idea what you're talking about, and now I'm not curious any more.
I will not allow my own devices to work against me.
@maxy In the old days, operating system developers assumed that all programs installed by a user were trusted. In those days, it cost a huge amount of money to buy a new software program, so of course you trusted it! Unfortunately, those days are over - even if you use open source products, there's always the risk that some corporation buys up a project and starts shipping nefarious and unwanted updates.
Even if you're on a fully OSS stack, you need to be protected from rogue software.
@Tedspence this is not fundamentally new, this is selecting the inputs to a program written to a capability interface. it's definitely a paradigm most users will never have seen, but it's literally what fd redirection in unix shells does.
I wholeheartedly agree that capability-oriented OS APIs are the only user-first way to design an OS, and every practical option for an OS/userspace fail this horribly.
@Tedspence the place I think this is closest to practically implementable is probably freedesktop-based Linux where we already have a capability interface for things like screencasting through desktop portals... but spoofing location, etc. is not yet easy to do.
it would be wonderful for the FOSS community to lead here--cc @postmarketOS
@Tedspence YES, this so much.
Apple started doing this with Photos, you can grant access to only certain photos. BUT they didn't do it quite right; they still tell the app partial access has been granted, so the app knows the user is holding back.
I'd love to see this with Contacts (share only a subset of contacts), location, etc. but damnit don't snitch to the app that I'm lying to it.
If an app needs to know REAL location for security reasons, that could be an entitlement that has to be granted, and the developer would have to provide a good reason.