If Google truly cared about privacy, each app would run in its own strict jail, and permissions would be faked by default. Also, easy malware by Israel or anyone else would not be a thing. As it stands, apps know everything I am doing, and I get targeted spam email rather immediately.
> I don’t even know where to begin unpacking this madness. How is knowing whether I have the Xbox or the Playstation app installed on my phone essential to their Swiggy's core functionality?
Probably has to do with feeding adtech's hunger for personal information, or fingerprinting maybe (not sure if that's a thing in the context of phone apps).
It's probably an oversight than a "backdoor". They already have a "frontdoor" in the form of a permission that's pre-granted to them by the OS, so there's little need for them to devise backdoors like the android.intent.action.MAIN query that the blog post mentions.
Can windows apps (not installed from the MS store) enumerate through the window titles of all open windows? How hard would it be for an app to monitor all of your web traffic based on the title alone?
Legit question. ChatGPT isn't super helpful here since it agrees with everything when I'm really looking for someone to say why this isn't really feasible in the real world.
Most windows apps aren't sandboxed, so them being able to grab window titles is the least of your worries. Any program can steal your login sessions and passwords if they wanted to.
Are you essentially discussing like a keylogger? I can't imagine windows intentionally keeps the plaintext password anywhere longer than it needs to be.
Obviously there's no way for a malicious program to grab your login credentials that you've entered into an incognito tab that have been closed. There might not be sandboxing, but viruses can't timetravel yet. However that's not going to be much of a defense when many users use password managers, and are terrible at detecting malware (so it's only a matter of time before their passwords are keylogged).
ita disconcerting to see such naivety around security issues on hn.
not that windows is keeping passwords in plaintext, but that it's not immediately obvious that un-sandboxed apps that run on your windows/linux/mac desktop have virtually unlimited other avenues to capture passwords given they can read the entire state of other windows at the very least.
I dunno maybe macos is slightly better, and wayland definitely has some things which are better about this, but desktop os and $locally_installed_app means $locally_installed_app basically has root, there is just an exploding amount of vectors.
I'd like to see a linux based distrubution use some of the sandboxing in Android, it would be a order of magnitude improvement over what is going on now.
That, but consider also how an application running with your user privileges has full access to the filesystem with those privileges, so it can read your entire home directory, for example. That includes your browser profile with all cookies, and all credentials that applications store there unencrypted. Not to mention how that allows for all the fingerprinting even the most nefarious marketer could wish for.
Oh, and the UAC confirmations to elevate your apps permissions to root? People will gleefully confirm them without reading what needs access anyway, so you’re golden to do whatever you want.
Definitely possible. This is how chat bots worked on AOL in the 90’s, basically the FindWindow and FindWindowEx functions in the win32 API. Hasn’t changed much (if any) since then.
Not only can most apps see the titles of all other open windows on the system, but they can log all your keystrokes, take screenshots, record audio/video of you or your screen, or copy/delete all the files in your home directory, without any explicit permission or notification.
This is at least true for Windows and most traditional (X11 at least) *nix systems.
That is one thing I think Android got right... by default it runs every application as a different user. That means different home folders and no visibility into other apps.
Originally Android apps could draw over top of any other app though which is a phishing nightmare. It took them a long time to make that a permission, and then everyone granted it until they finally added the bubbles API recently.
Permissions are difficult to get right, and Android is unfortunately pretty slow to react.
On windows you shouldn't be able to do (most of) these directly with apps running under admin, though that's a small consolation when the browser is a normal process.
I'm not sure if we'll get away from these anytime soon as any out of the box solution will inherently limit the user's freedom that has persistently been there for decades on PCs
I have absolutely done all of these things on Windows, even for commercial applications. Programs that keylog (i.e. calls SetWindowsHookEx) sometimes get tagged by antivirus though.
Right; I think having the API exist is a good thing, it's just a question of making sure that it's only used in ways that the user allows. Your own scripts inspecting and controlling arbitrary windows on your own machine => great, third party programs doing the same thing without your informed consent => bad. (In practice, this means I'm a big fan of extensive permission systems that have the ability to deny or fake responses at the user's direction)
Windows has a whole different (looser, older) security model. There are no security barriers between windows running on the same desktop. (In particular, "UAC is [still] not a security barrier"--when you hit ok/type in a password to elevate a process, you’re effectively elevating the whole desktop and everything you're running.)
No, that is completely wrong and would be nuts. The only way the whole session gets elevated is if you'd launch explorer.exe with an admin token.
The way privilege escalation works on Windows is that pretty much everything gets launched with a standard user access token by default, and processes can request an admin access token in a few ways, UAC being the main one. When a process is supplied that token, that process is elevated.
It is more akin to 'sudo' rather than 'su', which makes sense because its progenitor is 'runas' from Windows 2000.
(Only) the process is elevated, but the process has a window on a shared session, and the OS does not successfully protect processes that share a session (and user, and registry, and disk, etc., etc.) from controlling each other.
From an API point of view, only one process is elevated. From a security point of view, if one process is elevated they all are, due to a lack of any effective mechanism that actually stops them.
No, even then there are things like Mandatory Integrity Control and Windows Message Restrictions / UIAccess. I'd dive into to deeper but I just got home from going out haha. Those terms should help you dig into it though!
I do fully agree that desktop OSes are a legacy security model and they can't hold a candle to that of iOS. Android is getting there, but because it also started from mostly an open all-access model it's been having the same warts.
Long-time Win32 programmer here - yes. This is by design. To use an analogy, Windows is like a "high-trust society".
There are functions EnumWindows() and EnumChildWindows() specifically for this purpose.
See utilities "Windows Modifier v2.00" (when I first downloaded it there were many pages about it, but it's a sign of how forgetful the Internet has become that I barely get any results about it now even searching for that exact name) and Microsoft's own Spy++ (SPYXX.EXE) for an example of this functionality.
The solution to an app you don't trust is to not use it at all, or use it in a VM.
How do you identify apps that you shouldn't trust? Sometimes trust is assumed only until evidence is given that trust shouldn't be given. Which makes no sense to me. Why was the initial trust so easily given?
A solution is to not use third party apps but most people aren't going to go that route. The VM idea is a good option though.
Because this architecture predates the existence of the current privacy nightmare.
In fact it predates the general availability of the internet. How could a program you would install from a floppy/compact disk bought on a store behave maliciously if you didn’t or barely had access to the internet ?
And then it stayed like this because Windows is heavily marketed as being retro compatible.
It's also from a time when corporate mass surveillance was universally hated, software was not a service, and "phoning home" or requiring an Internet connection considered unacceptable to the majority of users.
> How hard would it be for an app to monitor all of your web traffic based on the title alone?
Although not terribly accurate (because of the high variability of page titles), tools like ManicTime and ActivityWatch use windows titles to track your browser history if you don't install the browser plugin.
First, f-droid only accepts OSS apps, so the incentives for spyware is simply not there. Second, anti-features are explicitly marked on f-droid. Third, f-droid apps are curated like a very rigorous linux repo.
Being an OSS app is not sufficient protection. Most OSS apps aren't terribly misbehaved, but some are. Being OSS in and of itself is not anything like a guarantee with this sort of thing.
> Third, f-droid apps are curated like a very rigorous linux repo.
Yes, I know. My question is is this one of the things they're screening for?
packages on f-droid list all required permissions explicitly, and the mentioned permission seems to be listed as "query all packages: Allows an app to see all installed packages.". It doesn't mark the app as having "anti-features", but you can at least make a more informed decision this way.
That's pretty cool, but the article says that most apps that are doing this sort of thing aren't using the query all packages permission and instead are using the facility to provide a specific list of apps they're checking for, which is not permission-gated.
It is. It specifically says that the apps must be declared in the manifest like other permissions. So it's a specific permission for each app really. F-Droid could query that if it wants to (not sure if it does)
> It doesn't mark the app as having "anti-features"
I suppose they must be too busy ticking off "anti-features" like "can communicate with non-Free services" to notice that sort of thing.
(No, really. F-Droid will tag applications like a Mastodon client as having "anti-feature: Non-Free Network Services", presumably because it can be configured to connect to servers running non-free software?)
> For extremely specific use cases such as file managers, browsers or antivirus apps, Google grants an exception by allowing QUERY_ALL_PACKAGES permission, which provides full visibility into installed apps.
Why would browser need to enumerate the installed apps?
When a user visits a play.google.com URL Google wants to be able to show either an "install" or a "launch" button contingent on whether the app is already installed.
this doesn’t make sense and sounds like an excuse IMO.
Instead of the browser enumerating all apps, why can’t it check when you visit a page if the current page (ONLY the current page) is installed as an app?
How would the OS know if the app that the browser is querying about is actually the current page? For all the OS knows, the user might be quickly visiting a ton of play.google.com pages for the top 1000 apps on the app store.
> How would the OS know if the app that the browser is querying about is actually the current page?
Maybe i’m missing something, but it sounds like it would be easy for google to support this functionality by letting developers configure this in their app “bundle”. A property that tells the OS “my app is related to domain example.com”. Make it an array of domains if you must.
> A property that tells the OS “my app is related to domain example.com”. Make it an array of domains if you must.
Elaborating on the sibling's comment: There is already such a property that apps must set in their manifests in order for them to be able to react to links/intents for domain-associated-with-the-app.com.
But it doesn't address the question of how a browser is supposed to be able to open links to domain-associated-with-the-app.com in that app, without Android revealing to the browser whether the app is installed or not. In short: The browser will, by construction, be able to determine which apps you've got installed or not.
A minor UX difference doesn't really feel like a great case for reducing user privacy, it makes me a little concerned about priorities... which I already was, really.
I don't buy this. Google has this information on their backend, they don't need to query any local state. Indeed, when I visit a play.google.com URL, google checks if my browser is logged in or not. If it is not, the default is "Install" no matter what. If I do have a session, then it's either "Install" if I don't have it installed, or "Install on more devices" if I do have it installed.
File managers need full access as you can use that ability to extract and inspect the code of any apps installed on the system. It is a very useful feature and I would hate for it to be removed.
Definitely not “good” but I’m still to see anything remotely resembling the complete disregard for privacy and security typical for the adtech-driven android ecosystem.
Just a different business model, not a display of moral values.
Sure, Pegasus exists but I don’t think it is commodified yet.
What evidence is there/can you present that Apple is making use of this information in a negative way?
How can Apple not have a list of installed apps on your phone while maintaining basic functionality (automatic updates, reinstalling apps from backup, etc)?
Sort of. They have a list of apps you've bought/installed through app store, and they can figure out what you've deleted based on what your phone is pinging for update checks on.
If they went beyond that, or disclosed that knowledge, or allowed an app to get that manifest without your permission, it would destroy their brand image built around privacy, in a way that would cause long-term irreparable damage.
They decided to not comply with laws compelling them to add back doors to optional encryption on iCloud storage, rather than tarnish that image, because they know how valuable that trust is.
You can dump on Apple all you want, but compared to Google who plead with people to use their browser and phones to improve adtech surveillance they can monetize, I think they're doing OK and are a lot more trustworthy.
Are you sure? I know someone in adtech and I'm pretty sure Apple allows a similar app manifest that allows you to check for specific apps. I could be wrong.
> I know someone in adtech and I'm pretty sure Apple allows a similar app manifest that allows you to check for specific apps. I could be wrong.
On iOS an app developer will need to register in advance which external applications their app intends to query, and the list needs to be very short and motivated. [1]
Incidentally, “I have a friend who says...” isn’t really a good citation anywhere outside Reddit - which HN resembles more and more each day.
I suppose a more appropriate term of phrase would've been "I'd heard anecdotally...", but I agree I was lazy with my original reply. I appreciate the feedback.
Comparing HN to resdit is explicitly against HN guidelines. Though sometimes I think the only reason it’s never “true” is because Reddit is a moving target. Both HN and reddit get worse over time, so HN never catches up to how bad Reddit is.
Also the bots have not invaded HN, which is a truly massive distinction.
I think this is probably true of any online community. I’d wager that an online community needs more users to grow and be sustainable, and more users inevitably means more content, and more content means less _high-quality_ content overall.
You're too kind, their reply was extremely rude to you. I have been here 16 years, been an iOS developer just as long, and have no idea why your comment is "Reddit."
A simple thought exercise for me is "Which of these two comments is more Reddit?" - I'd say the one that came with curiosity is HN, the one that bats around half truths combatively and invoking Reddit isn't.
I snorted when I got to the self-important haughtiness about reddit.
Why?
- You immediately recognized what they meant.
- They weren't advancing a claim, they were indicating a basis for their interrogative, likely to avoid seeming naive when claiming it out of nowhere.
- The article we're commenting on describes the same mechanism you claim differentiates iOS. ("register in advance...which applications...intends to query, and the list needs to be very short and motivated.")
- I've worked heavily on iOS and Android since 2009. As close to a graybeard as you can get in mobile. I'm searching, reaching, grasping for any sign you've done anything other than Google and link the first article you saw, and I can't find _any_. At all. But I don't think that's wrong. You're trying. Why is it wrong for the person you asked to try too?
- There's strong signs you didn't read the article we're commenting on.
- If you had, it is unlikely you would have said iOS was differentiated, then laid out the exact same mechanism described in the article.
- There's strong signs you didn't read the article you linked.
- On iOS you can register URL schemes in a plist, these aren't "external applications you intend to query" and the list does not have to be "very short and motivated"
I get cranky too, but, I am grateful I recognize it is very reddit to cry Reddit and edit it out, or delete.
> There's strong signs you didn't read the article you linked.
What could possibly indicate I didn’t read the article? Of course I read it.
Isn’t your assumption of my bad faith also explicitly against HN’s guidelines?
> On iOS you can register URL schemes in a plist, these aren't "external applications you intend to query" and the list does not have to be "very short and motivated"
Yeah Apple used to be more loose with registered URL schemes, but tightened up a few years ago ands so now if you submit with a huge list of schemes the app has no good reason to use you’re going to get bounced.
> What could possibly indicate I didn’t read the article?
What I laid out, namely, that you described iOS the same as the article, while simultaneously claiming iOS differs significantly.
> On iOS you can register URL schemes in a plist, these aren't "external applications you intend to query" and the list does not have to be "very short and motivated"
> I’m also an iOS developer- and yes it does.
Which part is "yes it does"?
We both can agree quite quickly that URL schemes in a plist aren't "registering apps." You can drag this out a couple turns by playing shell games first by ignoring the URL schemes difference, then by making me do the leg work to show it's trivial to find apps with dozens of apps in that list.
Either which way, I continue to be taken aback by your snarkiness towards the original post and cries of Reddit given you know you were 100% wrong on this.
You're in a really bizarre situation where too much territory was staked out and you're defending it all: you can't claim this was a remotely accurate description and you read the article about Android and iOS is different. It's already a farce, then throw in scolding about how HN is Reddit because of low quality posts...my goodness, my friend.
> Of course I read it. Isn’t your assumption of my bad faith also explicitly against HN’s guidelines?
No, because I said "There are strong signs", I didn't say "You didn't read it."
Also, why would not reading be "bad faith"?
You are extremely focused on making attacks and perceiving them in others, please take a step back and note: "But I don't think that's wrong. You're trying. Why is it wrong for the person you asked to try too?" - you shouldn't have to make up an interpretation where gently chiding you for being rude turns into invoking rules and accusing you of bad faith
Not sure about the manifest but recently I've seen talk about some banking apps using SBSLaunchApplicationWithIdentifierAndURLAndLaunchOptions (undocumented function in SpringBoardServices) [0] to try to launch another app on the phone by the bundle id, and they can determine if it's installed or not.
They were using this trick to detect unauthorized apps on the phone.
I would have to strongly recommend nobody enroll a personal device in a company MDM. If the company needs you to have mobile connectivity that badly, they can give you a device.
I think it’s a personal decision. I really, really do not want to carry two huge slabs around. One is already too much.
Account driven MDM enrolment pushes the Pareto front when it comes to privacy/conveniency compromises from my point of view. I will ask my IT if they have already looked at it.
The benefit with the two device approach is when you can not carry both devices for the majority of the time. If i’m not explicitly on call, my work device isn’t with me. Anything anyone says to me will wait until I’m back in the office.
If you have the self control to refuse to ever check Slack and disable all notifications/etc on your personal phone when not on call, this doesn’t apply as much. But for me I default to trying to stay on things and forcing myself to disconnect is a net good, even if it does mean I carry two phones at times. My pockets are large.
I mean... isn’t that expected of an MDM? I have always assumed that any company device (i.e. any device enrolled in an MDM) is under 100% control and surveillance of that company. Being able to see my installed apps is the least of my worries.
Apple introduced account-driven enrollments in 2021[1], which behaves similar to Android's work profile. Managed apps/data are kept in its own APFS volume, and MDM servers don't have access to anything outside of it. They also disallow system-wide commands like wipe device. The only caveat is you need managed Apple IDs[2] to use this enrollment flow, and I doubt many companies have set it up.
Regardless, MDM installed app visibility is limited to those users who opt-in to an organization managing their personal device, and isn't an effective way to broadly gather what apps a given person has installed. What's described in this post would work on any user/device, and there's no way to deny/opt-out of specific permissions.
I'm working on implementing this for the company, and the annoying limitations on iOS is that you can't clone apps. If you want Gmail (as an example) as managed app, you can't have another Gmail as unmanaged app. While the company can't see inside the Gmail managed app (without the app itself explicitly providing that feature), the company can remove Gmail (and any local data inside the app) at any time.
Fun fact from the MDM implementation - the most private way (at least to the company policies) to have a company-connected device is to buy a separate phone and install company's MDM on it. On company provided devices, the company may locate company's assets at any time but doing so on a personal device is a privacy breach.
Yes, Apple hates the idea of work-badged apps that Android has. I have to admit, a lot of our users don't grok it either at first. However once they realise the benefits (the company has much less visibility, AND they can turn off the work section completely with the touch of a button) they usually come around pretty quickly.
The bad part of this is that apps have to specifically support the multiple profiles option, otherwise they can't be used for this.
And yes, I agree, that is the best way. We have the same restrictions for personal devices. Though I as an admin know we never use the locate functionality (and I know every person who has access to it).
Donyou know if account driven enrolment requires different phone numbers for the MDM managed apps and the personal ones? Specifically for the diaper app for example.
I don't believe they do, no. The numbers aren't all that important in terms of MDM. We don't even see the number if someone inserts a second private SIM in their company phone. We consider that personal information we shouldn't even know.
Yes I know about User Enrolment. The problem is the managed Apple IDs are a complete and total dealbreaker. So I'm not even considering this as an option.
The reason is that Apple demands that the UPN (the account ID) and the email address are the same. For us this is not the case (our UPN is our employee number as an email address, whereas our email address is just our name). And obviously we're not going to change this for ten thousand users because Apple wants to (most of which don't have Apple devices because we're a European company). Also, you have to manually decide what happens to each user that has already created an account with their corporate email address and what to do with the content they purchased on it. This is not feasible for a large corp. We have commented this to our Apple account manager for years and years but they simply don't care. If you work in this realm you probably know that Apple doesn't really care about things that matter for their corporate customers anyway. The consumer is their main client and it shows (unlike with Microsoft where it's the opposite).
So the whole account-driven enrolment (User Enrolment) as well as everything else depending on managed Apple IDs like DEP for Macs is completely out of the window.
The problem in my opinion is that I as an admin can simply query for example all the employees that have something like Grindr installed. Considering the current political climate in the US (or worse, the middle east where this can lead to a death sentence in some cases) it's obvious why this is super bad. And really, why should we be able to do this at all?
Speaking of iPhone, Im curious about something. On occasion, I log into the [former] bird app using the web app because it's enough to check up on some key follows.
Recently, they released a major update to their LLM feature and I installed the app to check it out. While I had the app installed, every time I checked the mobile website there was a large banner directing me to go to the app. Ad blockers and distraction blockers would not get rid of it. When I deleted the app again, it was gone. What gives? Why does the mobile website know whether I have the app installed? How come content+distraction blockers are enough to block all reminders to use the app when it's not installed, but are irrevocable if I have the app installed?
This was somewhat mitigated on iOS a few years ago.
You could try to communicate with an app via the custom URI scheme and if it succeeded, it would know you have the app installed. Twitter used this for finger printing.
An app has to get a special intent and has to list the apps it wants to use it for.
One of the biggest incentives for creating apps is to scrape all kind of data from the users. Look at how many apps require permission to see you contacts. And how many actually need your contacts to function. That's why I'm still a bit surprised that many seem to be surprised by findings like this one here.
I wish there was an option for “give bogus contacts” which showed the app a list of contacts - but it was all randomly generated junk. Make it so the app can’t tell if the contacts it gets are real or fake.
I read a fiction book years ago where there were cameras everywhere. To get privacy, instead of hiding their identities the protagonist paid companies to insert bogus information into the information brokers’ network. So if they tried to figure out where they were on a certain day, 20 records would match. I think this is a much more likely vision of the future.
Look at how many apps require permission to see you contacts. And how many actually need your contacts to function.
That is, again, not require but ask for on iphone. I have zero non-functioning apps on my iphone due to denied access to contacts. Even a chinese bluetooth light controller doesn't dare (while refusing to work on android for the same reason).
You can hate apple/iphone ecosystem all you want, but let's not sneak false claims into how they actually work.
> Look at how many apps require permission to see you contacts.
It is so annoying that it’s either "give access to ALL my contacts and ALL their information (yes, even the notes I took on their favorite things for next Christmas)" or "don’t give access". I wish we could limit the number of contacts and the level of information we give.
> It is so annoying that it’s either "give access to ALL my contacts and ALL their information… […] I wish we could limit the number of contacts and the level of information we give.
iOS added fine-grained (at the contact level) access to contacts data last year.
They don't need to be, since it's enforced at the OS level. Users can limit permissions to individual contacts regardless of whether iOS apps have been updated to explicitly handle that use case.
If they just audited apps and banned companies from the app store for abuse it would do a lot to curb this behavior. This is feasible, there just aren't THAT many popular apps at any given time.
It requires root, but you can block/spoof this with an LSPosed[1] module such as XPrivacyLua[2]. I hear there's also the closed-source AppOps[3], but I've never used it.
I've not heard of XPrivacyLua, which is by the same author of the excellent NetGuard[0], which I've been using for years.
Interestingly XPrivacyLua is not supported anymore and the pro companion app will be removed from the Play store by Google because it uses the permission QUERY_ALL_PACKAGES.[1]
Indeed, it is a shame. However, XPL-EX is a fork (though with much internal code (re)written at this point) with even more capability, while maintaining the familiar and simple UI. Seems pretty neat!
Privacy issues aside, it's kinda cool reading about how Indians use their phones, and also how they use English. I'd never heard "beyond the pale" before, and I'm still not sure what the idea of "multiple Indias" means when some of them are Mexico and some are Africa...?
I've also never heard of the majority of the apps being analyzed or tracked. Must be such a different world out there.
From the context, what I gather was meant by the idea of "multiple Indias" was the socioeconomic status of different demographics in India and their app usage. The presence of specific apps gives a tell to which demographic they belong to.
In other words, the richest demographic used certain apps and was equated to folks in Mexico, followed by the less rich equated to folks in Indonesia and the poor to Sub-Saharan Africa.
Beyond the pale is commonly used in English. A pale is a stake, and it means beyond the boundary (set out by a fence with stakes, hence the phrase) of what is acceptable. It gaines popularity in the mid 19th century. It may be related to the term "the Pale" which referred to the better controlled more Anglicised part of Ireland around Dublin, but there isn't enough evidence to be sure of this. Certainly not an Indianism anyway.
>I'm still not sure what the idea of "multiple Indias" means when some of them are Mexico and some are Africa...?
Is it not pretty obvious? It is like the phrase "middle America". It doesn't literally mean a different country. It means different wealth categories: the Indians that when considered as a whole are economically equivalent roughly to Mexico, those roughly equivalent to Indonesia (poorer) and those roughly equivalent to Sub-Saharan Africa (poorest). There are ~1b Indians that are still so poor they aren't realistically in the market for your startup app if it wants its customers to ever spend anything, there are ~300m Indians that could be in the market for some apps, but probably mostly free ad-funded ones, and there are ~150m Indians that are quite a good market because they will happily spend money on something that provides value.
It's the average cooldude marketing of self-proclaimed "India 1", denigrating their own people and can't think outside of labeling others as something else.
These people are extremely snobbish in person when you go past their sweet talks, who don't understand much about people. I hated the "real" interactions and went back to being an IC in big tech.
Part of it is because they don't understand them, part of it is because they "understand" via someone else who told them stuff (like a redditor assuming everything on r/india is true), part of it is their own contempt of culture due to previous reasons ("ah these people are beyond any repair!"). Basically, ignorance in elites.
> How is knowing whether I have the Xbox or the Playstation app installed on my phone essential to their Swiggy's core functionality? How will knowing if I have the Naukri or Upstox app help them deliver groceries to my doorstep?
Maybe I'm wrong, but that feels pretty similar to fingerprinting. Usually that's why online services try to fingerprint you, for advertising and data revenue.
The US Customs & Border Control apps ("CBP Home" and "Mobile Passport Control") could check for blacklisted apps and flag you to be deported to an El Salvadorean gulag without due process.
I think the commenter was asking for a clarification on the hyperbole used. Unsure on the intend being candidly asked or there was an agenda (as it is often the case with political discussions).
Hopefully the El Salvador deal is a far cry from the internment camps from the 19th & 20th century.
This is likely in reference to a recent deal the US (Trump) has made with El Salvador, allowing them to ship US citizens off to prisons in El Salvador, whether this is actually possible is not clear at this point though [1].
Here is some more information about the conditions in these prisons in El Salvador, CECOT being the most notable one:
> Able to hold 40,000 inmates, the CECOT is made up of eight sprawling pavilions. Its cells hold 65 to 70 prisoners each. They do not receive visits. There are no programs preparing them to return to society after their sentences, no workshops or educational programs. They are never allowed outside. [2]
I believe the term gulag makes sense in that context despite it not being a forced labor camp. Not sure how this relates to Russia at all (apart from the origin of the term obviously).
I can imagine knowing the apps someone uses might be a telling thing to someone looking for leverage on someone (who might not want to disclose what apps they use). Apps can expose your orientation, your lifestyle, your income level, your habits, and even where to look to find you (imagine you have an app for a gym, that narrows down the list of gyms to find you at and is better than nothing)
Politicians, law enforcement, high value targets, etc. A list of apps on their phone could totally be used against them and is better than no list of apps.
Thanks for the link, seems like the loophole is already there since the introduction of the package visibility restriction, and almost everyone and their mother knows how to bypass this restriction.
> Google refuses to patch this
While I don't believe Google engineers are not aware of this widely used loophole, do you have any source that they refused to fix it?
If it's a security issue fix, they should release it in one of the monthly security patch.
I also think that private space do not fix the underlying issue. If you have four apps and you don't want them to know about each other you can put one of them in main profile, work profile, app locker and you run out of profile for the last one. The way app locker work doesn't scale to tens of sandbox.
I know you didn't ask for this sort of answer, but you could use user profiles for this.
You can have more users on the "standard" AOSP Android as well, but with a certain AOSP-derived you can also have notifications forwarding.
Until they add Application List Scopes (I believe it's on the road map), in the exactly the same way users can now lie to apps they have only specific contacts in their contact list and only one or two specific folders in the Storage.
they keep releasing overly complicated features to sidestep the obvious reported vulnerability, to silence power users and please corporate enterprise sysadms.
the rest of the 99.9 of users keep the vulnerability, which is very profitable for ad networks. wonder why an ad networks who maintains android would do that.
What do you mean with "refused to patch this"? Google will reject any app publishing attempt that asks for that filter and isn't a launcher on Play store.
XPrivactLua and other XposedMod/Magisk extensions break open the app sandbox. It is better to restrict running those on usereng/eng builds (test devices). For prod builds (user devices), I'd recommend using Work Profiles (GrapheneOS supports upto 31 in parallel) or Private Spaces (on Android 15+) to truly isolate apps from one another.
> Android’s security design has fundamentally been based on a multi-party authorization model: an action should only happen if all involved parties authorize it.
> these are user, platform, and developer (implicitly representing stakeholders such as content producers and service providers). Any one party can veto the action.
How is this not anti-user? It explicitly states that the app developer should be able to veto my decisions...
Under the shared responsibility model, such veto makes sense. Just because the end-user (the app has no way to determine if it was a thief or a spy or a monkey or the actual device owner) approves of an action doesn't mean the OS and the app have to grant authorization.
I can see how such a setup is hostile to power users, but then Android is used by 50% of all humanity, and your guess is as good as mine as to just how many want "sudo make me a sandwich" level of control.
That link seems to have... an agenda. It's way too hand-wavy (e.g., it doesn't at all attempt to tease out the nuance of whether a rooted phone inherently has a broken security boundary by design, or whether [like on Linux] it's secure as long as the implementation is non-buggy) and seems laser-focused on convincing users that desire sovereignty over their own devices that they might as well jump off a cliff.
Madaidan's articles are well-known to be centered around "security at all costs", and often at the cost of user freedom. That's just not a realistic take when it comes to privacy. What good is absolute security if all it does is secure the device from your "tampering"? Sure, it would be nice if the device were highly secure, but I'd rather it stop spying first.
With absolute security, you can rest assured that only Google has access to all of your data, and only Google is allowed to turn off the siphoning.
As dataflow says that site has an agenda. I've used rooted phones continuously since Android v4 and I've had no trouble. Moreover, I'd posit that much of the crap I remove from phones lowers the attack risk which to some degree offsets the risk of rooting.
Granted, I'm not suggesting that everyone should root their phones, in fact in recent years I even stopped suggesting it to my tech-savvy friends (that is unless they approach me for advice).
I don't need to lecture about these things but all those who've rooted their phones know the huge advantages—power and control one has over one's phone is enormous.
For example, some apps contain so many trackers that normally you'd never use them except they're the only apps suitable for one's purpose. Rooting allows you the user to take control and have them do what you want and not that of the developer.
Yes, rooting has its risks but for my purposes its benefits far outweigh them.
As someone who cherishes the power of root privs, I'd still like to make a point for alternative solutions that came up like distros such as GrapheneOS or CalyxOS or non-root filtering options via VPN.
If it weren't for backups I could manage my everyday life without root. For all other cases I would root and later unroot my phone via an OTA update :D
https://github.com/schnatterer/rooted-graphene/
Hopefully GrapheneOS deliver on their promise to provide a better backup solutions than seedvault.
> The term [rooting] generally also includes the functionality for making runtime code patches (eg. with Zygisk) and making runtime filesystem modifications (eg. Magisk modules).
> Out of the many root-enabled apps I've studied or reverse engineered, the vast majority fail to handle arbitrary inputs properly (especially filenames). For example, some root-supporting file managers turn a seemingly benign action like listing a directory into local privilege escalation. This is trivially exploitable, especially with browsers auto-downloading files with server-provided filenames to /sdcard/Download/.
To avoid repeated root access UI prompts, some apps spawn a long-running shell session, write commands to stdin, and rely on parsing stdout and searching for the shell prompt to determine when commands complete. This approach is prone to desync, which can lead to commands being skipped or other inputs being interpreted as commands.
All in all, I simply do not trust most root-enabled apps to not leave a gaping security hole, so I avoid them entirely. There are apps that do handle root access in what I would consider a more proper way, by spawning a daemon as root and then talking to the daemon over a well defined binary protocol. Unfortunately, this approach is the extreme minority.
The question is: Who is the beneficiary of the app sandbox?
Is it you, the user, because no malicious processes can taper with your apps?
Or is it the corporations, because they prevent you from modifying their apps – which makes you a pure consumer?
I think, for the tech-savvy, the latter is more accurate and I think it is very important to be able to crack open these sandboxes and tinker with processes. Be it to inject ad blockers, automate them, modify their appearance, etc. It should be a right of a user to be able to do these things.
Malicious apps sneak through the vetting process all the time.
Genuine, honest apps have to process unsafe content (be it we pages, messages) all the time.
One exploit should at most make single App vulnerable, not expose everything I have on my phone.
Strong, restrictive sandboxing, memory and execution protections are the only safe way.
And how is destroying the sandboxing related to having more rights as a consumer? You could still patch and repack them in the way Lucky Patcher does with ads, for example?
> I think, for the tech-savvy, the latter is more accurate and I think it is very important to be able to crack open these sandboxes and tinker with processes
Anyone tech-savvy that wants to mod their Android (like they'd mod Linux distros), should consider purchasing Android devices (like Pixel) that support ownership transfer (that is, unlocking then relocking the bootloader), and flash CalyxOS/GrapheneOS usereng/eng builds.
Undortunately the trend set by google is becoming extremely antagonistisc for modders. It's becoming a tradeoff between security and convenience, arguably that was not the case back in early android version, actually it was nearly the opposite. i remember hiw CyanogenMod features were surpassing the state of Pure Android at the time, it was fun to see the innovation happening in that space. Then came the ostracization of modders, from GApps restrictions to Play Integrity, all of those made it nearly impossible to have an android OS built to your taste, while able to run useful apps like banking and payments. It's sad that I have to carry 2 devices with me because Google took the greedy way.
Can't wait for App List Scopes, like we have with Contacts or Storage already. Not a day too early.
For a few months all the UK banks I have accounts in send the list of all apps to the mothership.
I noticed it first when suddenly Revolut refused to start up because I had an app installed, Natwest and Nationwide at least inform prior to the data collection, but weren't concerned.
It ended up with the long overdue confinement of all the banking apps in their dedicated profile, but I'd love to be able to confine them further.
You mentioned NatWest. I remember using NatWest and noticing on NoRoot Firewall (on my Android) it was 'speaking' regularly to Facebook. Of course I had all FB and IG and their IP ranges blocked from the get-go, but still. Why (TF!!!!) would my effing back telling FB that I launched their app? (one could say that they use this or that library, so the code, blah blah blah)
This is disgusting and the reason I don't use iOS. The utter lack of firewall! (plus the batterygate scandal)
I'm on Android 14 and I've been pretty happy with an app called Insular on F-Droid or Island on the Play Store. It let's you install as many instances of an app as you'd like and they'll show up in the work profile, ignorant of the others' existence.
> If there is one leap that the infosec community consistently fails to make, it is this: people who are not like me, who have different needs and priorities, who have less time or are less technical, STILL DESERVE PRIVACY AND SECURITY.
The right ("as intended", in my view) functionality would be to support a manifest with, say, five apps, and if as a dev you wanted more youd apply to google for an exception (like aws limit increases) with a list of reasons for each app.
I know people may not remember this, but Android was initially designed with interoperability in mind. It's sad to see both the system development and the community opinion to have turned against it so hard.
It seems like the ACTION_MAIN loophole could be fixed (eventually) if apps that declare it are required to actually be launchers. It seems like legitimate integrations should have more specific intents.
At that point, Android prompting if random game you just downloaded should be your defaut launcher seems pretty dangerous interaction for sneaky apps to risk. They either cause the user to bounce and report or the fools select it as default launcher, replace their launcher, can't provide the launcher functionality and break the user's home screen and end up getting reported in Play Store. I also assume actually getting published as a launcher-class app at that point brings automated testsuites and other requirements that will be burdensome for developers.
It's because it stores the files there so you can sync them with other permissions. And also that your notes aren't deleted like they would be if they were stored in the internal app storage. There's more granular options for filesystem access available but if you implement them you limit yourself to the latest Android releases.
According to Exodus it has no trackers and it's an open source app also so you can see what it does (though tbh I didn't check that for the mobile one)
If there's apps to call out there's way worse than Obsidian.
There isn't a permission for that though - it's all or nothing. I agree that it should be more granular; each app should really have its own scoped file storage area by default, with "access anything" being reserved for file browsers, backup software, etc.
Yes but only later Android versions. If you start supporting those you need to move to the corresponding API level and that means to drop support for older ones. They probably don't want to do that yet. This one is Android 10 and up, and the Android 10 version of scoped storage was quite basic IIRC so you probably want an even later one. I guess they still want to support older phones.
On FreeBSD I can build a full copy from source (in fact I have to, there is no binary package). The only issue seems to be licensing, not source availability. Personally I don't care about licensing (I completely ignore it all anyway) and it doesn't stop you from inspecting the source code.
I think Obsidian is a really great package, I just happened to have moved over from OneNote which is horrible Microsoft mediocrity and doesn't even have a Linux app. And the web version is really useless, it needs to refresh every day and it can only search within the same tab, not a whole notebook. Such a mess. Obsidian is so quick and efficient <3 And there is full self-hosted syncing available, which I also use.
Obsidian on Android source seems not available. Even generally the reports seems that source is not available.
May be the freebsd build is using some binary library packages?
A cursory search indicates that one of the freebsd 'build-scripts' used for installing obsidian uses a binary package for obsidian itself, not building it from source.
It strange that about obsidian which seems to be rather popular here has many people thinking that it is open source, when it is not.
That's just a user contributed thing though. It's also just in the official ports collection. There's only a makefile there and some config files for electron (electron is kinda a PITA to compile on FreeBSD because there's no package)
Now, it can update itself automatically but it's all JavaScript. No binaries.
But it's safe enough for me anyway. Especially because the dev community uses it do much. If it did something untoward it would be noticed quickly.
The "official" packages seems derived from the Nix build for Obsidian, which is using binary caches to get the Obsidian binary is what I could understand.
If I'm not mistaken this is because without this permission they can only see audio, video and image files. You wouldn't be able to use it comfortably to do it's job.
Personally I use it with Storage Scopes on GrapheneOS.
>For extremely specific use cases such as file managers, browsers or antivirus apps, Google grants an exception by allowing QUERY_ALL_PACKAGES permission, which provides full visibility into installed apps.
'Extreme' my a*. My bank app has this permission, as well as my camera app, contacts app, clock app, Google Home, and on and on. My bank app was moved to an old iPad because of this.
yea I used to work for an advertising network and every game that implemented the Android SDK ended up with this permission, it was a way that we used to not show ads for games that the user already had on their phone
For the wider audience: though don't take this as GrapheneOS doesn't care about privacy. I'm sure there are reasons (I didn't read all of the linked threads) and it gives you plenty of other protections and tools - eg profiles, ability to disable all network access by app etc
> I'm sure there are plenty of system APIs providing this information too, and I don't just mean APIs designed to directly provide the information.
> It's not useful to prevent directly getting a list of installed applications without preventing detecting which applications are installed, so this specific feature request has to be rejected. It would have to be part of a larger, much more comprehensive feature preventing apps from finding other apps. That implies outright preventing communication with non-system components which is a much different approach to applications and rules out a lot of things. [...]
> The request should be for preventing apps from discovering which apps are installed, since anything less than that has no privacy / security value. There's no point in disallowing access to a list while not preventing discovering which apps are installed anyway.
I get what he's saying, but still seems like blocking the easy way of getting a list of apps, while certainty not perfect, would prevent most privacy abuse.
Privacy is not an on off switch, it's about making things leak data less.
I really don't understand grapheneos development sometimes, like when they refuse to make a setting to invert the back and recent button. Yes it's not part of AOSP but it's so simple to do and a feature that all manufacter offer because people want it, refusing to do that is weird imo.
Would it? My understanding is that most fingerprinting is done by a few large companies, in their own proprietary libraries that are shipped with third-party apps. If you block this method, they will quickly find another one and ship it everywhere, because that is their core business.
With browser fingerprinting, the ad companies are already regularly pulling many shenanigans; I don't see a reason why this would be different.
Big companies like Swiggy and Zepto will mine the F out of your data. Some of it is for their benefit but some of it they could sell in the future. These so called founders are really just another wolf of app street looking to pump and dump. So when they do dump, or when some VC comes with money, they don’t just sell their app they sell it as a whole package of data and analytics that some company can use to sell their product or something VC can leverage to sell their stock to someone else. It’s not that difficult.
As far as smaller apps go these apps outsource their development to people who come with ‘packages’ to develop and maintain their app. These packages are the same logic as above but it’s just that they come from some template so you might be asked for location permission or camera or microphone by some really random app that has nothing to do with it.
While the quality of iOS is degrading, some of these things are really important and simply work better on iOS.
501 comments
[ 2.8 ms ] story [ 316 ms ] threadI think I call bullshit on this.
But I agree that they could do way more and that they don't seem to care.
Have they even been pretending on this front?
Probably has to do with feeding adtech's hunger for personal information, or fingerprinting maybe (not sure if that's a thing in the context of phone apps).
Play Store Review and everything takes weeks sometimes and I can't tolerate that.
1. download the APK from a mirror site
2. disassemble it to get the android manifest
3. inspect the android manifest to check for the things the blog post discusses
Legit question. ChatGPT isn't super helpful here since it agrees with everything when I'm really looking for someone to say why this isn't really feasible in the real world.
https://xkcd.com/1200/
_Windows Recall to the rescue!_
Can’t tell if serious or not [1]. Also any program can read any saved password out of Windows Credential Manager.
https://en.wikipedia.org/wiki/Mimikatz
not that windows is keeping passwords in plaintext, but that it's not immediately obvious that un-sandboxed apps that run on your windows/linux/mac desktop have virtually unlimited other avenues to capture passwords given they can read the entire state of other windows at the very least.
I dunno maybe macos is slightly better, and wayland definitely has some things which are better about this, but desktop os and $locally_installed_app means $locally_installed_app basically has root, there is just an exploding amount of vectors.
I'd like to see a linux based distrubution use some of the sandboxing in Android, it would be a order of magnitude improvement over what is going on now.
Oh, and the UAC confirmations to elevate your apps permissions to root? People will gleefully confirm them without reading what needs access anyway, so you’re golden to do whatever you want.
The security model of Windows doesn’t exist.
This prompt got me some mostly looks OK Python
> Can you make a simple windows program that will get all the window titles from active programs running
This is at least true for Windows and most traditional (X11 at least) *nix systems.
That is one thing I think Android got right... by default it runs every application as a different user. That means different home folders and no visibility into other apps.
Permissions are difficult to get right, and Android is unfortunately pretty slow to react.
I'm not sure if we'll get away from these anytime soon as any out of the box solution will inherently limit the user's freedom that has persistently been there for decades on PCs
The way privilege escalation works on Windows is that pretty much everything gets launched with a standard user access token by default, and processes can request an admin access token in a few ways, UAC being the main one. When a process is supplied that token, that process is elevated.
It is more akin to 'sudo' rather than 'su', which makes sense because its progenitor is 'runas' from Windows 2000.
From an API point of view, only one process is elevated. From a security point of view, if one process is elevated they all are, due to a lack of any effective mechanism that actually stops them.
I do fully agree that desktop OSes are a legacy security model and they can't hold a candle to that of iOS. Android is getting there, but because it also started from mostly an open all-access model it's been having the same warts.
There are functions EnumWindows() and EnumChildWindows() specifically for this purpose.
See utilities "Windows Modifier v2.00" (when I first downloaded it there were many pages about it, but it's a sign of how forgetful the Internet has become that I barely get any results about it now even searching for that exact name) and Microsoft's own Spy++ (SPYXX.EXE) for an example of this functionality.
The solution to an app you don't trust is to not use it at all, or use it in a VM.
A solution is to not use third party apps but most people aren't going to go that route. The VM idea is a good option though.
Because this architecture predates the existence of the current privacy nightmare.
In fact it predates the general availability of the internet. How could a program you would install from a floppy/compact disk bought on a store behave maliciously if you didn’t or barely had access to the internet ?
And then it stayed like this because Windows is heavily marketed as being retro compatible.
Although not terribly accurate (because of the high variability of page titles), tools like ManicTime and ActivityWatch use windows titles to track your browser history if you don't install the browser plugin.
https://www.manictime.com/
https://activitywatch.net/
> Third, f-droid apps are curated like a very rigorous linux repo.
Yes, I know. My question is is this one of the things they're screening for?
I suppose they must be too busy ticking off "anti-features" like "can communicate with non-Free services" to notice that sort of thing.
(No, really. F-Droid will tag applications like a Mastodon client as having "anti-feature: Non-Free Network Services", presumably because it can be configured to connect to servers running non-free software?)
Why would browser need to enumerate the installed apps?
Why?!
In other words, blame Google product management.
Instead of the browser enumerating all apps, why can’t it check when you visit a page if the current page (ONLY the current page) is installed as an app?
Maybe i’m missing something, but it sounds like it would be easy for google to support this functionality by letting developers configure this in their app “bundle”. A property that tells the OS “my app is related to domain example.com”. Make it an array of domains if you must.
Elaborating on the sibling's comment: There is already such a property that apps must set in their manifests in order for them to be able to react to links/intents for domain-associated-with-the-app.com.
But it doesn't address the question of how a browser is supposed to be able to open links to domain-associated-with-the-app.com in that app, without Android revealing to the browser whether the app is installed or not. In short: The browser will, by construction, be able to determine which apps you've got installed or not.
But it doesn’t leak that information to web pages.
Obsidian for example asks for permission for entire filesystem, while it really needs to access the files which the user needs it to see.
On Android phones. iPhone doesn’t have this privacy deficiency.
Just a different business model, not a display of moral values.
Sure, Pegasus exists but I don’t think it is commodified yet.
What evidence is there/can you present that Apple is making use of this information in a negative way?
How can Apple not have a list of installed apps on your phone while maintaining basic functionality (automatic updates, reinstalling apps from backup, etc)?
If they went beyond that, or disclosed that knowledge, or allowed an app to get that manifest without your permission, it would destroy their brand image built around privacy, in a way that would cause long-term irreparable damage.
They decided to not comply with laws compelling them to add back doors to optional encryption on iCloud storage, rather than tarnish that image, because they know how valuable that trust is.
You can dump on Apple all you want, but compared to Google who plead with people to use their browser and phones to improve adtech surveillance they can monetize, I think they're doing OK and are a lot more trustworthy.
In a relative way, they definitely are.
On iOS an app developer will need to register in advance which external applications their app intends to query, and the list needs to be very short and motivated. [1]
Incidentally, “I have a friend who says...” isn’t really a good citation anywhere outside Reddit - which HN resembles more and more each day.
[1] https://www.hackingwithswift.com/example-code/system/how-to-...
I suppose a more appropriate term of phrase would've been "I'd heard anecdotally...", but I agree I was lazy with my original reply. I appreciate the feedback.
Also the bots have not invaded HN, which is a truly massive distinction.
I think this is probably true of any online community. I’d wager that an online community needs more users to grow and be sustainable, and more users inevitably means more content, and more content means less _high-quality_ content overall.
A simple thought exercise for me is "Which of these two comments is more Reddit?" - I'd say the one that came with curiosity is HN, the one that bats around half truths combatively and invoking Reddit isn't.
I snorted when I got to the self-important haughtiness about reddit.
Why?
- You immediately recognized what they meant.
- They weren't advancing a claim, they were indicating a basis for their interrogative, likely to avoid seeming naive when claiming it out of nowhere.
- The article we're commenting on describes the same mechanism you claim differentiates iOS. ("register in advance...which applications...intends to query, and the list needs to be very short and motivated.")
- I've worked heavily on iOS and Android since 2009. As close to a graybeard as you can get in mobile. I'm searching, reaching, grasping for any sign you've done anything other than Google and link the first article you saw, and I can't find _any_. At all. But I don't think that's wrong. You're trying. Why is it wrong for the person you asked to try too?
- There's strong signs you didn't read the article we're commenting on.
- If you had, it is unlikely you would have said iOS was differentiated, then laid out the exact same mechanism described in the article.
- There's strong signs you didn't read the article you linked.
- On iOS you can register URL schemes in a plist, these aren't "external applications you intend to query" and the list does not have to be "very short and motivated"
I get cranky too, but, I am grateful I recognize it is very reddit to cry Reddit and edit it out, or delete.
What could possibly indicate I didn’t read the article? Of course I read it. Isn’t your assumption of my bad faith also explicitly against HN’s guidelines?
> On iOS you can register URL schemes in a plist, these aren't "external applications you intend to query" and the list does not have to be "very short and motivated"
I’m also an iOS developer- and yes it does.
What I laid out, namely, that you described iOS the same as the article, while simultaneously claiming iOS differs significantly.
> On iOS you can register URL schemes in a plist, these aren't "external applications you intend to query" and the list does not have to be "very short and motivated"
> I’m also an iOS developer- and yes it does.
Which part is "yes it does"?
We both can agree quite quickly that URL schemes in a plist aren't "registering apps." You can drag this out a couple turns by playing shell games first by ignoring the URL schemes difference, then by making me do the leg work to show it's trivial to find apps with dozens of apps in that list.
Either which way, I continue to be taken aback by your snarkiness towards the original post and cries of Reddit given you know you were 100% wrong on this.
You're in a really bizarre situation where too much territory was staked out and you're defending it all: you can't claim this was a remotely accurate description and you read the article about Android and iOS is different. It's already a farce, then throw in scolding about how HN is Reddit because of low quality posts...my goodness, my friend.
> Of course I read it. Isn’t your assumption of my bad faith also explicitly against HN’s guidelines?
No, because I said "There are strong signs", I didn't say "You didn't read it."
Also, why would not reading be "bad faith"?
You are extremely focused on making attacks and perceiving them in others, please take a step back and note: "But I don't think that's wrong. You're trying. Why is it wrong for the person you asked to try too?" - you shouldn't have to make up an interpretation where gently chiding you for being rude turns into invoking rules and accusing you of bad faith
They were using this trick to detect unauthorized apps on the phone.
https://blog.verichains.io/p/technical-analysis-improper-use...
[0] - https://gist.github.com/wh1te4ever/c7909dcb5b66c13a217b49ea3...
On Android if they use the work profile (which is the standard method these days) they can only see the apps inside there.
Account driven MDM enrolment pushes the Pareto front when it comes to privacy/conveniency compromises from my point of view. I will ask my IT if they have already looked at it.
If you have the self control to refuse to ever check Slack and disable all notifications/etc on your personal phone when not on call, this doesn’t apply as much. But for me I default to trying to stay on things and forcing myself to disconnect is a net good, even if it does mean I carry two phones at times. My pockets are large.
Android has this really well worked out with their work profile. It's like having a company VM on your phone. Really great separation.
But on Apple we can't use a similar option which I admit does exist, but there's too many strings attached (see the discussion above).
The problem is of course carrying two devices with you.
Regardless, MDM installed app visibility is limited to those users who opt-in to an organization managing their personal device, and isn't an effective way to broadly gather what apps a given person has installed. What's described in this post would work on any user/device, and there's no way to deny/opt-out of specific permissions.
[1] https://developer.apple.com/videos/play/wwdc2021/10136/ [2] https://support.apple.com/guide/apple-business-manager/use-m...
Fun fact from the MDM implementation - the most private way (at least to the company policies) to have a company-connected device is to buy a separate phone and install company's MDM on it. On company provided devices, the company may locate company's assets at any time but doing so on a personal device is a privacy breach.
The bad part of this is that apps have to specifically support the multiple profiles option, otherwise they can't be used for this.
And yes, I agree, that is the best way. We have the same restrictions for personal devices. Though I as an admin know we never use the locate functionality (and I know every person who has access to it).
The reason is that Apple demands that the UPN (the account ID) and the email address are the same. For us this is not the case (our UPN is our employee number as an email address, whereas our email address is just our name). And obviously we're not going to change this for ten thousand users because Apple wants to (most of which don't have Apple devices because we're a European company). Also, you have to manually decide what happens to each user that has already created an account with their corporate email address and what to do with the content they purchased on it. This is not feasible for a large corp. We have commented this to our Apple account manager for years and years but they simply don't care. If you work in this realm you probably know that Apple doesn't really care about things that matter for their corporate customers anyway. The consumer is their main client and it shows (unlike with Microsoft where it's the opposite).
So the whole account-driven enrolment (User Enrolment) as well as everything else depending on managed Apple IDs like DEP for Macs is completely out of the window.
The problem in my opinion is that I as an admin can simply query for example all the employees that have something like Grindr installed. Considering the current political climate in the US (or worse, the middle east where this can lead to a death sentence in some cases) it's obvious why this is super bad. And really, why should we be able to do this at all?
Recently, they released a major update to their LLM feature and I installed the app to check it out. While I had the app installed, every time I checked the mobile website there was a large banner directing me to go to the app. Ad blockers and distraction blockers would not get rid of it. When I deleted the app again, it was gone. What gives? Why does the mobile website know whether I have the app installed? How come content+distraction blockers are enough to block all reminders to use the app when it's not installed, but are irrevocable if I have the app installed?
https://developer.apple.com/documentation/webkit/promoting-a...
You can get rid of them with the Unsmartifier extension.
https://old.reddit.com/r/apple/comments/q55753/unsmartifier_...
The StopTheMadness extension can also remove them (among many other things... this extension is a must have for me):
https://underpassapp.com/StopTheMadness/support-ios.html
JFC. Are they disabled if you ask for the desktop site?
To clarify - the mobile website doesn’t. It has meta tags that tell safari what app it’s tied to, and safari displays associated the app banner.
You could try to communicate with an app via the custom URI scheme and if it succeeded, it would know you have the app installed. Twitter used this for finger printing.
An app has to get a special intent and has to list the apps it wants to use it for.
One of the biggest incentives for creating apps is to scrape all kind of data from the users. Look at how many apps require permission to see you contacts. And how many actually need your contacts to function. That's why I'm still a bit surprised that many seem to be surprised by findings like this one here.
I read a fiction book years ago where there were cameras everywhere. To get privacy, instead of hiding their identities the protagonist paid companies to insert bogus information into the information brokers’ network. So if they tried to figure out where they were on a certain day, 20 records would match. I think this is a much more likely vision of the future.
That is, again, not require but ask for on iphone. I have zero non-functioning apps on my iphone due to denied access to contacts. Even a chinese bluetooth light controller doesn't dare (while refusing to work on android for the same reason).
You can hate apple/iphone ecosystem all you want, but let's not sneak false claims into how they actually work.
You don’t have WhatsApp then.
It is so annoying that it’s either "give access to ALL my contacts and ALL their information (yes, even the notes I took on their favorite things for next Christmas)" or "don’t give access". I wish we could limit the number of contacts and the level of information we give.
Same with storage scopes: one directory and that's it.
iOS added fine-grained (at the contact level) access to contacts data last year.
https://lifehacker.com/tech/you-can-control-which-contacts-a...
Many apps have not updated and perhaps never will.
For example I know Slack still doesn’t use the single picture picker. They still want access to everything.
So iOS lets me limit what they can see, but it’s still a pain compared to just letting me pick the one picture I want.
https://blog.verichains.io/p/technical-analysis-improper-use...
I’m amazed Android still allowed this in 2022.
[1]: https://lsposed.org [2]: https://github.com/M66B/XPrivacyLua / https://github.com/0bbedCode/XPL-EX [3]: https://appops.rikka.app
Interestingly XPrivacyLua is not supported anymore and the pro companion app will be removed from the Play store by Google because it uses the permission QUERY_ALL_PACKAGES.[1]
[0]: https://github.com/M66B/NetGuard [1]: https://xdaforums.com/t/closed-app-xposed-6-0-xprivacylua-an...
I've also never heard of the majority of the apps being analyzed or tracked. Must be such a different world out there.
In other words, the richest demographic used certain apps and was equated to folks in Mexico, followed by the less rich equated to folks in Indonesia and the poor to Sub-Saharan Africa.
>I'm still not sure what the idea of "multiple Indias" means when some of them are Mexico and some are Africa...?
Is it not pretty obvious? It is like the phrase "middle America". It doesn't literally mean a different country. It means different wealth categories: the Indians that when considered as a whole are economically equivalent roughly to Mexico, those roughly equivalent to Indonesia (poorer) and those roughly equivalent to Sub-Saharan Africa (poorest). There are ~1b Indians that are still so poor they aren't realistically in the market for your startup app if it wants its customers to ever spend anything, there are ~300m Indians that could be in the market for some apps, but probably mostly free ad-funded ones, and there are ~150m Indians that are quite a good market because they will happily spend money on something that provides value.
I got all this just from reading the post btw.
These people are extremely snobbish in person when you go past their sweet talks, who don't understand much about people. I hated the "real" interactions and went back to being an IC in big tech.
Part of it is because they don't understand them, part of it is because they "understand" via someone else who told them stuff (like a redditor assuming everything on r/india is true), part of it is their own contempt of culture due to previous reasons ("ah these people are beyond any repair!"). Basically, ignorance in elites.
I learned this watching a stand-up routine by Malaysian comic Nigel Ng. He was explaining his first name.
It is for fingerprinting purposes
Fingerprinting is an identification mechanism. It is most commonly used for targeting and profiling.
Hopefully the El Salvador deal is a far cry from the internment camps from the 19th & 20th century.
Here is some more information about the conditions in these prisons in El Salvador, CECOT being the most notable one:
> Able to hold 40,000 inmates, the CECOT is made up of eight sprawling pavilions. Its cells hold 65 to 70 prisoners each. They do not receive visits. There are no programs preparing them to return to society after their sentences, no workshops or educational programs. They are never allowed outside. [2]
I believe the term gulag makes sense in that context despite it not being a forced labor camp. Not sure how this relates to Russia at all (apart from the origin of the term obviously).
[1] https://apnews.com/article/rubio-trump-deportations-usaid-f7...
[2] https://apnews.com/article/el-salvador-us-rubio-prison-de912...
Well, not yet, anyway.
Politicians, law enforcement, high value targets, etc. A list of apps on their phone could totally be used against them and is better than no list of apps.
Same with banks apps, if you are a scammer it's really useful to know beforehand what kind of bank the target uses.
There are probably a whole bunch of groups who have a purposes for this kind of info, especially if they can link it to the phone number.
Google refuses to patch this. I wonder what would happen if you submit it to the Android VDP as a permission bypass.
There’s also this SO question by the author about the bypass: https://stackoverflow.com/q/79527331
> Google refuses to patch this
While I don't believe Google engineers are not aware of this widely used loophole, do you have any source that they refused to fix it?
Do you need someone from Google to explicitly write an official note, notarized, indicating they are refusing to fix it?
Google addressed similar isolation concerns (without breaking a tonne of APIs in incompatible ways) with Private Space and Work Profile: https://source.android.com/docs/security/features/private-sp...
I also think that private space do not fix the underlying issue. If you have four apps and you don't want them to know about each other you can put one of them in main profile, work profile, app locker and you run out of profile for the last one. The way app locker work doesn't scale to tens of sandbox.
You can have more users on the "standard" AOSP Android as well, but with a certain AOSP-derived you can also have notifications forwarding.
Until they add Application List Scopes (I believe it's on the road map), in the exactly the same way users can now lie to apps they have only specific contacts in their contact list and only one or two specific folders in the Storage.
they keep releasing overly complicated features to sidestep the obvious reported vulnerability, to silence power users and please corporate enterprise sysadms.
the rest of the 99.9 of users keep the vulnerability, which is very profitable for ad networks. wonder why an ad networks who maintains android would do that.
That's why projects like XPL-Extended (and previously XPrivacyLua), are an absolute need. I never run an android phone without these.
> these are user, platform, and developer (implicitly representing stakeholders such as content producers and service providers). Any one party can veto the action.
How is this not anti-user? It explicitly states that the app developer should be able to veto my decisions...
I can see how such a setup is hostile to power users, but then Android is used by 50% of all humanity, and your guess is as good as mine as to just how many want "sudo make me a sandwich" level of control.
With absolute security, you can rest assured that only Google has access to all of your data, and only Google is allowed to turn off the siphoning.
Granted, I'm not suggesting that everyone should root their phones, in fact in recent years I even stopped suggesting it to my tech-savvy friends (that is unless they approach me for advice).
I don't need to lecture about these things but all those who've rooted their phones know the huge advantages—power and control one has over one's phone is enormous.
For example, some apps contain so many trackers that normally you'd never use them except they're the only apps suitable for one's purpose. Rooting allows you the user to take control and have them do what you want and not that of the developer.
Yes, rooting has its risks but for my purposes its benefits far outweigh them.
Hopefully GrapheneOS deliver on their promise to provide a better backup solutions than seedvault.
> The term [rooting] generally also includes the functionality for making runtime code patches (eg. with Zygisk) and making runtime filesystem modifications (eg. Magisk modules).
> Out of the many root-enabled apps I've studied or reverse engineered, the vast majority fail to handle arbitrary inputs properly (especially filenames). For example, some root-supporting file managers turn a seemingly benign action like listing a directory into local privilege escalation. This is trivially exploitable, especially with browsers auto-downloading files with server-provided filenames to /sdcard/Download/.
To avoid repeated root access UI prompts, some apps spawn a long-running shell session, write commands to stdin, and rely on parsing stdout and searching for the shell prompt to determine when commands complete. This approach is prone to desync, which can lead to commands being skipped or other inputs being interpreted as commands.
All in all, I simply do not trust most root-enabled apps to not leave a gaping security hole, so I avoid them entirely. There are apps that do handle root access in what I would consider a more proper way, by spawning a daemon as root and then talking to the daemon over a well defined binary protocol. Unfortunately, this approach is the extreme minority.
I think, for the tech-savvy, the latter is more accurate and I think it is very important to be able to crack open these sandboxes and tinker with processes. Be it to inject ad blockers, automate them, modify their appearance, etc. It should be a right of a user to be able to do these things.
Malicious apps sneak through the vetting process all the time.
Genuine, honest apps have to process unsafe content (be it we pages, messages) all the time.
One exploit should at most make single App vulnerable, not expose everything I have on my phone.
Strong, restrictive sandboxing, memory and execution protections are the only safe way.
And how is destroying the sandboxing related to having more rights as a consumer? You could still patch and repack them in the way Lucky Patcher does with ads, for example?
Anyone tech-savvy that wants to mod their Android (like they'd mod Linux distros), should consider purchasing Android devices (like Pixel) that support ownership transfer (that is, unlocking then relocking the bootloader), and flash CalyxOS/GrapheneOS usereng/eng builds.
For a few months all the UK banks I have accounts in send the list of all apps to the mothership.
I noticed it first when suddenly Revolut refused to start up because I had an app installed, Natwest and Nationwide at least inform prior to the data collection, but weren't concerned.
It ended up with the long overdue confinement of all the banking apps in their dedicated profile, but I'd love to be able to confine them further.
This is disgusting and the reason I don't use iOS. The utter lack of firewall! (plus the batterygate scandal)
not recommended to run insular anymore. use Shelter for a14
https://hachyderm.io/@evacide/114184706291051769
At that point, Android prompting if random game you just downloaded should be your defaut launcher seems pretty dangerous interaction for sneaky apps to risk. They either cause the user to bounce and report or the fools select it as default launcher, replace their launcher, can't provide the launcher functionality and break the user's home screen and end up getting reported in Play Store. I also assume actually getting published as a launcher-class app at that point brings automated testsuites and other requirements that will be burdensome for developers.
According to Exodus it has no trackers and it's an open source app also so you can see what it does (though tbh I didn't check that for the mobile one)
If there's apps to call out there's way worse than Obsidian.
Surely Obsidian do not to see all files on the device, it only really needs to see the files the user needs it to see.
On FreeBSD I can build a full copy from source (in fact I have to, there is no binary package). The only issue seems to be licensing, not source availability. Personally I don't care about licensing (I completely ignore it all anyway) and it doesn't stop you from inspecting the source code.
I think Obsidian is a really great package, I just happened to have moved over from OneNote which is horrible Microsoft mediocrity and doesn't even have a Linux app. And the web version is really useless, it needs to refresh every day and it can only search within the same tab, not a whole notebook. Such a mess. Obsidian is so quick and efficient <3 And there is full self-hosted syncing available, which I also use.
May be the freebsd build is using some binary library packages?
A cursory search indicates that one of the freebsd 'build-scripts' used for installing obsidian uses a binary package for obsidian itself, not building it from source.
It strange that about obsidian which seems to be rather popular here has many people thinking that it is open source, when it is not.
That's just a user contributed thing though. It's also just in the official ports collection. There's only a makefile there and some config files for electron (electron is kinda a PITA to compile on FreeBSD because there's no package)
Now, it can update itself automatically but it's all JavaScript. No binaries.
But it's safe enough for me anyway. Especially because the dev community uses it do much. If it did something untoward it would be noticed quickly.
Personally I use it with Storage Scopes on GrapheneOS.
'Extreme' my a*. My bank app has this permission, as well as my camera app, contacts app, clock app, Google Home, and on and on. My bank app was moved to an old iPad because of this.
I was kind of surprised
https://discuss.grapheneos.org/d/13302-query-all-packages-pe...
https://discuss.grapheneos.org/d/7800-how-to-mitigate-identi...
Later
For the wider audience: though don't take this as GrapheneOS doesn't care about privacy. I'm sure there are reasons (I didn't read all of the linked threads) and it gives you plenty of other protections and tools - eg profiles, ability to disable all network access by app etc
> I'm sure there are plenty of system APIs providing this information too, and I don't just mean APIs designed to directly provide the information.
> It's not useful to prevent directly getting a list of installed applications without preventing detecting which applications are installed, so this specific feature request has to be rejected. It would have to be part of a larger, much more comprehensive feature preventing apps from finding other apps. That implies outright preventing communication with non-system components which is a much different approach to applications and rules out a lot of things. [...]
> The request should be for preventing apps from discovering which apps are installed, since anything less than that has no privacy / security value. There's no point in disallowing access to a list while not preventing discovering which apps are installed anyway.
The open issue to restrict app visibility is [2].
[1] https://github.com/GrapheneOS/os-issue-tracker/ issues/149#issuecomment-553590002 [2] https://github.com/GrapheneOS/os-issue-tracker/issues/2197
Privacy is not an on off switch, it's about making things leak data less.
I really don't understand grapheneos development sometimes, like when they refuse to make a setting to invert the back and recent button. Yes it's not part of AOSP but it's so simple to do and a feature that all manufacter offer because people want it, refusing to do that is weird imo.
With browser fingerprinting, the ad companies are already regularly pulling many shenanigans; I don't see a reason why this would be different.
Big companies like Swiggy and Zepto will mine the F out of your data. Some of it is for their benefit but some of it they could sell in the future. These so called founders are really just another wolf of app street looking to pump and dump. So when they do dump, or when some VC comes with money, they don’t just sell their app they sell it as a whole package of data and analytics that some company can use to sell their product or something VC can leverage to sell their stock to someone else. It’s not that difficult.
As far as smaller apps go these apps outsource their development to people who come with ‘packages’ to develop and maintain their app. These packages are the same logic as above but it’s just that they come from some template so you might be asked for location permission or camera or microphone by some really random app that has nothing to do with it.
While the quality of iOS is degrading, some of these things are really important and simply work better on iOS.