I don't use Mullvad, but I respect the shit out of them. This is a good, information dense explanation of the problem, their short term workaround and potential workarounds for others, as well as what will need to be fixed in Android. Good stuff.
I was a bit surprised to walk onto a DC Metro car last weekend to find the walls plastered with ads for Mullvad. Just wanted to note that Mullvad is spending money on traditional advertising, as well as blog posts like this.
Mullvad's "Stop chat control" ads have been all over Stockholm a few months ago, including this giant banner in the airport. This is the kind of advertising I respect.
However I'm worried that their goodwill and values will become more valuable to some private equity corp that buys them to asset strip and squeeze their customers.
I'm sorry you feel that way, but I can relate. I initially had mixed feelings about it as well.
On the other hand the campaign we did in Stockholm last year worked out quite well. It managed to affect both domestic and EU legislative discussions at the time. Or at least our campaign contributed to moving the discussion in the right direction.
How much is that worth? I'm not sure, but the reason we started Mullvad in the first place was to conduct political action through entrepreneurship, specifically regarding mass surveillance and censorship.
If nothing else it seems to amuse a lot of people, including me and my colleagues. When I first heard of the idea of plastering privacy propaganda all over some major U.S. cities my initial reaction was more or less "lol, we can just do that?". As it turns out we can. :)
Thank you for sharing that! I am definitely part of the HN group think that tends to be irked by mass marketing- mainly because of baggage from the past of false advertising. However, I do agree that getting the non-IT geek's attention is what would actually move the needle for political action. I was amused (mostly surprised) to see a billboard while driving down the 110 in LA. More importantly, it led to a cool discussion with my non-tech wife who now appreciates your guys' brand more. :)
As frustrating as it is, even great products don't sell themselves. I find much, if not most marketing for subscription-based services pretty scummy, but it's not like it has to be, and I'd much rather see physical ads than how most stuff gets surreptitiously slipped into my surveillance-capitalism-sponsored life.
Since there's no existing compendium, maybe a social media contest for people submitting photos of anonymized objects (e.g. in a box), books (hardback with custom cover), humans (costume/mask/etc) with Mullvad ads / billboard in the background. Crowdsource field reporting and motivate discussion about metadata in online and offline privacy.
Okay, this comment was the comment that got me sold on Mullvad. I was looking for a VPN I liked anyway and if you also use your business entity to help drive legislation toward a more privacy focused end, I'm in.
For me, (one of) the moments was when there figured out how to do remote attestation of the server to check that what it was running was what you expected, so you could check its privacy yourself.
Rather a neat subversion of the common corporate use of remote attestation, to preserve user privacy and security rather than curtail it.
Thank you! You are of course referring to System Transparency. I feel obligated to point out that we have yet to fully implement that idea. I've been working on it, and the related projects Sigsum and Tillitis, for the past six years. There have been lots of detours, but we are making progress towards the vision outlined in the blog post I wrote in 2019: https://mullvad.net/en/blog/system-transparency-future
Two years ago we moved the OSS projects System Transparency and Sigsum to its own organization: Glasklar Teknik AB (glasklarteknik.se).
The OSS and OSHW project TKey was moved to Mullvad's other sister company Tillitis AB (tillitis.se)
Thank you for the service that you and the rest of the team provide. I've found it to be excellent, and you're one of only a very slim number of transparent VPN providers who seem to be in it for the right reasons.
How did you measure the effectiveness of physical ads to issues and other key metrics? I’m just curious what it takes to measure those as it’s always been mysterious to me. It seems like it needs to include a coupon code or something? Also interesting re: legislation. How so?
To my knowledge we don't measure it, at least not in the way I think you mean.
I can't speak for my marketing colleagues but I would assume they reason about it. It seems like a complex system to me, which means the approach kind of has to be (1) forming an understanding of the system and (2) deciding whether one is comfortable with the uncertainty.
One aspect that makes the cost/benefit assessment quite a bit easier is that we don't only care about how many new paying customers we get. It's also fun to do this kind of advertisement. How many interesting conversations about privacy have been had as a result of people seeing our billboards? That's worth something too.
thank you for offering up in this forum at least your own personal contributions to your organization's position on its advertising campaigns. not sure if any official statements on the matter have been made elsewhere, but you've assuaged at least my own slight concern about it with this one. truly. (and by 'truly' i mean i've been meaning to stuff some cash in an envelope addressed to you guys!)
I’m fanboying at this point, but I honestly believe Mullvad should be the poster child for a lot of things other companies should be doing. Transparency, accountability, data minimization, thorough documentation, publicly available audits, etc.
What is it about a company spreading awareness about their product that weirds you out in particular, I'm curious? Billboard advertisements are an awareness type of advertisement. I'd be much more concerned to learn about paid endorsements, which they document on their website that they specifically do not do. Endorsements are a much more sensitive form of advertising, where once money trades hands for an endorsement, it stops being a useful third party assessment and starts being an advertisement disguised as a third party assessment. Awareness advertisements just make good business sense, so I'm genuinely curious why those would shy anybody away.
I agree with you, but I also understand where GP is coming from. For the past 20 years, what people are mostly exposed to is internet ads, which are, to put it mildly, pushy. As a result, all ads now have to deal with considerable negative sentiment as a baseline simply by virtue of being ads.
I saw them on the side of a CTA bus for the first time the other day. I don’t think it is bad at all, but the initial reaction for me as an American used to typical bus advertising it was exactly as if seeing an ad for 4chan there. It just isn’t the expected modality for the product.
(Seeing the reply down thread from a Mullvad rep, this is not unexpected)
Mullvad itself is extremely clear that use of a VPN alone is not enough for the reasons you stated. Mullvad VPN (which is what they advertised) is a suite of products and services, some of which are:
- DNS services (ads, tracking)
- A privacy-optimized browser (cookies, fingerprinting)
- Network services like multihop routing (many benefits such as resistance to timing attacks)
All of these services are included with your subscription at no additional cost. I feel like the claim of preventing ad tracking is as legitimate as it could possibly be.
This can be instantly disproved by examining the cases where valid warrants were presented to them by LEAs and they were unable to provide any user data.
Also they actually make it easy to use their services without providing any data - you can use them by paying Monero over tor, and the only thing identifying you is a short unique "identifying number" - no emails, no names, not even an account.
I find their gimmick of "buy a physical gift card from Amazon, scratch to reveal one-time code" to be pretty genius. It's just a bulk pile of cards, Amazon records you bought one but doesn't know which one (and the actual code is under a scratch-to-reveal surface).
Even if a three-letter agency intercepted your package and swapped your gift card with a known code, I believe Mullvad is not recording the connection between specific gift code and the account number.
You can also exchange unscratched gift cards with friends and strangers.
1. We launched Mullvad 15 years ago. During those 15 years people's interest and awareness of online security and privacy has grown considerably, as has the consumer VPN market.
2. Our strategy is quite different from most of our competitors'. As a result we've grown slower than several of them, but we have nevertheless continued to grow year after year.
3. The costs of the campaign are perhaps lower than you assume.
tl;dr We've slowly grown over many years and are now making enough money to plaster privacy propaganda over your city. Hopefully it's an interesting change from the usual bus ads. Enjoy!
Not everyone telegraphs if they're in it for the money.
In some lines of business, like (purely hypothetically) security, it might actually be a bad thing for your business if you do.
I also use mullvad because I don't really think this is the case, but bad actors are generally hard to conclusively identify by design. And VPNs are pretty far out in the "just trust me bro" realm of handing over all your browsing habits with no ability to check their real behavior.
Mullvad is trying pretty darn hard to be as far from "just trust me bro" as is feasible. If you do take their word for how they run their systems (/are working toward), their servers are diskless (what logs?), will only run software signed by their infrastructure team, and will remotely attest that their software has not been tampered with.
This is so very, very, far away from the typical VPN company that any such comparison sounds ridiculous to me.
Just the pretense of doing all this work costs so much that a greedy biz bro simply wouldn't.
Thank you for noticing! System Transparency is taking way longer to figure out, design and build than I expected. On the other hand the project is quite ambitious, and our work on ST has sprouted two additional OSS projects:
On the other hand, if it were an NSA honeypot, doing all that work would easily be worth the cost. Personally, I don't think they are, so I'm merely pointing out that there are angles other than totally above-board honest legitimate reasons, and "greedy biz bro".
> VPNs are pretty far out in the "just trust me bro" realm of handing over all your browsing habits with no ability to check their real behavior.
Yes. It is quite an interesting situation, really. It's also a fun challenge! To what extent can we prove that we are trustworthy, and using what tools? Do those tools exist or do we have to invent them?
You'd have to invent this one at least, as it currently doesn't exist. As the DNS server operator, you can view all my DNS queries. In a zero-trust environment where I don't trust you not to log all user queries and forwards them to the NSA, you'd need to use homomorphic encryption and create a DNS client and server than can do a lookup, without you, the DNS server operator, from finding out what the DNS lookup was of.
https://github.com/menonsamir/spiral-rs claims to have implemented this at a level that's practical for real world applications, with a demo for a wikipedia server, but it's far too slow, as demoed, for use as DNS server.
Now, the fact of the matter is that you can map my account ID back to the IP I'm connecting from, but with very limited way to map from my IP to my identity protects that in many ways, but data-mining at scale, knowing how many users connecting to one proxy server from city X, would be worth something to advertising and related companies who are more interested in large habits of users. If it turns out no one uses the pirate bay anymore, but use torrent site XYZ, I know where I'd place my advertising dollars for, say, a VPN product.
This is on the extreme end, but you asked for a fun challenge! :)
I should've been more clear. The questions I posed above are rhetorical. I've spent well over half a decade obsessing over them. See my mention of System Transparency, Sigsum and Tillitis elsewhere in this thread.
Thank you for your hard work. You've spent way more time on the problem than I. Didn't realize it was rhetorical! Mostly I wanna see homophobic encryption happen in practice. :p
tbh I don't think they exist. And I'm, like, half okay with that - it's entirely justified paranoia, bad actors of all skill levels undeniably exist and they hide successfully for many years, but I do believe good actors exist. It's why I chose mullvad.
At best you have stuff like attestation... but we all know those have a long history of being flawed and are subject to loads of side channels that can't be attested against. Plus VPNs are such a honeypot in every conceivable way that TONS of state-actor-level efforts are entirely reasonable, and that could easily include cheating on basically all attestation systems imaginable. We're just kinda stuck trusting history and lack of public leaks / correlated actions / whistleblowers IMO.
Or, frankly, the Mozilla partnering counts for a lot to me. I won't use their setup because it doesn't have non-vpn-app options, but they're a group I mostly trust to have people's safety at heart.
Personally, stuff like Tor (where by construction you only need to touch a couple good actors to be reasonably secure, and anyone can contribute) is about the only mostly-actually-trustworthy kind of system. You can expect malicious actors to participate there, and still have a reasonable level of privacy, particularly if you check a few personally (which is feasible because anyone can contribute). Tor and similar have plenty of issues, but structurally they're much more sound by design than any centralized VPN can ever be. Now if only they were even a tiny fraction as usable...
I think legally they would have to change their ownership directive document in Switzerland to allow the board of directors to allow the two founders to sell more than 50% of their shares. So you might get a heads up!
A VPN is not enough for privacy. But in combination with a privacy-focused browser, you make sure to block third-party cookies and other tracking technologies used by the data collectors.
The paragraph above is clearly visible on our landing page. We don't want people using our service for things it's not designed for.
The paragraph below is also a direct quote from our website.
"When you visit a website, you can be identified and tracked through your IP address, third-party cookies, all kinds of tracking scripts, and through so called browser fingerprints. That’s why masking your IP address is not enough to stop the data collection. However, by using a trustworthy VPN in combination with a privacy-focused browser, you can put up a better resistance against the mass surveillance of today. That's why we partnered with the Tor Project to develop Mullvad Browser – a browser designed to minimize tracking and fingerprints."
Please show me evidence to back this up and I’ll happily walk back my statements.
The “mullvad” browser is not their VPN product. And if you think DNS denylisting prevents “ad networks from spying on you”, I have some unfortunate news for you. It works to prevent the rendering of a subset of ads (especially in the browser), but isn’t worth a damn for actual behavioral analysis.
I would guess it started with something like this: they serve DNS to prevent DNS leaks when using the VPN. They realize they can use this to block domains, just like a pihole or Cloudflare DNS. They integrate that into their VPN offering.
It's pretty logical once you think about it, but it was a surprise to me too.
It blocks almost all analytics, social pixels which likely covers 90% of the market. Between DNS blocking and uBlock, whatever behavior analysis they can do beyond that doesn't seem to work because the ads I see are entirely irrelevant
I’ve been using and still using Mullvad but also getting worried.
I live in nyc and in the last few months I’ve seen a _lot_ of ads from them. Huge billboards in high-traffic areas. Full-sized ads on a side of a bus. A whole subway car just with mullvad ads.
Some of the ads also felt deceptive making it seem like it will prevent all your online tracking, even though we know that’s not the case.
> Some of the ads also felt deceptive making it seem like it will prevent all your online tracking, even though we know that’s not the case.
I'm sorry to hear that. For what it's worth our marketing colleagues make a big effort to minimize the risk of such interpretations. Sometimes a really snappy string of words can be interpreted multiple ways. There's also only so many words we can put on an ad before it gets messy. We do try hard to make the nuances clear on our website, which ultimately is where any new users will have to go in order to buy the service.
I’m a big fan of your service, but I agree with GP. I rode the subway yesterday and saw a Mullvad ad that strongly implied that a VPN is adequate protection against data brokers and data collection on websites.
It certainly wasn’t the most egregious VPN ad I’ve ever seen, but it was disappointing to see Mullvad imply privacy properties for VPNs knowing that ordinary people don’t understand cookies, sessions, fingerprinting, or JavaScript.
> feel free to describe to HN how Mulvad protects users against ad networks.
A VPN is not enough for privacy. But in combination with a privacy-focused browser, you make sure to block third-party cookies and other tracking technologies used by the data collectors.
That's why we partnered with the Tor Project to develop Mullvad Browser – a browser designed to minimize tracking and fingerprints.
Please also note that this information is clearly displayed on our landing page. We don't want people using our service for things it's not designed for.
ah, now i understand. your earlier comment very much read like you were accusing kfreds personally of making such a statement about ad networks. but you meant to say one (or more) of the ads you've seen yourself appears to makes such a claim. thanks for clarifying.
>"Unfortunately port forwarding also allows avenues for abuse, which in some cases can result in a far worse experience for the majority of our users. Regrettably individuals have frequently used this feature to host undesirable content and malicious services from ports that are forwarded from our VPN servers. This has led to law enforcement contacting us, our IPs getting blacklisted, and hosting providers cancelling us."
>"The result is that it affects the majority of our users negatively, because they cannot use our service without having services being blocked."
I sort of understand their reasoning, then, because acting as a reverse proxy for externally-initiated inbound connections is not typically within the scope of VPN services per se, and especially outside the scope of Mullvad's particular mission of offering VPN services for the purposes of protecting privacy and suppressing censorship.
There are other solutions for your use case, with or without a third-party VPN, that wouldn't require port forwarding. There are also other VPN services that do offer this functionality.
If you don't use a VPN I'll note that they have a DNS service that is free. I think this demonstrates some support, at least in the way that increased traffic/usage can be support (and should help make Mullvad VPN users stand out less WRT DNS requests). The only downside I'll say is that the ping time for me is quite a bit higher than quad9 or cloudflare.
I wrote some info about it in this thread[0], including how you can do ad blocking at the DNS level (and cloudflare info for the same).
Simply the best VPN around, in terms of values, mindset, loyalty to their core beliefs and the relentless proof to stick to their moto over the last decades.
I AM a user of mullvad, and I am extremely satisfied. I once mailed support with a payment question and added a small iptables question regarding a problem I had.
I got back a swift reply which solved the payment question, and a detailed iptables reply with pros and cons of different solutions.
Well I don't know how many IP addresses each of Mullvad's servers have, but they list a domain name, IPv4 and IPv6 address for all of them publicly[1].
Our detection model at ipinfo is largely based on behavior models of IP addresses. We have 700 servers around the world from which we run internet measurement, allowing us to reliably determine which IP addresses are VPNs or proxies. These measurements are largely ping/traceroute data, which enable us to estimate a number of different things most importantly IP location data.
If you are interested in what kind of other information we can discover from our internet measurements, check out our tags page: https://ipinfo.io/tags
Net flows. A residential proxy should have a residential amount of traffic coming from it. If one IP has 1000x the usual traffic one household could reasonably account for, then mark it as a residential proxy. It won't be 100% accurate, but it's sufficiently accurate for reddit to go on a blocking spree.
I am not sure how they do it, but one option is setting some arbitrary threshold for number of devices fingerprinted on a single ip in a given period of time. Something like taking the average number of devices and denying access to ips that they detect ~3 sigma different devices from.
> these issues should be addressed in the OS in order to protect all Android users regardless of which apps they use.
Android's paranoid networking has always had an exception for System and OEM apps (which include Google apps). Most such bugs fixes are unlikely to fix that core assumption. Some code refs: https://github.com/celzero/rethink-app/issues/224
> The leak during tunnel reconnects is harder for us to mitigate in our app. We are still looking for solutions.
Android supports seamless handover between two TUN devices (on reconfiguration). It is tricky to get it right, but implementable.
To be fair, it’s the application developer who requests the application’s permissions and it is possible to release an app without internet permission.
I agree that the OS should have a way to override the permission, but it’s not Android itself just giving out internet access by default. It’s more that it’s almost every developer’s default setting when building the app.
The best example of no internet permission in an app off the top of my head is Hacker’s Keyboard – and you can understand why the developer chose to avoid it.
Which flashlight app? As far as I know there is no official flashlight app (though recently there is a built in flashlight feature). How is Google responsible for a third party app that refuses to work without an internet access?
> Which flashlight app? As far as I know there is no official flashlight app (though recently there is a built in flashlight feature). How is Google responsible for a third party app that refuses to work without an internet access?
GP is saying that the Android permissions model requires giving Internet access to any app you install from the Play Store; there isn't a way for an app to request "zero permissions" (or rather, there is, but basic Internet access is a permission granted to all apps, even when zero additional entitlements are requested).
That said, this isn't unique to Android. At least as of a few years ago, iOS did more or less the same thing. (You can disable an app's access to the local network, but that's not the same thing as denying (or requiring an app to request) basic network connectivity).
The hypothetical flashlight app that was used as an example to demonstrate the problem of not being able to take away the permission to access the internet from an app.
This depends on the firmware used. I am writing this comment from an Oneplus device which allows blocking internet access on a per-app basis - on a stock firmware.
Not universally true, I use banking apps on my Pixel running the latest GrapheneOS. There is literally nothing I cannot do on my phone. I think it's possible that no US banks have apps that can be used as it seems a universal experience among Americans.
Uber, Google Maps, VoLTE, VoWiFi, and eSIM work. You may need to install the sandboxed Google Play Services from the Apps app.
Android Auto is completely disabled as an opinionated security measure.
Google Pay and some banking apps (ones that require Google's Play Integrity API) will not run. GrapheneOS doesn't attempt to spoof these APIs because they are moving towards cryptographic verification [0]. Most apps don't require this check but if they do you are out of luck unless you can get the app developers to trust GrapheneOS's keys.
I think they work if you install Google Play Services (as a sandboxed app). What doesn't work for me is contactless payments with Google Pay however Google Wallet itself works. But I think that is actually intended and for security reasons.
Using banking apps on a phone is dangerous because if your phone gets hacked (and Linux kernel has extremely large attack surface), the attacker gets access to both the app's session and SMS codes that are used to confirm operations. People who use banking apps must be crazy or don't care about their money.
I think I do. It costs money and people in general don't appreciate it. Also while "malware on phone stealing money" is technically possible, it doesn't happen (much?), and most people get scammed in easier and more effective ways (see crypto) instead.
Can give one anecdote: I've been using Graphene for about a year and all banking apps work just fine. In fact, I've never had as little issues with any other custom rom. It's quite crazy just how good Graphene is.
Not a custom ROM maker, though I did get lost trying to plan one for my old Xiaomi Mi A3 (laurel_sprout). Another guy did make a unofficial LOS for it though.
Custom ROMs nowadays require you to be scouring Qualcomm out of tree source repositories (or firmware dumps of equivalent phones, I think, in the case of Mediatek). It's impossible to guarantee quality with this conditions. Even if you just want to have a pristine kernel tree of the original firmware you may find, if it was ever released, it was squashed on the wrong source commit (again, laurel_sprout, though a random Github angel fixed it).
So Google's devices tend, thankfully, to have better sources. Additionally, GOS team is competent and, for now, sustained full-time by donations. Those three conditions are what allow GOS to be a very good ROM.
Do note: it has its quirks, specially with the new trimestral code dumps by Google where half-baked features are on the source (though disabled by feature flags).
there is (or at least can be) some risk tolerance within any so-called 'threat model.' but i absolutely take your point and agree with you.
nary the case but i suppose if i absolutely needed to access any finances from my mobile device, it certainly wouldn't be from one of said institution's own mobile apps, but via web browser.
> i suppose if i absolutely needed to access any finances from my mobile device, it certainly wouldn't be from one of said institution's own mobile apps, but via web browser.
I used to do home banking from my bank's website. Recently, they created a digital-only branch for customers who mostly do home banking and only rarely need to go in person to the bank. They asked their customers if they wanted to switch and offered services at the same or lower cost than before. I made the switch, but found out that unfortunately the new website lacks some functionalities that are only available from the mobile app. I guess they are assuming that most people would just use their phone anyway and didn't bother to reach feature parity between the website and the app, preferring the app.
crazy. it's remarkable to me that lawyers actually do explicitly, if not expressly, account for these kinds of technical decisions, ultimately made in surreptitious fashion by the business, when drafting usage terms. i.e., you would've (or, a lawyer determind, should've) been able to find notice of this change somewhere buried in the new service terms. i at least have faith in that much.
Minor conveniences like this are not worth the complete erosion of privacy, in my opinion. Just go to the nearest ATM to deposit checks (who uses checks anymore, btw?) and use the site for everything else. Not everyone even has a smartphone, and out of those that do, many prefer banking on their laptop over their phone anyway, which incentivizes banks to create feature-rich websites. If the mobile site isn't any good, usually the "desktop site" isn't too difficult to navigate on mobile, if you need to.
>Go for a walk every day, and occasionally make your walk to an ATM?
There are workarounds, but it sounds annoying and a burden. What if the closest bank branch is an hour on foot away? Or the OP lives in a rural place and it's half an hour drive? I don't have this problem since my bank works with graphene, but I would reconsider using it if most applications I use refused to load.
As I understand, it installs a pseudo-VPN and passes traffic through it. I remember using similar app (NoRoot Firewall), and it worked poorly and couldn't block everything I wanted.
GrapheneOS is totally different to having an app on stock android
> GrapheneOS adds a Network permission toggle for disallowing both direct and indirect access to any of the available networks. The device-local network (localhost) is also guarded by this permission, which is important for preventing apps from using it to communicate between profiles. Unlike a firewall-based implementation, the Network permission toggle prevents apps from using the network via APIs provided by the OS or other apps in the same profile as long as they're marked appropriately.
>The standard INTERNET permission used as the basis for the Network permission toggle is enhanced with a second layer of enforcement and proper support for granting/revoking it on a per-profile basis.
> To avoid breaking compatibility with Android apps, the added permission toggle is enabled by default. However, the OS app installation UI has been extended to show the toggle as part of the installation confirmation page so users can disable it when installing an app.
> when the Network permission is disabled, GrapheneOS pretends the network is down. It shows the network as down in various APIs, returns errors showing a network connectivity issue rather than a revoked permission and avoids running scheduled jobs depending on the network. This results in apps handling it as if the network is down rather than crashing or showing errors from trying to use the network and being unable to do it.
Nope. GrapheneOS is an AOSP fork (with not so many modifications) intended to be more secure.
It doesn't do it in a hacky way, these apps just don't get the internet permission. And it lets you install Play Services as a normal app (not a system app) so you choose what permissions that gets.
On Android there is NetGuard which poses as a (local, running on the phone) VPN and allows you to deny / allow traffic based on process and domain. Works great, no root needed.
Then you can't run another VPN right? Then raw through Verizon with their tracking headers and stuff for anything non-https unless you go through the series of opt outs that get periodically invalidated with a new opt out needed.
Just checked, there doesn't seem to be an option for it (though technically it should be possible, I think). Sorry to hear about Verizon - hopefully mobile will soon be a viable option for you. Good luck!
IIRC, there's separate permissions for web access and unrestricted internet access. The former is only apparent if you look for it on install, and isn't something you can disable on most ROMs.
Third party app firewalls exist for at least macOS and Linux distros. It’s likely built in to the system as well, but you’d have to wrangle the command to do it in the terminal.
Did they edit their post? I just see "They don't even allow disabling internet permissions on a flashlight app, the OS is run by an internet ad company so it makes sense."
If you're implying that you need location permission to turn internet access into a tracking problem, you're wrong.
Play Protect and the approval process are mostly make-work because you don't have control over internet permissions--because Google needs them everywhere for their ads business they have to put a lot of energy into this edifice.
This is about the continuous background location permission. In the past years they have cracked down on this, yes. But nothing forbids you from requesting the foreground approximate or fine location permissions.
So yes, this hypothetical flashlight app can request the permission. The user has to allow it in some way - approx or precise, one-time or always. But also nowadays the users sees when & what app is requesting these kind of permissions. It's a moot point.
(For background location there's an extensive form in the play store, you even have to send videos in many cases - for foreground, there's nothing)
This has been a long-standing issue with android, that no matter how much you want it to use internal dns servers only, it'll decide to flip to cell and use those as it needs/wants. I've observed adb debugs for times recently to see why/when wireless was disconnecting, and it comes down to liveliness checks that if it can't see or resolve something, it'll simply bring up and try the cell data to do so.
It's especially frustrating when using internal dns records that only live internal will randomly not work on a phone. I can see that the device is on wifi that is feeding internal dns servers with the records, but it's resolving externally still for some android reason. This happens on my SO's phone when using things all the time, but I really don't use my phone in the house except to read books and rarely notice.
No idea how apple is about this, but the fact they try to proxy everything you do via their "privacy" vpn by default including dns as DOH, I can't imagine it is any better trying to use what they'd see as a competing product, and we know how apple feels about those.
Apple (or iOS) actually has a robust built-in way to filter and block traffic using configuration profiles. I’m uncertain if you can configure it per-app, but you can definitely whitelist/blacklist hostnames. For an example of this in action, check out this system-wide ad blocker https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
In my limited experience, when mybloxx (very rarely) has a problem, it blocks all network access and I have to go in and “reset iOS connection cache” or “reset mybloxx”, two separate options in mybloxx that I’m unsure of what they do behind the curtain.
I hope someone who is more knowledgeable about the configuration profiles can give you a definitive answer.
I could have sworn there was source for it a few years ago but looking again I can’t seem to find it. I think the dev might have taken it down because others were reusing his code according to r/jailbreak
Anyway I do trust the developer, he’s been at it a number of years working on this thing, and most importantly it really does work well, blocking the most amount of ads vs other blockers. He’s obviously not a web dev and the jailbreak scene is kind of scrappy so I can forgive the website. Look past the formatting and see what’s there. If you want to use the method but not run any code you can manually supervise your idevice but you have to backup / wipe / restore in order to do it on stock iOS. The pac scripts are open source and you can self-host them if you’re truly paranoid.
I built AOSP from source. It's supposed to be devoid of any google specific requirements. I went out of my way to block as many google servers as I could in the hosts file just to ensure it wasn't phoning home.
As far as I can tell the only issue I ran into was that despite being connected to a working wireless access point, the device reported I had no internet. It still worked, but it seems for the purposes of the status bar icon, and whatever other underlying system code, it was using a google server to verify internet was working.
I would just stay far away from android if you value your privacy, and probably tech all together.
That would be a pretty expensive mistake considering iOS also has VPN leaking issues that have been reported but unfixed for what, years at this point?
Nope, any phone with a cellular modem ships with unreplaceable firmware that is likely used to spy on you. Failing that, many governments field the capability to forcibly reroute cellular traffic over backdoored networks. You could be using a PinePhone with PostMarketOS and still get wiretapped in any number of ways.
A few years ago, when I was testing various VPN set ups for a project, one thing I would do is have a MikroTik firewall device (hardware) sit between my computer and my main router, it’s only purpose would be to block any traffic, not dst for the IP address of the VPN server that the pc was connecting to.
This worked great to ensure that no traffic was leaked from pc to vpn server. The IP address of the VPN server you’re making use of rarely changes or if it does it’s easy enough to change on the MikroTik firewall.
Another method is to block all traffic not to the port/protocol pair being used by the VPN server if you don’t know the servers IP address (or if it changes). As an example drop any traffic not dst UDP 1194 (based on the type of VPN, of course). MikroTik routers also have a great little tool called torch that allows you to quickly and easily watch traffic (in addition to of course, supporting packet captures. Mikrotik routers are very reasonably priced and range from as low as $30 up to $3000 - all with no software licenses, and they are very powerful and capable if you know what you’re doing.
Can a standard linux distribution be configured as a network slug? I'm sick of companies forcing themselves onto people's private information without their consent.
This worked great to ensure that no traffic was leaked from pc to vpn server. The IP address of the VPN server you’re making use of rarely changes or if it does it’s easy enough to change on the MikroTik firewall.
Another method is to block all traffic not to the port/protocol pair being used by the VPN server if you don’t know the servers IP address (or if it changes). As an example drop any traffic not dst UDP 1194 (based on the type of VPN, of course).
outbound filtering by source and/or destination address and/or port is both a fundamental firewalling concept and standard configuration on all firewall-routing platforms. (policy-based routing[0], i.e. filtering by gateway, is the same.) generally speaking, only the con/prosumer products allow everything out by default.
just curious, what was your "main router" in this setup? ISP-supplied?
It was also a mikrotik - so of course, I could’ve done everything on that one.
however, I had to show / prove to a client that the set up could be easily duplicated at other locations (and moved around) where everything else on the network was unknown (only known / controlled parts were to be a Windows laptop, and the mikrotik router connecting ethernet from that laptop to whatever network also via eth.
For some of the configurations that needed to be very portable, the (very low end) MikroTik was powered via USB from the laptop
Customer also wanted the router to log any dropped/leaked traffic (which we did on the mikrotik to it’s internal memory, or a usb stick with a txt file log)
Raspberry pi with a second network interface… Running FreeBSD.
As to your other point… If you remove the Sim card from your telephone and then connect to a second router device that you carry with you… But we’re getting a little weird here…
Oh, I am/was there. I have two to three phones anytime on me, so I can route one through the hotspot of the other. Still the question if the second phone route everything through the VPN.
Edit: and GP asked specifically about Mikrotik, I think. They have L7 cap, but it's literally raw.
The Problem with Android in regards to DNS: you just can't set your own IPv6 DNS Server on that platform, it gets changed anytime anything happens to your wifi.
There is no app, even for rooted android, which can disable the operating system from changing it.
When you are stuck with a router that always hands out IPv6 Adresses and doesn't let you turn that off you are just screwed.
I don't even know if you could install a firewall appliance behind that router and strip out the IPv6 DNS Servers it advertises.
What if you use the system-level support for DNS-over-TLS instead of setting the DNS server IP addresses? That's a global setting so it should apply regardless of which network you're on, or what happens on it. If you care about DNS requests leaking you should be using DoT or DoH anyway.
even bigger nightmare on iOS where 'always-on VPN' can only be configured on devices 'supervised' by an Apple-approved (documented application and telephone call with current employee required) organization's MDM solution—or you otherwise need a Mac to use the Apple Configurator app to even create a Configuration Profile containing the 'always-on VPN' key.
I've done this before for months at a time (the GL.inet E750 with an iPhone with no SIM) but oftentimes US GSM providers throttle the hell out of UDP traffic on weird ports (like to 64-128kbps, a tenth of a megabit), and also notifications are frequently delayed.
Yeah it's the best solution if you use any public wifi or even mobile telephony. Somebody can just run their own base station and then your phone would connect to that. If it's not your network don't directly connect without a mobile router.
Edit: Other commenters report that Android will silently re-enable cell data under various conditions, so this isn't a surefire solution, either.
The Grugq created a tool for this a decade ago (sadly unmaintained): https://github.com/grugq/portal as part of a presentation about operational security for hackers. It's a great watch if you're interested in how various (in)famous hackers thought they were secure and got busted anyway. https://www.youtube.com/watch?v=9XaYdCdwiWU
It's expected. The people who own the phones aren't in control of the OS and the wireless chipsets are closed/proprietary. Cellphones really shouldn't be trusted by anyone.
Correct, the baseband usually has binary blobs. Although I am curious why Google/Apple decided not to make their own baseband, given their new silicon manufacturing expertise.
IIRC Apple has tried/is trying, but it is ridiculously complex to the point that they had to go back to Qualcomm as there really is no other option. Read: The biggest tech co on the planet stumbles with this, it should be considered a magic box as this point.
Google is sort of trying by using a Samsung modem (instead of Qualcomm) with an IOMMU in between, so at least the modem doesn't have access to the whole address space like on other phones. But they get a lot of flack for it.
Right now we have no alternatives, but it's not technologically impossible to create mobile devices that give us root access to a mobile OS, or to create open wireless chipsets with open firmware.
Both Android and iOS will do that when you receive a MMS.
Even if the MMS is supposedly on an intranet, it wouldn't surprise be that a poor implementation might expose the rest of the system to internet for a brief moment.
i'm almost certain i've had it happen on iOS, too. only reason i can't definitively say—is because i can't rule myself out always having to manually toggle cell data on/off, both radio-level and per-app, when i'm coming/going from my own networks to my mobile VPN.
In the sentence "See, I can do silly categorical statements too," the adjectives "silly" and "categorical" both modify the noun "statements" and are not themselves related to one another. That's why OP used both of them. If the two words were synonymous, only one would be required.
It'd be hilarious if phones hadn't largely replaced desktops/laptops for most people. I feel bad for all the kids who grew up/will grow up with nothing but a device primarily designed for media consumption and the collection of their private data for a computer.
ISA doesn't determine speed (and not every workload is CPU-bound). In fact ARM, being RISC, would probably outperform x86 if you looked at a hardware+software stack that wasn't tuned for battery life above all else like Android is. For example, Apple Silicon Macs and Microsoft's upcoming Snapdragon laptops.
Making userdebug builds with ro.adb.secure=1 to have root access via ADB with the rest of the security model intact is officially supported by GrapheneOS. Using Magisk massively rolls back the OS security model and is strongly discouraged. Using ADB on a production device isn't recommended with or without root, but it's officially supported if you want to do it. If you only grant ADB access to the computer you use for building and signing the OS, it's not a big deal. You need to be aware that you need to heavily secure that computer and shouldn't use it for anything else though.
Not OP, but I think that their concerns are legitimate for the most part. One example they've brought up is that, with root, a single bug in the display server could lead to complete and immediate compromise of the entire device (assuming root access is gated by UI prompts as is common on most rooted ROMs). Additionally, with verified boot, persistent changes to the OS made via root would cause the phone to be unable to reboot, which limits what you can do with root (assuming you still want verified boot). GrapheneOS standards are much higher than on desktop Linux, where root can be acquired as easily as injecting a fake `sudo` into ~/.bashrc.
Basically the idea is that there should be no need for root if everything is nicely gated by permission controls and high-level APIs. If every component of Android were actually well-designed, this idea would have more merit, but unfortunately there are still a few big gaps in what you can do with a rooted versus non-rooted device, e.g. custom firewall rules (which could provide a hotfix for the issue at hand here). When asked to expose more fine-grained firewall control to the end user, the Graphene devs basically responded that it's extremely difficult to set up firewall rules properly such that leaks are impossible [1], which may be true, but I'd like to think it's better than nothing.
Also, because root access would break Android's protection against end user application tampering, that would likely rule out the possibility of GrapheneOS receiving special support from banking apps, which is something they hope to see in the future [2].
It's app accessible root with a massive portion of the OS trusted with giving out access to it that's a huge problem and massively rolls back OS security against compromise. It also means an accessibility service can trivially escalate to root with no way to revoke it beyond reinstalling the OS or doing a wipe from recovery. You also lose the main security properties of verified boot, which is based around avoiding trust in persistent state. Raising the bar for physical attacks is a secondary purpose of verified boot, not the main one.
GrapheneOS already has fine-grained firewall support exposed to the user via the standard VPN service feature which despite misconceptions can be used while also using an actual VPN and there are multiple apps supporting this. It's not simply difficult to set up firewall rules where leaks aren't possible but rather it doesn't really work because not everything is done via direct socket access from the apps. This is why we have our Network toggle in the first place, which does a lot more than blocking direct socket access both to block indirect access and preserve compatibility by pretending the network is down for the most important APIs.
These DNS leak issues which were reported to us earlier may be an app bug which can be worked around by the app. The OS could be changed to prevent this happening but that doesn't imply that it's an OS bug. More investigation is required to determine the cause and solution. We're also aware of a local network multicast leak that's not covered in Mullvad's post, which is very likely to be an Android OS bug but we aren't certain about that yet either. It's worth noting that neither the DNS leak issues or local network multicast leak issue impact the built-in VPN support. They're only happening with VPN apps. It's likely that some of this is caused by bugs in the Android VPN service app support (particularly the multicast packet leaks) but the DNS leaks are quite possibly an app flaw. Mullvad's post acknowledges they found a way to address one of the forms of leaks with changes to their app, which may be possible for the rest since there aren't leaks when the VPN is down but rather when it's in the process of reconnecting. It looks a lot like a race condition where the VPN is being activated before everything is in place, which could be a bug in the OS but could also be a bug in the app where it's doing something in a different order than what's intended.
> GrapheneOS already has fine-grained firewall support exposed to the user via the standard VPN service feature which despite misconceptions can be used while also using an actual VPN and there are multiple apps supporting this.
Interesting, didn't know that. Maybe I should file an issue with the official WireGuard app asking them to support this. It would be nice if "multiple VPNs" was provided as an OS feature.
> It's not simply difficult to set up firewall rules where leaks aren't possible but rather it doesn't really work because not everything is done via direct socket access from the apps.
This only applies to rules intended for specific apps and not system-wide rules, no? I'd hope so, since as you said people are already applying system-wide (or at least user-wide) rules using the VPN interface.
> Interesting, didn't know that. Maybe I should file an issue with the official WireGuard app asking them to support this. It would be nice if "multiple VPNs" was provided as an OS feature.
Apps have to implement it unless you mean supporting multi-hop WireGuard VPNs within the OS. Apps can support multi-hop and apps can also support doing filtering, etc. in addition to supporting an actual VPN. It's not exclusive unless the apps make it exclusive. Apps can also decide they want to support forwarding traffic through another app but they should really do that in a way that's secure instead of how some apps are currently offering this...
> This only applies to rules intended for specific apps and not system-wide rules, no? I'd hope so, since as you said people are already applying system-wide (or at least user-wide) rules using the VPN interface.
Sure, but output filtering doesn't really work well in general. For example, if you allow resolving any DNS names then you allow 2 way communication with anyone through your DNS resolver. The requests only go to your DNS resolver, but they can be for <data>.<random>.example.com where the name servers for example.com are set up to receive that data and the random value avoids it being served from the resolver's cache. The value of the DNS result can return data in the other direction. It's easier with a TXT record but can simply be an A/AAAA record too. DNS is commonly used to mask traffic by malware. It's not an obscure approach but rather very normal. Similarly, many services can be used as some form of proxy at least to communicate with arbitrary people.
The main purpose of a firewall is when you're actually hosting services and need to filter inbound connections for DDoS mitigation, etc. by limiting the number of connections per IP or IP block, rate limiting, etc. It also acts as a way to prevent listening on ports you didn't intend to be listening on due to default-enabled services or services which listen on all interfaces by default, etc. On platforms where loopback is commonly used for communication, it's also a way to do access control based on uid, gid, SELinux context, etc. None of those 3 things applies much to Android. It's very rare for apps to use loopback for communication, although some do it. Hopefully they already do their own authentication... GrapheneOS does plan to use network namespaces to provide the option of per-profile or per-app loopback interfaces, although we could also just start with a toggle for access to it.
Worth noting Android uses eBPF for controlling per-app access to the network for our Network toggle, not netfilter (iptables/nftables). They've gradually moved more and more to eBPF and away from netfilter since they have the resources to develop things that way.
This doesn't work with GrapheneOS but rather you can create a derivative of GrapheneOS without the core security model intact. Instead of a tiny core portion of the OS being trusted with root access, a massive portion of the OS is trusted with that. It's much easier for an application to compromise the OS. An attacker doesn't need exploits for privileged persistent compromise anymore but rather that's a given since the verified boot security model is no longer intact. The purpose of locking the bootloader is enabling verified boot, which is no longer intact with this approach. CalyxOS doesn't have a complete verified boot implementation for the OS like GrapheneOS and rolls back the standard security model a fair bit, but doing this rolls it back far more. You cannot have your cake and eat it too in this case. If you want modifications to the OS, you should use the official build instructions and avoid replacing the core of the OS with a rootkit trusting a massive portion of the OS to give out root access and trusting persistent state with root access.
avbroot is not officially supported by CalyxOS or GrapheneOS, but it does work with both OSes. The point of avbroot is to make root access available to trusted Android apps while leaving commands such as "fastboot flash" and "fastboot erase" disabled.
There will always be a subset of users who prioritize functionality over security. This includes anyone who would root an Android device (and anyone who would use a desktop computer running most distributions of Linux, macOS, or Windows).
I'll be glad to reconsider using root on Android if all of the functions of App Manager's "block trackers" feature[1] and Basic Call Recorder[2] were available on Android without root.
No, it's not compatible with receiving official over-the-air updates. Similarly to if you build and signed the OS properly, you'll need to make each of the updates yourself. Unlike building and signing the OS properly, you will not have the basic security model intact but rather will be massively rolling back security and trusting a huge portion of the OS with root access. Giving root to a massive portion of the OS destroys the fine grained access control and isolation model used throughout the OS. It makes exploitation much easier to do and much easier to hide. It also makes persistence a given since persistent root access can be given out which means an attacker doesn't need any verified boot bypass anymore. It's odd to go through all this effort to continue signing the OS for verified boot while losing the main verified boot security model which makes it useful.
If you want root access, build and sign userdebug builds with ro.adb.secure=1, which is officially supported by GrapheneOS and only exposes root access via ADB which you should only use from the computer where you're building the OS.
It would be possible to add some kind of key combination at boot to disable loading user installed applications, etc. and instead making a terminal with root access available. Not clear how that's really useful though. Instead, what these projects are doing is giving out root access to a massive portion of the OS in order to be able to give out full root access to apps. This is used as a shortcut to implement features in a way that massively reduces security even if you never use it. Implementing those features properly integrated into the OS following the principle of least privilege is the proper approach. Most of the features people believe they need this hack to achieve are doable without it, such as filtering traffic with your own firewall rules while also using a VPN which is a standard Android feature available to apps.
a point as salient as it is germane. this is exactly why open-source software and hardware mobile device projects[0] will only continue to proliferate.
As much as I want to support those kinds of devices they're all insanely priced and have earned a reputation for failing at the most basic tasks. Maybe after it's been more than 3-5 years since the last forum post titled "can make/receive calls" I'll give pine phones another look.
Then tons of my most important systems are "insecure" by your definition. I'll give you $100k cash no questions asked if you can provide me with copies of my SSH private keys held on such devices.
Your definition is meaningless and not useful for reasoning or communication.
Root is complicated, I would refactor that to "Any system where you don't have access to the bootloader signing keys is insecure". If you can't run your own code on the device, you can't really trust it.
I remember being chastised in some Android subreddits years ago for going against the (probably astroturf) opinion that having root access was "insecure". Sigh...
Most are happy to outsource root to the OS manufacturer. And while I demand having root on Desktop, I don't see it happening on mobile for the majority.
Most phone users are oblivious to what root even is and yet still hate it when changes are pushed to their devices without notice, with no ability to revert to how things were or prevent unwanted changes in the future. This isn't acceptance but rather learned helplessness.
Most users click on every single download link and install shit they shouldn't touch.
The simple problem has always been that when you're selling someone a $1000 piece of hardware that's supposed to "just work" how much do you let their ignorance fuck it all up.
Now granted that's not an argument for locking away access from those who choose to accept the responsibility, as has always been the case, but the idea that there was any other outcome was absurd.
Yes it'd be nice if everyone had some tech savvy common sense, but even now when we have generations growing up with it, actual understanding is far and few between when looking at the general population. People don't care, and don't want to, and it can make things risky.
Well people are technological illiterates for the most part, but the mobile platforms are dumbed down to such a degree that it would be impossible for people to learn even if they grew up with it. It's a vicious cycle, you have to design these mobile platforms for infants because that's the only way you can keep them safe, but they will never learn anything about computer or network technology using something designed to infantilize them.
The thing is, it's not that I particularly care about people, but it's made Android/iOS incredibly irritating to use, I avoid it as much as I can. It's not just that it wants to protect me from myself, as much as it doesn't let me do what I want to do, it feels like computing with a straightjacket on. Build a fort knox of sandboxes and SELinux, that's fantastic, as long as you give me the keys and blueprints, and for christ sake, stop pretending that my phone isn't a computer.
Block connections without VPN is turning out to be as reliable as my self-control at an all-you-can-eat buffet…if I'm not mistaken, these DNS leaks can very much expose where you browse and even your location, which kinda defeats the whole purpose of a VPN (and yes, even with VPNs, Android might still leak your DNS info. If you're really privacy-conscious, you might need to look beyond just using Android or keep your sensitive stuff off your phone)
Sometimes you wonder if those "bugs" are intentionally well placed or not. Especially since big tech has been known that they work together with a kinds of intelligence agencies. I just can't believe that so many bugs like this in Android are there "not intentionally" at this point since this is not the first time I have heard about these kinds of bugs in Android.
I've sort of suspected this the case for a while. On VPN, MMS and Visual Voicemail still work on Android. Both of these require direct mobile access or they will get rejected (sometimes they are only on the mobile network, or else they requests get rejected if they don't come from within the mobile network). I suspect the same is true of VoLTE. If there is a VPN, that would mess things up.
I found this out since on Mobile Linux, if you enable VPN, the VPN breaks all of those.
I don't think there is a clear way to fix this on Android without breaking a lot of expected functionalty.
ironically SMS/MMS and VVS are two of maybe a few other operations/functions (system updates maybe? maybe?) that are justifiably 'hard-coded' to the carrier connection.
i've done the dance re: VVS with advanced AT&T support on VPN'ed iOS—so can confirm your point is not limited to Android.
No VoLTE uses a dedicated bearer (network interface) in the LTE stack. Not the one used for data. Different bearers can have different priorities/QCI (like QoS). In a congested LTE network VoLTE should provide a better experience than VOIP on a lower priority bearer.
Luckily WireGuard doesn't have this issue on desktop peers. Although I did run into DNS leaking due to my peer config having an exception for my local network address range. The way I resolved that is to setup dnsmasq on the server and set that as my primary DNS.
I will say that I wish there was a DisallowedIPs directive. It's fun having to subtract a /24 from 0.0.0.0/0, although there are calculators you can use.
It's worth noting that the built-in VPN support doesn't have these leaks. We don't agree with how Mullvad is presenting this because it is not yet clear if the leaks with their app and other apps are because of bugs in these apps or the OS. Their own post says they've resolved part of these DNS leaks through changing their app to avoid not having a DNS configuration. Android supports many use cases of the VPN service API including not handling DNS and this may be a side effect of that flexibility. It's not necessarily a bug. If it's possible to set up the apps in a way that they don't leak without OS changes, then it was probably an app issue all along.
We're aware of a separate issue unrelated to DNS leaks where multicast packets can leak to the local network with VPN apps. This appears to be an OS bug, but that's not confirmed yet. It will likely only be determined if it's a bug when we find a fix for it. This multicast leak doesn't happen with the built-in VPN support either.
There have been plenty of VPN leaks on other platforms including issues that are still not really fixed without setting up custom netfilter or eBPF rules similar to what Android is trying to do on platforms where that's not done for you by the OS.
On Android, the responsibility for preventing leaks is partially taken on by the OS which promotes a standard leak blocking feature which has gotten much better in the past few years. Each app trying to do this themselves is not a recipe for success. It's not as if Mullvad was aware of these issues for a long time and asking Android to fix it without action.
I gave on trusting phones to secure data a long time ago. But my approach is, at least when on wifi, to allow access to the internet only if the device connects to a local vpn gateway. 100% leak proof and prevents almost all wifi/lan/mitm attacks.
what if a system-level (read: root) process doesn't respect your user-configured routing table? that's the real issue here. only mitigation would be to physically remove the undesirable NIC/s from the system, which is obviously impossible on SoC hardware.
It won't make a difference, the other end (gateway) will only accept vpn connections, nothing more or less. Devices that can't establish a connection with your wg/openvpn won't be able to communicate with any other device anywhere in any way period.
we're talking here about the ability to control what NIC localhost traffic egresses a device with multiple NICs—even when some of said NICs may be be virtualized, like a TUN interface for example. anything and everything else is upstream.
by "localhost traffic" i've meant literally any traffic generated by a given device, its operating system, and any applications running on it, no matter the destination.
I have also noticed that when using the FoxyProxy addon under Firefox, even with a SOCKS5 proxy in use, it will leak DNS requests through the direct connection unless you also set a manual proxy in the regular Firefox settings as well.
> Depending on your threat model this might mean that you should avoid using Android altogether for anything sensitive
I once worked with someone who worked with someone that had previously been a major Android fanboy, but after doing some work that required a security clearance, they became an iPhone user and insisted their family get iPhones too.
Apple is no less culpable of the same, they just put it behind the garden walls (which, in fairness, would appear to be just barely more trustworthy than Alphabet).
That's unfortunate, they only recently rolled out prompts to push Android users away from their in-app always-on functionality to the built in version.
So, a closed source operating system can do things the user can't control? I don't know what's more impressive, the fact people don't apprehend this reality, or the fact people still rely on VPNs (especially a third party) for privacy or whatever.
nope. no DNS service, not even a self-hosted one, can mitigate what's happening here.
the matter at-hand considers Android (and iOS both) operating system- and kernel-level insecurities by-design. the operating system (together with all root-level or otherwise authorized system activity), under certain conditions—e.g. connectivity change, hard-coded system function, apps with permission to hardcode their own network functions, etc.—will refuse to use any NIC, whether physical or virtualized, except the one containing the cellular carrier's connection/routes. that traffic might then necessarily include DNS queries and any/all other private but now-leaked data.
1.) the system strictly respects user-configured DNS; and
2.) that the leak of some private data is acceptable. leaked traffic is still leaked even if otherwise encapsulated by some other encryption mechanism outside of an otherwise properly-configured VPN tunnel.
#1 is of course a much larger risk assumption to swallow.
If google wasn't evil: then the default for all permissions would be to mock fake data that the app could never recognize as fake. Then you pick and choose which apps get REAL data.
Linux has network namespaces, which can be used to isolate programs so they don't see any external networking when no VPN is available. Does android not use this for its VPN feature?
Lol. On the other hand, I use Linux network namespaces to make programs run outside the VPN on a specific machine that has the whole system configured to go through the VPN. So yeah if you get namespaces you can use them to both isolate programs and also bypass the VPN.
Mullvad's security team should have found this problem on their own, and as soon as it appeared:
Inspect security empirically - you might think that your security must work, but that means nothing; you must investigate empirically: All data going to the Internet must pass through the gateway. Collect the packets on the gateway, not on the device, and inspect them for leaks. Finding leaks should be trivial at that point.
The only trick might be cellular connections: We don't know that leaks aren't unique to cellular connections. I know cellular gateways can be setup, but are the packets inspectable at a level that will reveal leaks?
NetGuard doesn't support the standard OS leak blocking like Mullvad and doesn't try to filter DNS so it inherently has leaks. There are no known remote leaks on Android 14 when a VPN app supporting is already active or when it's down. The DNS leaks in this post were partially caused by an app bug that's not fixed and also happen when the VPN is in the process of connecting. The issue with leaks when the VPN is in the process of connecting may be an app bug or an OS bug. It's not clear that it's an OS bug at this point. It was reported to us for GrapheneOS earlier and we've been looking into it.
There's also leak issue which was reported where multicast packets leak outside of the VPN tunnel to the local network. This is highly likely to be an OS bug, unlike the DNS leak issue where it's not yet clear if the OS or the app is the problem. The OS can likely prevent those DNS leaks even if apps don't get fixed but it wasn't necessarily supposed to be responsible for it. From the OS perspective, a VPN app is supposed to set a DNS configuration and not setting that configuration results in partially using the OS DNS.
If you don't mind clarifying, currently GOS uses ASYMMETRIC MTE for the low overhead and to close the soft time constraint in ASYNC MODE. I was having a read though https://googleprojectzero.blogspot.com/2023/08/mte-as-implem...
Where I had come accross possible MTE bypasses in ASYNC mode and I quote:
'Since SIGSEGV is a catchable signal, any signal handlers that can handle SIGSEGV become a critical attack surface for async MTE bypasses'. Moreover, "The concept is simple - if we can corrupt any state that would result in the signal handler concluding that a SIGSEGV coming from a tag-check failure is handled/safe, then we can effectively disable MTE for the process", hence having MTE as ineffective.
Paradoxically, I don't believe this issue is faced regarding SYNC MODE. As you obviously know, 'in asymmetric mode, read memory accesses are processed as SYNC, while write memory accesses are processed as ASYNC'.
does this mean that the signal handlers in write memory are exploitable?
If this be true, does GOS offer a mitigation for this, or can it be possible to simply allow all users to have the option to pick SYNC MTE to bypass this attack surface?
Furthermore, MTE is not enabled for the kernel, would it be possible to have it enabled by choice as well?
Finally, regarding the OS processes to which GOS recently enabled MTE for as an option for its users, does it also include the cellular firmware, IOMMU/SMMU and the software stack that communicates between the isolated chip and the OS? I address this point because, GAL Beniamini stated that:
" That said, up until now we’ve only considered the high-level attack surface exposed to the firmware. In effect, we were thinking of the Wi-Fi SoC and the application processor as two distinct entities which are completely isolated from one another. In reality, we know that nothing can be further from the truth. Not only are the Wi-Fi SoC and the host physically proximate to one another, they also share a physical communication interface". Nonetheless he further states:
"For example, by going over the IOMMU bindings in the Linux Kernel, we can see that apparently both Qualcomm and Samsung have their own proprietary implementations of an SMMU (!), with it’s own unique device-tree bindings. However, suspiciously, it seems that the device tree entries for the Broadcom Wi-Fi chip are missing these IOMMU bindings". Despite that the research is from a couple years, it remains viable evidence that IOMMU although provides adequate protection, it remains an insufficient mechanism on its own and requires further hardening on the software stack. Does GOS address this profound attack vector?
Android is open source, but the codebase is massive and unapproachable. I managed to make some tweaks to Android, and compiled my own custom version (for one, I removed the stupid blur from lock screen album art), but I'm fairly confident I wouldn't be able to even find all the relevant code for DNS and VPN interactions in any reasonable amount of time.
Do you really think they would allow terrorists like Hamas use Mullvad to coordinate attacks? Coincidentally, Hamas does not trust any sort of VPN, opting for underground land lines.
This is a good point. It doesn't have to be Mullvad but it's almost guaranteed based on what we've seen in the history (see CIA + swiss crypto company) that some of the major VPN providers are managed by intelligence agencies. Either VPN companies were bought via shell companies after reaching certain market share or they were even developed
from the scratch.
> Hamas does not trust any sort of VPN, opting for underground land lines.
I mean, duh. Like everyone always says around here, all bets are off when your threat model includes nation states.
Timing attacks, meta data, and total access to the internet backbones means it’s a reasonable bet that the Big Boys can track anything on the public internet, regardless of encryption or redirection. And if you’re Hamas, you’re probably on their radar.
There's only two realistic possibilities with Mullvad:
If they are a state actor, then the goal would be to use the intelligence only for parallel construction in the most severe cases like terrorism.
If they are not a state actor, then the goal would be to be so private that if terrorists use it, nobody would ever know including themselves.
In both cases, we see the same result as the public until somebody leaks.
This means that you would be very unlikely to get busted using a state compromised VPN for torrenting movies, as that's typically a civil matter and would require additional data points for parallel construction to not reveal the compromised VPN.
But if you are involved in terrorism, then you should assume the VPN is compromised in a way that will make digging up additional secrets about your activities trivial and attributable to something besides the VPN that everyone is fine with (like dragnet service provider data).
> but choose not to act on anything they find on VPNs and other "privacy focused" tech?
Oh, they probably do act on it. For most things, I assume they use the intelligence they gather for parallel construction - if you know a fact about an adversary, it can make it easier to find other, more obvious (to that adversary) ways to "find" that information.
I'd imagine taking direct, obvious action on information gleaned from front and honeypot VPN services is probably only done for extreme cases i.e. an active threat to the country/administration/agency/allies.
I like Mullvad. Just wish they used less shitty providers - all of them are super dodgy from xtom (super unhinged owner) to m247. Mullvad presents a great image but their providers would probably sell netflow traffic for $7 a month to any interested party. They really do use the scum of the earth providers instead of investing in their own infra
I never understand this argument. If feels like saying there is no reason to wear just a helmet in outer space because you'll die without a space suit anyway. Yes, there are other methods of fingerprinting that can track your with varying degrees of accuracy that you should be aware of. But IP still remains a highly effective one. And just like the space helmet, it isn't an either or. You'll have to wear both the suit and the helmet.
That depends a lot on your threat model. In many instances it will be better to share an IP with all the other VPN customers.
EDIT: Also, without this leak, Android API "VPNs" can actually distinguish traffic of individual apps, acting as a firewall that blocks untrusted apps from sending your data somewhere else. With a DNS leak, they can exfiltrate data through it.
Just changing your IP address is far from the only reason to use a VPN. Personally, I'd consider it more of a secondary effect. If you're on an untrusted network, it lets you pipe your data out to another location. I'm not sure what the point of your comment is, since it doesn't apply to the information in the shared post.
Maybe they could be more forceful about it, but I feel like Mullvad is reasonably responsible about this (certainly more so than most VPN vendors), with their front page describing a VPN as "step 1" and directly saying that "a VPN is not enough for privacy".
I agree, but IP addresses haven't been used as the main source of tracking for some time.
Advertisers learned how to use much better data points a long time ago due to AOL proxies much like the Mobile proxies a significant amount of mobile providers use today.
> Depending on your threat model this might mean that you should avoid using Android altogether for anything sensitive, or employ other mitigations to prevent the leaks. We aim to partially mitigate these problems in our app, so make sure to keep the app up-to-date.
I don't think companies should give false hopes to people, and that is what is exactly happening here (e.g., "fixing a DNS leak will make you private and that's the only reason you're not!").
I agree with what you're saying, but I don't believe Mullvad push that narrative.
In the article, they warn that "DNS leaks may have serious privacy implications for users".
Looking at their marketing homepage, they say "Using a VPN alone is not enough to achieve perfect privacy. There’s simply too much data being extracted through most browsers."
It also seems like there's some misunderstanding about what the internet is in general here or a really bad misrepresentation ("you're not on the internet because your packet traveled over wavelength" wtf):
> Depending on your threat model this might mean that you should avoid using Android altogether for anything sensitive, or employ other mitigations to prevent the leaks. We aim to partially mitigate these problems in our app, so make sure to keep the app up-to-date."
This statement clearly implies this is the reason that Android is currently not safe.
I think it would still be a pseudonym since you have credentials to log in to the VPN that remain stable, no?
Anonymous would be like: minute-by-minute you drip Monero into the VPN in exchange for service. It could track you by your IP, but nothing else, and you can change your IP.
Any device on the Internet is fingerprinted to such a level that it can be identified anywhere even if you upgrade or change the OS or browser. The only way to avoid this is to turn off Javascript and related technologies entirely and browse through Tor or some other like utility.
