-
On android there are permisions. If you use a foss app, for example a text editor with zero wifi permisions you are pretty safe from tracking on the apps part. Although storing important notes in plain text can lead you to being comprimised. You can use an offline foss text encryption app then in that situation you really are protected from tracking.
-
Hmm maybe that’s why Firefox really stopped letting people use addons on android.
-
Apps like vivalda and chromium or edge. But real open source apps like midori, falkon browser, editor text editor or open source.
-
With a good firewall, encryption from the right people, and apps with good permisions it can be posible to use the internet while minimising most tracking done to you.
Removing internet permissions can be done to apps from Google Play Store too. That way even those apps can be blocked from tracking. No need for FOSS apps. However, someone said that apps can still make use of Android Webview or other exploits to connect to internet. Not sure how far this is true.
The whole point of this thread is:
foss IS NOT EQUAL TO zero tracking/ analytics/ surveillance.
People think FOSS is synonymous to the above, but it is not. You have to treat apps from outside the Google Play Store with even more caution.
Yes, the concern toward “Webview or other exploits” is valid.
. Android | Madaidan's Insecurities
Firewalls, such as AFWall+ or Netguard, are regularly used on Android to attempt to block network access from a specific app, but these do not reliably work — apps can use IPC to bypass the restrictions. If you cut off network access to an app, it will not prevent the app from sending an intent to another app (such as the browser) to make it make the same connection. Many apps already do this unintentionally whilst using APIs such as the download manager.
The most effective way to block network access is to revoke the INTERNET permission from the app like GrapheneOS allows you to do. This prevents abusing OS APIs to initiate network connections as they contain checks for that permission, one example of which is the aforementioned download manager. You should also run the app in its own user or work profile to ensure that it cannot abuse third party apps either.
related discussion here: New Firewall features: Logging, IP ranges · Issue #389 · GrapheneOS/os-issue-tracker · GitHub
1 Like
That’s very scary.
Very interesting.
One of the biggest reason I use a OnePlus device is because of the built-in firewall in Oxygen OS. Color OS (Oppo) too has the same feature. Hope they don’t remove this feature in their integrated new OS.
Xiaomi devices too have it, but they have deeply integrated it with their Security app, which does a lot of other stuff which are quite unnecessary. Samsung, Vivo and Pixel (and probably Motorola and Nokia too) don’t have that feature.
While the article warns against unlocking the bootloader, it still recommends GrapheneOS. That’s contradictory. I’m anyway against custom ROMs because there is a lot of risk in using them. No one knows the developers and what they have baked into the codes. People are only interested in features, which is very simplistic.
For my use, I am fine without unlocking bootloader and rooting. Stock ROMs are less risky than custom ROMs.
It’s probably understood but not explicitly stated that installing GrapheneOS involves re-locking the bootloader and having verified boot…
PS. Some think madaidan is another alias of GrapheneOS’ developer but theStinger didn’t admit it.
2 Likes
PS. Some think madaidan is another alias of GrapheneOS’ developer but theStinger didn’t admit it.
They are absolutely not the same person.
1 Like
I disagree here. Just being FOSS doesn’t mean an app is absolutely free from malware, but malware is pretty prevalent on Google Play.
apps can use IPC to bypass the restrictions. If you cut off network access to an app, it will not prevent the app from sending an intent to another app (such as the browser) to make it make the same connection. Many apps already do this unintentionally whilst using APIs such as the download manager.
Re: IPC: Apps can only IPC to other apps in a very restricted manner (for example, if other apps have exported its components explicitly, or if the other apps are signed with the same keys as the app trying to IPC with it).
Re: Intent to browser: Well, that can be sent even when by any app that does not have Internet permission. Unless I am mistaken, removing Internet permission of an app (like how GrapheneOS does) does not prevent it from throwing arbitrary Intents at apps that do have Internet permission (like browsers).
Re: Download Manager: Apps can abuse DownloadManager, though DownloadManager itself can be blocked by the firewall. But yes, removing Internet permission of an app does disable it from using DownloadManager, whereas a firewall like NetGuard / AfWall+ will not do so since they merely track and block connections owned by the blocked-apps (DownloadManager is the owner of downloads it initiates for other apps too, and hence userspace firewalls may not block even if the download was triggered by a blocked app).
The most effective way to block network access is to revoke the INTERNET permission from the app like GrapheneOS allows you to do. This prevents abusing OS APIs to initiate network connections as they contain checks for that permission, one example of which is the aforementioned download manager. You should also run the app in its own user or work profile to ensure that it cannot abuse third party apps either.
Right: This is one valid approach, but a very limiting one. For example, well implemented firewalls can also let you disable access to an entire range of IP addresses, which a GrapheneOS-like firewall can’t.
I guess, at the end of the day, it comes down to, what is it that you want to block. To me, the answer is always “block all outgoing TCP/UDP to IPs except the ones I trust”. It is not per-app, since that’s too coarse, but I can see why that works for some people. It doesn’t work for me.
(disclaimer: I co-develop a user-space firewall+dns client for Android)
2 Likes
I co-develop a user-space firewall+dns client for Android
Why dance around it? RethinkDNS, correct?
Edit: you did this weird dance back here too Blokada anti-features: Paid features and trackers (!8536) · Merge requests · F-Droid / Data · GitLab
Edit: I don’t mean this in a rude way or anything, I’d rather you just say it out that you are one of the devs.
1 Like
You say dance and then quickly turn around and point out that you don’t mean to be rude? May be try using more neutral words to reflect your intentions better.
There’s no dance here: I did not mention RethinkDNS because I am not here to promote it by forcing it into a discussion where it isn’t mentioned at all.
Edit: you did this weird dance back here too https://gitlab.com/fdroid/fdroiddata/-/merge_requests/8536
Okay, I’ll bite. What problems do you have with that merge-request? Which dance moves did you not like? Genuinely asking because that merge-request is me trying earnestly to do right by the F-Droid community, and informing them what I knew for 5 months but saw little to no response from Blokada AB employees. All I get in response these days to that merge-request is non-stop abuse.
1 Like
@ignoramous
Whoa there.
I was in favor of that merge myself.
I explicitly myself haven’t recommended Blokada and even removed it from my recommendations long ago for other reasons.
RethinkDNS is a neat app and is available on F-Droid, I don’t see anything wrong with you giving it a mention.
3 Likes
This, as a blanket statement, does not stand.
Right in this topic, SkewedZeppelin (DivestOS developer) is participating among us. LineageOS and DivestOS and CRDroid and several other projects maintain publicly available source code repositories and they even provide DIY build instructions. I do not want / need / care to “know” the LineageOS team, except perhaps the person who is maintaining the build for the specific device(s) that I am using. Know, as in, know how to contact, and gauge (in advance) how receptive they are toward merge requests.
While Google Play Store may not be completely free of malware, there is still plenty of safeguards in place, which I believe is much superior to unofficial platforms. It is in that context that I used the term ‘even’ more caution.
That’s a little reassuring. Google would have thought about it when designing the OS.
More than downloading, the bigger concern is if local files can be uploaded. That’s because even if an app downloads something, user has a good amount of control on what’s next. Android allows plenty of control via app permissions. Is it the download manager that manages uploads too?
I always block internet access (using OS built-in feature, where available) to apps that shouldn’t need it for core functionality. If the built-in feature is not available, I have to rely on 3rd party firewall like Netguard or Karma Firewall. I have always done this thinking this would prevent the app from connecting to the internet completely. This wasn’t necessarily for blocking ads, but just that apps that require local permissions like storage, contacts, camera, microphone, etc. shouldn’t be misusing them.
Now I see that there are still ways for apps to communicate with their servers despite the methods above. But I hope there are sufficient safeguards in place within every OS to prevent such abuse.
Is there a way to block apps from sending out intents too? Atleast block them from sending intents to the downloads manager, browser, Webview, Google Play Services, etc.?
Is there anyone auditing those publicly available codes or repositories? And doing it on a continuous basis?
And how secure is the platform where these are hosted?
The concern posted in this topic is how platforms can be exploited by someone who has a malafide intent. Obviously, it doesn’t apply to all developers.
If I answer “yes” and “yes” to the above, would you believe me?
Consider: the LineageOS “android_frameworks_base” repository
. GitHub - LineageOS/android_frameworks_base
has 800 child forks. The majority of the forked projects represent folks who are DIY builders (no intent to distribute a further customized ROM). They each have a vested interest in keeping abreast of changes//progress in the parent project, and will regularly browse and read the commitlogs describing each change… and (at the moment, 30 merge requests are open) may be motivated to suggest further changes (or reversions) to the parent project.
And how secure is the platform where these are hosted?
This is a good (important) question. What do you believe is lacking, security-wise? What additional measures are you inferring might (should) be taken? Are you, as a critic, even aware of what measures are, in fact, already in place for a given project?
NOT anti-Google. Instead, they are anti-Tracking. Google is just one
this, from the OP, does accurately reflect my sentiment FWIW.
has 800 child forks
Count of forks is meaningless.
- lots of people fork a repo to simply have a copy of it.
- GitHub advertising is/was “fork me” for a while
- some people use forks to make their GitHub more appealing on a resume
30 merge requests are open
This is even more meaningless, as LineageOS doesn’t accept merge requests via GitHub. GitHub prevents disabling of this option.
Development of LineageOS is done on their Gerrit instance: https://review.lineageos.org/
And here is CalyxOS: https://review.calyxos.org/
And the upstream official AOSP one: https://android-review.googlesource.com/
Overall the general sentiment of many eyes being on the code is impossible to measure.
However we (those of us downstream AOSP) still find things.
ie.
- Sometimes we’ll tell each other
- sometimes we’ll think its obvious enough that others already saw
- sometimes we’ll come across what the other has found
- and sometimes it just sits there unfound.
I had typed some examples, but I don’t feel like writing a whitepaper’s worth of paragraphs on them.
2 Likes
This is “the next big issue”.
It has become reasonably possible to craft decently secure systems.
However supply chain attacks don’t care how many walls you have.
Reproducible builds are one way to improve this, but I’ve seen some experts say that they are instead a waste of time.
You’ll always at one point have to trust to an extent someone or something, because none of us have infinite resources (time or money) to control our entire stack.
2 Likes
I would be surprised. Can you reveal who is auditing them on a continuous basis? As far as I know, people are simply taking the codes and then modifying it a little to present their own versions. And I also don’t see the motivation behind spending resources in the audit. The custom ROM community of users is a very tiny minority, and as a free product, there is even little motivation.
In the madidan link, it was interesting to read that Lineage (the only custom ROM that I was earlier trusting as safe and reliable) isn’t safe either.
No, I’m not.
I don’t have a technical background, so I can’t comment. But I’m skeptical because of the enormous potential to exploit free platforms. As they don’t have the funding or resources like large corporations to develop and maintain a secure platform.
I’ll quote myself from another platform:
It is the most apt way to sum up their site, without divulging into other unncessaries.
3 Likes