DNS traffic can leak outside the VPN tunnel on Android(mullvad.net)
mullvad.net
DNS traffic can leak outside the VPN tunnel on Android
https://mullvad.net/en/blog/dns-traffic-can-leak-outside-the-vpn-tunnel-on-android
391 comments
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.
Blog posts like this (instead of endless YouTube sponsorships like their competitors do) are what made me choose them as my VPN service.
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.
FYI they are transparent about buying outdoor ads: https://mullvad.net/en/help/policy-reviews-advertising-and-a...
I saw mullvad vpn ads on the L train (nyc) this week!
[deleted]
I was surprised this week to see a big yellow Mullvad ad on LA Metro bus. They must be on an advertising push.
I saw them on metro north going into nyc
[deleted]
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.
https://mastodon.online/@mullvadnet/109959480069637837
https://mastodon.online/@mullvadnet/109959480069637837
I use and recommend Mullvad.
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.
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.
Why do you think they'd accept an offer? They openly said it's not for sale: https://mullvad.net/en/blog/2021/9/16/ownership-and-future-m...
Not everyone's in it for the money. Assuming they're not operating at a loss, even less so.
Not everyone's in it for the money. Assuming they're not operating at a loss, even less so.
They are making bank. Thank you open Swedish data:
https://www.allabolag.se/5592384001/mullvad-vpn-ab
https://www.allabolag.se/5592384001/mullvad-vpn-ab
There are billboards for Mullvad all over Chicago which kind of weird me out.
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. :)
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.
> plastering privacy propaganda all over some major U.S. cities
The ads are great to see in NYC subway and giant billboard near NY Times HQ.
Is there an online page with all of the ads? Maybe a video tour of the ads "in the wild" in different cities?
The ads are great to see in NYC subway and giant billboard near NY Times HQ.
Is there an online page with all of the ads? Maybe a video tour of the ads "in the wild" in different cities?
Thanks! I don't think so unfortunately. It's a great idea though.
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.
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)
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.
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!)
transparency is absolutely a corporate virtue.
transparency is absolutely a corporate virtue.
73796204hdbueojs
NjIjdj72827823738638383873838738383+?@
Hdhshshsjnhdjzjjskshnsksjsjajsnbsnzkznnskwysnekeodiyfhdhjeoxuhdndkxixhdjndkdidihdbdjdkdudjdjskiskkdkddkjdkdighxnndnehdjisjsbzihxbduehsnsjjsjhduddxdudidndudjddbzbnzsiiek728747296482£+389293939jsjbzdhdhbdbdjdjndjdjfjfjncnfjmcjfnfnfnnf84833837939383⁸3883838387492937839288393828299299298938379393479499484⁸494484984934848393784948749482⁹33939838399444975949
1
They do traditional advertising (billboards being one example) instead of paid reviews, affiliate/influencer advertising, etc.
https://mullvad.net/en/help/policy-reviews-advertising-and-a...
https://mullvad.net/en/help/policy-reviews-advertising-and-a...
Oh wow, I wish more companies had pages like that summarizing what sort of marketing/advertising they do/don't use.
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.
I've been a happy expressvpn customer since dec 2016 but I'm sincerely considering switching to mullvad at this point
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)
(Seeing the reply down thread from a Mullvad rep, this is not unexpected)
My concern with the Mullvad ads is that some are essentially lying about what their product does. One of the ads I recall said something like:
> Imagine an ad that won’t track you after you see it
> Mullvad VPN
That’s not what a VPN does though. Tunneling my browsing does not stop sites from serving ads, setting cookies, fingerprinting browsers, etc.
> Imagine an ad that won’t track you after you see it
> Mullvad VPN
That’s not what a VPN does though. Tunneling my browsing does not stop sites from serving ads, setting cookies, fingerprinting browsers, etc.
> That’s not what a VPN does though.
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.
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.
nick238(2)
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.
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.
https://github.com/mullvad/system-transparency
https://www.system-transparency.org
https://news.ycombinator.com/item?id=29903695
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.
https://github.com/mullvad/system-transparency
https://www.system-transparency.org
https://news.ycombinator.com/item?id=29903695
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:
- https://www.sigsum.org (a transparency log with witness cosigning)
- https://tillitis.se (an open-source hardware FPGA-based security key with measured boot)
- https://www.sigsum.org (a transparency log with witness cosigning)
- https://tillitis.se (an open-source hardware FPGA-based security key with measured boot)
> a greedy biz bro simply wouldn't.
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".
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".
For sure. Them being Swedes with a long track record decreases that probability a lot.
> 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?
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! :)
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! :)
Thanks! :)
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.
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...
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!
They arent based in Switzerland but in Sweden.
They’re in it for the money.
They’ve made some claims that are downright lies, I chuckle at the idea anyone would trust them.
The NYC subway ads state that they save you from online web ad systems; blatantly false.
I’ll take a photo next time I see the ad to store away.
They’ve made some claims that are downright lies, I chuckle at the idea anyone would trust them.
The NYC subway ads state that they save you from online web ad systems; blatantly false.
I’ll take a photo next time I see the ad to store away.
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."
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."
Your knowledge might be a bit out of date, they do offer an ad-blocking DNS now.
I don't know if it's easily configurable in the app, though.
I don't know if it's easily configurable in the app, though.
> I don't know if it's easily configurable in the app, though.
I just discovered it by accident the other day.
It's super easy.
See "DNS content blockers" at https://mullvad.net/de/help/using-mullvad-vpn-on-android#vpn...
I just discovered it by accident the other day.
It's super easy.
See "DNS content blockers" at https://mullvad.net/de/help/using-mullvad-vpn-on-android#vpn...
> They’ve made some claims that are downright lies
Which claims are you referring to?
Which claims are you referring to?
NYC subway, today: https://ibb.co/v3rdHcm
From my above post:
> The NYC subway ads state that they save you from online web ad systems; blatantly false.
> The NYC subway ads state that they save you from online web ad systems; blatantly false.
What were the lies?
From my above post:
> The NYC subway ads state that they save you from online web ad systems; blatantly false.
> The NYC subway ads state that they save you from online web ad systems; blatantly false.
A very cursory search online shows that it's actually your statement which is blatantly false. They've offered ad blocking for years.
While it's true they've not always offered this, it's on you when making such claims to ensure you're still factual.
While it's true they've not always offered this, it's on you when making such claims to ensure you're still factual.
> They've offered ad blocking for years.
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.
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.
https://mullvad.net/en/blog/how-set-ad-blocking-our-app
"How to set up ad blocking in our app"
Dated May 27, 2021
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.
"How to set up ad blocking in our app"
Dated May 27, 2021
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.
> 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 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.
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.
Did the ad in fact talk about the VPN by itself, or in conjunction with the Mullvad Browser?
In any case we make the most important nuances clear on our landing page, and in other places on our website.
In any case we make the most important nuances clear on our landing page, and in other places on our website.
I believe it just said Mullvad, which I interpreted to be the VPN. It was on the NYC subway.
Sorry, not buying it. To claim that you stop online ad networks is a downright falsehood and you know it.
That copy should’ve never made it past basic checks for legitimacy.
Or alternatively: feel free to describe to HN how Mulvad protects users against ad networks.
That copy should’ve never made it past basic checks for legitimacy.
Or alternatively: feel free to describe to HN how Mulvad protects users against ad networks.
> 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.
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.
In combination?
The browser piece is doing almost all of the work against ad networks, isn’t it?
Which part of defense against ad networks does a VPN contribute to?
The browser piece is doing almost all of the work against ad networks, isn’t it?
Which part of defense against ad networks does a VPN contribute to?
To claim that you stop online ad networks is a downright falsehood and you know it.
I’m going to make sure to photograph the NYC subway ads next time I see them
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.
Follow up: I just took this photo: https://ibb.co/v3rdHcm
They do offer DNS-level ads filtering when you enable the VPN.
> Sorry, not buying it. To claim that you stop online ad networks is a downright falsehood and you know it.
Where do they claim their VPN stops online ad networks?
Where do they claim their VPN stops online ad networks?
The NYC subway ads
Can you point me at the one you're talking about, please?
I literally just took this photo right now (2024-05-08) https://ibb.co/v3rdHcm
There are settings to help with that, though.
https://mullvad.net/en/blog/aiding-to-break-habits-gambling-...
https://mullvad.net/en/blog/how-were-knocking-down-ads-and-t...
It's not going to prevent everything, but it'll definitely help.
https://mullvad.net/en/blog/aiding-to-break-habits-gambling-...
https://mullvad.net/en/blog/how-were-knocking-down-ads-and-t...
It's not going to prevent everything, but it'll definitely help.
they do advertise, but they try to keep traditional (instead of influencers) https://mullvad.net/en/help/policy-reviews-advertising-and-a...
I was an extremely happy user until they removed port-forwarding. That forced me to switch unfortunately :(
What was the reasoning for removal?
Unsurprisingly, they wrote a blog post about it.
>"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."
https://mullvad.net/en/blog/removing-the-support-for-forward...
>"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."
https://mullvad.net/en/blog/removing-the-support-for-forward...
How were you using port forwarding with an external VPN?
A lot of VPN’s allow you to forward a port from local to “listening” on one of their servers, to make it easier to use P2P filesharing and such.
Mullvad and a few others have had to disable this feature because it turns out it’s super useful for hosting malware C&C servers, phishing pages, etc
Mullvad and a few others have had to disable this feature because it turns out it’s super useful for hosting malware C&C servers, phishing pages, etc
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.
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.
[deleted]
It’s typically for BitTorrent.
They don't do YouTube sponsors but they sure plastered their ads all over Chicago. Literally everywhere.
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).
[0] https://news.ycombinator.com/item?id=40056162
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).
[0] https://news.ycombinator.com/item?id=40056162
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.
In short: they are great.
I got back a swift reply which solved the payment question, and a detailed iptables reply with pros and cons of different solutions.
In short: they are great.
What VPN do you use, if any?
Good points. By the way, how do they compare with the likes of ProtonVPN?
only bummer is that due to their strong respect of user anonymity a lot of their IPs are blocked by major platforms like Reddit
I use Mullvad and Reddit has never tried to block me, in fact I've run into no blocks at all. Then again my browsing habits are quite boring.
you are likely logged in! they only enforce the blocklist on lurkers
You're correct, and I just tested it... seems that about half of Mullvad IP's are in fact blocked if you're logged out. Good catch.
how are platforms like reddit able to get complete list of mullvad IPs and other vpns but not residential proxies?
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].
[1]: https://mullvad.net/en/servers
[1]: https://mullvad.net/en/servers
It’s an industry now e.g. https://ipinfo.io
damn this is crazy, how did they even compile all the residential proxies
im seeing it detect!!
im seeing it detect!!
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
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.
How does one even get access to that kind of information? Are ISPs just selling this stuff or what?
We have 700 servers around the world and we run measurements over all of the usable internet space, including assigned IPv6 addresses.
I highly recommend reading some of our blog posts and community posts.
You can also checkout our IP data tags page: https://ipinfo.io/tags
I highly recommend reading some of our blog posts and community posts.
You can also checkout our IP data tags page: https://ipinfo.io/tags
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.
people use mullvad IPs maliciously -> those IPs end up on blocklists
rethinkdns dev here
> 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.
> 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.
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.
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.
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).
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).
Google doesn't let you deny permissions for most of them.
As I understand it, apps that use the internet still need an entitlement, it's just that the Google Play store no longer shows that one in the list.
As I understand it, apps that use the internet still need an entitlement, it's just that the Google Play store no longer shows that one in the list.
> As I understand it, apps that use the internet still need an entitlement, it's just that the Google Play store no longer shows that one in the list.
That's what it is, I think. The Play Store doesn't show it in the list of permissions anymore.
That's what it is, I think. The Play Store doesn't show it in the list of permissions anymore.
still the same. Alphabet nor Apple have any real incentive to change this (commercial incentivization to maintain it notwithstanding).
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.
Thank you, I missed the point of GP clearly. I use GrapheneOS and forgot you can't deny network access to an application in a "regular" Android.
It's just an example of an app that doesn't need internet access, yes flashlight is so useful it is built in to basically all phones now.
GrapheneOS does if you're willing to take the plunge.
Take the plunge to not do any banking on your phone.
It's an unfortunate limitation for a device I own to be handicapped this way.
It's an unfortunate limitation for a device I own to be handicapped this way.
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.
Do Android Auto and VoLTE / VoWiFi work on Graphene these days? I also remember Google Maps and Uber being extremely problematic
Android Auto is supported on GrapheneOS:
https://grapheneos.org/usage#android-auto
VoLTE and VoWiFi are supported if your carrier supports it.
Google Maps and Uber work fine, provided you install sandboxed Google Play.
https://grapheneos.org/usage#android-auto
VoLTE and VoWiFi are supported if your carrier supports it.
Google Maps and Uber work fine, provided you install sandboxed Google Play.
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.
[0]: https://grapheneos.org/articles/attestation-compatibility-gu...
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.
[0]: https://grapheneos.org/articles/attestation-compatibility-gu...
Note that Android Auto has been supported in GrapheneOS for a while:
https://grapheneos.org/usage#android-auto
https://grapheneos.org/usage#android-auto
Ya kept wanting to try Android Auto but when they released I failed to find the toggle xD
Nowadays it's the Google's Find My Tag network which will be unsupported.
Nowadays it's the Google's Find My Tag network which will be unsupported.
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.
Google Wallet is usable on GrapheneOS, but Google artificially restricts contactless payment functionality to Google-certified OSes.
It's not a real security check that they're doing, but rather just checking for certification, which is very unfortunate.
It's not a real security check that they're doing, but rather just checking for certification, which is very unfortunate.
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.
Excluding phones, Linux desktop, and Windows which doesn’t have a better record in vulnerabilities, leaves out essentially MacOS!
Using desktop and a phone as a second factor to confirm operations is relatively safe. At least compared to using only a phone.
Actually OTP hardware devices are a proper solution to this, but banks are mostly deprecating them, unfortunately.
and why do you think that is? *ponderingfaceemoji
banks and gov sites say it's because of security, but accept SMS. so we know what it's really about
banks and gov sites say it's because of security, but accept SMS. so we know what it's really about
I don't. Deliberately exposing people to risk for fun?
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.
I still hate it, but can't do much about it.
I still hate it, but can't do much about it.
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).
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).
I've used GrapheneOS for years and I'm doing banking on my phone just fine.
My banking apps worked for me on GrapheneOS once I installed Google Play services.
The only 'banking' app I've had not work on GrapheneOS is Cash App, but then I just go to the website and use the web UI.
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.
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.
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.
i hope you switched back, lol.
i hope you switched back, lol.
Your bank doesn't have a mobile website?
It does but have to use the app to deposit checks.
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?
You can also contact your bank and tell them that you want to be able to deposit checks via the Web site.
If enough people do this, and don't use the overly-proprietary app, the bank might listen.
You can also contact your bank and tell them that you want to be able to deposit checks via the Web site.
If enough people do this, and don't use the overly-proprietary app, the bank might listen.
>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.
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.
FWIW GrapheneOS does (it asks you before installing any app)
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.
> 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.
Netguard is an open-source program that helps fix this: https://netguard.me/
Is android.permission.INTERNET not a thing anymore? Unlike iOS, Android at least used to have this one.
I sometimes wish I could just configure that per-app as a user. Frustratingly, on iOS it's possible only for mobile data, but not for Wi-Fi – why!?
I sometimes wish I could just configure that per-app as a user. Frustratingly, on iOS it's possible only for mobile data, but not for Wi-Fi – why!?
A possible answer is it’s not really a privacy setting but instead to save you from carrier data charges.
I agree that there should be an app firewall to the point I’m running an older phone w the checkm8 jailbreak to have a firewall.
I agree that there should be an app firewall to the point I’m running an older phone w the checkm8 jailbreak to have a firewall.
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!
You can run WireGuard (as a proxy not a VPN; ie, TCP/UDP only) with Rethink DNS + Firewall, an app I co-develop: https://github.com/celzero/rethink-app
On iOS it's also possible it's also possible to block Wi-fi data but only on iPhones sold in China: https://apple.stackexchange.com/a/312430
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.
I'm on OxygenOS 12 and I have the option to disable mobile data and/or Wi-Fi for each app, not sure if other versions have that though.
[deleted]
Can you link to the documentation explaining how developers disable Internet permissions on iOS.
Unfortunately a race to the bottom is a bad thing, not an excuse
My network security requirements have nothing to do with iOS. Can't we just collectively drop OS tribalism?
Or any other operating system...
For windows you go into the firewall settings and either set a deny rule for a specific executable or even set the default behavior to deny.
For linux there's a couple ways of setting up a process group that can't access your network.
I'm not very familiar with other OSes.
Why do you ask? Isolation between processes can be difficult on non-phone operating systems, but removing permissions tends to be quite easy.
For linux there's a couple ways of setting up a process group that can't access your network.
I'm not very familiar with other OSes.
Why do you ask? Isolation between processes can be difficult on non-phone operating systems, but removing permissions tends to be quite easy.
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.
They also exist for Android, for that matter.
Depending on how blur you draw the line of os:
docker run --network none
docker run --network none
That's what you get when you trust your device to commercial companies.
That's what you get when there are no practical alternatives.
Speaking of, did FairPhone get the whole "making a phone call" thing figured out yet?
That hypothetical Flashlight app, that uses location permission, would have never been approved in the first place.
https://support.google.com/googleplay/android-developer/answ...?
https://support.google.com/googleplay/android-developer/answ...?
Who said anything about location permission?
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.
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)
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)
Or... they can just use the builtin tile. This is such a bizarre offtopic theorycrafting fest based on decade old ideas.
[deleted]
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.
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.
>it'll decide to flip to cell and use those as it needs/wants
Are you sure you don't have wifi assist enabled? That's explicitly designed to switch to cellular when wifi signal is poor.
Are you sure you don't have wifi assist enabled? That's explicitly designed to switch to cellular when wifi signal is poor.
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...
Can it be reliably configured to “fail off” ?
That is, if my configuration profile Becomes invalid or is non-functional, Will it just cease to pass traffic?
That is, if my configuration profile Becomes invalid or is non-functional, Will it just cease to pass traffic?
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 hope someone who is more knowledgeable about the configuration profiles can give you a definitive answer.
This looks very sketchy. I'd recommend checking out Little Snitch instead.
That website … scares me. Why are you trusting this product? Is there source available or some audit record?
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.
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.
iOS absolutely does not use Private Relay (iCloud branded VPN) by default. Even when it is included in a subscription, you must explicitly opt in.
The Limit IP Address Tracking feature is turned on by default and Apple makes it more annoying because it is turned on or off for each WiFi network.
And a simple search shows definitely people annoyed by the exact same symptom of redirected DNS queries and inability to use internal-only DNS entries. https://www.reddit.com/r/ios/comments/uurkqr/limit_ip_addres...
And a simple search shows definitely people annoyed by the exact same symptom of redirected DNS queries and inability to use internal-only DNS entries. https://www.reddit.com/r/ios/comments/uurkqr/limit_ip_addres...
Have you tried disabling "mobile data always active" in developer options?
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.
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.
I will give up on android and move to iPhone. Google cannot build products whatsoever.
As said they have the same problems, and a lot less options to do anything about it. It is different kool-aid, but still just kool-aid.
If you really want secure and private, get a dumb phone, and just use it as a phone. Anything else, use linux that you can actually control and audit.
If you really want secure and private, get a dumb phone, and just use it as a phone. Anything else, use linux that you can actually control and audit.
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?
Is there any company that can make a competent product? Valve needs to get into the phone game.
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.
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.
This type of device is referred to as a “network slug”[1] … and it is a fantastic idea.
If we’re being formal, a true slug is one that has no IP address defined and is a transparent layer two firewall… But we don’t need to pick nits here…
[1] https://john.kozubik.com/pub/NetworkSlug/tip.html
If we’re being formal, a true slug is one that has no IP address defined and is a transparent layer two firewall… But we don’t need to pick nits here…
[1] https://john.kozubik.com/pub/NetworkSlug/tip.html
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.
Very cool, didn’t know about this!
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).
just curious, what was your "main router" in this setup? ISP-supplied?
[0] https://en.wikipedia.org/wiki/Policy-based_routing
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)
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)
As long as you're promoting them, have they got a good/cheap router with a layer 7 firewall?
If only we could insert a firewall between our apps and the modems in our phones.
If only we could insert a firewall between our apps and the modems in our phones.
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…
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.
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.
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.
doesn't matter. plenty of elaboration elsewhere in the discussion.
Doesn't rethink let you change ipv6 dns?
so that's what happens on when the phone is the main interface
does this happen with wifi tethering too? if i have a vpn set up on a laptop that i connect through the phone's wifi will that leak in the same way?
does this happen with wifi tethering too? if i have a vpn set up on a laptop that i connect through the phone's wifi will that leak in the same way?
I guess the safest setup is to have mobile data off on your phone and carry an OpenWRT hotspot to do the VPN bit upstream from the phone.
it's true.
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.
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 _think_ iMazing can do what you want: https://imazing.com/configurator
Disclaimer: I've never used this feature. I only use it for backups and copying files to my iPhone.
Disclaimer: I've never used this feature. I only use it for backups and copying files to my iPhone.
never even thought to check if iMazing had any of this functionality. disclaimer noted, great tip regardless. thank you.
Making a simple OSS tool to generate valid configuration profile files seems like a potentially useful way to spend a weekend sometime.
The format cannot be that complex, right?
The format cannot be that complex, right?
Looks like it’s just XML .plist format, and (at least partially) publicly documented:
https://developer.apple.com/business/documentation/Configura...
https://developer.apple.com/business/documentation/Configura...
Web page for offline generation of iOS VPN configuration profile: https://mobileconfig.app
Until you get to the bit where I'm guessing you need Apples private keys to sign it or whatever
lol, hit me up with your rate. my only term is that i get to be watching over your shoulder the whole time.
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
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
> Other commenters report that Android will silently re-enable cell data under various conditions
This is terrifying.
This is terrifying.
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.
Armchair speculation: Patents?
so then whats the other alternative?
solder on some ESPs on an old playstation portable device and connect from starbucks?
solder on some ESPs on an old playstation portable device and connect from starbucks?
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.
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.
even in roaming?
Just be cautious...
Any system where you don't have root access in insecure by it's very definition. Android and ios are hilarious.
Any system that has a concept of root access is insecure by definition. See, I can do silly categorical statements too.
Honestly I think yours makes more sense than his..
categorical ≠ silly
...unless you care to elaborate on why you disagree with this statement in substance and/or on point?
...unless you care to elaborate on why you disagree with this statement in substance and/or on point?
> categorical ≠ silly
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's fun nitpicking nitpicks.
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's fun nitpicking nitpicks.
i see your careful edit. (i ran out of time myself.) they're called parts of speech. your comment makes much more sense now. welcome.
adjectives modify nouns.
sure is.
sure is.
Now you can try making true ones.
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.
they will never know the raw power of x86/x64 architecture and are limited to the mere throughput of an arm processor.
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.
I never said speed. I said power, as in voltage
The grapheneos devs are really, really against root. What are your thoughts on that?
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.
Always appreciate your detailed replies here. Thanks!
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].
Anyway, this particular issue is definitely a bug in AOSP, and will hopefully be resolved promptly. It's being tracked here: https://issuetracker.google.com/issues/337961996
[1] https://discuss.grapheneos.org/d/4113/6
[2] https://grapheneos.org/articles/attestation-compatibility-gu...
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].
Anyway, this particular issue is definitely a bug in AOSP, and will hopefully be resolved promptly. It's being tracked here: https://issuetracker.google.com/issues/337961996
[1] https://discuss.grapheneos.org/d/4113/6
[2] https://grapheneos.org/articles/attestation-compatibility-gu...
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. 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.
> 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.
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.
Anyone who prefers root access on Android with a locked bootloader (on the OSes that support it) can use avbroot:
https://github.com/chenxiaolong/avbroot
Works great with CalyxOS and GrapheneOS.
https://github.com/chenxiaolong/avbroot
Works great with CalyxOS and GrapheneOS.
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.
[1] App Manager: https://github.com/MuntashirAkon/AppManager
[2] BCR (Basic Call Recorder): https://github.com/chenxiaolong/BCR
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.
[1] App Manager: https://github.com/MuntashirAkon/AppManager
[2] BCR (Basic Call Recorder): https://github.com/chenxiaolong/BCR
[deleted]
What about OTA updates? Do they preserve it?
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.
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.
No, over-the-air updates are not supported. The instructions for flashing updates patched with avbroot are here:
https://github.com/chenxiaolong/avbroot?tab=readme-ov-file#u...
https://github.com/chenxiaolong/avbroot?tab=readme-ov-file#u...
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.
[0] https://en.wikipedia.org/wiki/PinePhone_Pro
[0] https://en.wikipedia.org/wiki/PinePhone_Pro
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.
i agree the whole concept is not too far past proof at present.
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.
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.
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.
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.
Any system exposed to the public internet is insecure by its very definition.
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.
"Once is happenstance. Twice is coincidence. Three times is enemy action." —Ian Fleming, Goldfinger
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.
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.
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.
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.
I think this finding originates with the GrapheneOS community [0]. Edit: I guess that may be the same user reporting both.
0: https://twitter.com/GrapheneOS/status/1782477984156311814
0: https://twitter.com/GrapheneOS/status/1782477984156311814
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.
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.
Why would localhost traffic be routed via non-loopback nic's. I think you are talking about something else and I am not following. Sorry.
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.
I don't suppose you can set a nonexistent manual proxy and then use the addon for everything?
> 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.
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).
Apple does the exact same shit. I discovered it when I first set up a home DNS server.
They switched to iPhone not for DNS reasons, but overall security.
I noticed this with my Android TV. Sometimes my location would leak and certain streaming sites stopped working (I'm outside the US).
Got an AppleTV and this issue stopped.
Got an AppleTV and this issue stopped.
No one is going to say Apple has acceptable levels of Security.
I am a bit shocked when I see politicians with iPhones, most are unaware that Pegasus can take over at any point.
I am a bit shocked when I see politicians with iPhones, most are unaware that Pegasus can take over at any point.
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.
Apologies if this is a dumb question—could a service like NextDNS help prevent this?
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.
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.
NextDNS _does help_ though by way of being DoH, so while your packets might be traversing a less desirable path they’re not readable.
fair point. but that assumes:
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.
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.
Interesting. Thank you for this.
APNS traffic leaks outside of the VPN on iOS as well (except possibly OS-supported VPNs installed with a provisioning profile).
Apple doesn’t seem to care, as they don’t care about preserving your privacy wrt themselves.
Apple doesn’t seem to care, as they don’t care about preserving your privacy wrt themselves.
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?
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?
This can also be detected by using the NetGuard firewall which acts as a vpn. Even in full lockdown mode, some kinds of newwork traffic gets through.
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.
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?
I hope to get your perspective on the matter.
Thank you in advance.
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?
I hope to get your perspective on the matter.
Thank you in advance.
We have reported the issues and suggested improvements to Google
Isn't Android open source? Can they not fix it for them and submit a PR?
Isn't Android open source? Can they not fix it for them and submit a PR?
Mullvad's not really in the business of developing for Alphabet. but any of us could though, sure.
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.
I don't VPNs, nor Mullvad, but I do appreciate the transparency here. We need to support more companies like this.
toy with me for a bit, couldn't Mullvad be another "Encrochat" in the making?
Encrochat was similarly marketed as absolutely trustable complete with experts covering "we fixed this vulnerability/exploit and you can trust us" vibes (https://www.manchestereveningnews.co.uk/news/uk-news/dads-se...)
Isn't Mullvad the same thing?
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.
Encrochat was similarly marketed as absolutely trustable complete with experts covering "we fixed this vulnerability/exploit and you can trust us" vibes (https://www.manchestereveningnews.co.uk/news/uk-news/dads-se...)
Isn't Mullvad the same thing?
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.
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.
So your narrative is that they have complete access but choose not to act on anything they find on VPNs and other "privacy focused" tech?
Makes sense as there has been no cases involving terrorist using Mullvad and such.
So Mullvad is not good enough for terrorists but good enough for the rest? This makes no sense to me.
Makes sense as there has been no cases involving terrorist using Mullvad and such.
So Mullvad is not good enough for terrorists but good enough for the rest? This makes no sense to me.
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).
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.
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.
What’s not to understand? Nation states (read: their 3 letter agencies) probably don’t care if you’re torrenting movies.
What's the point for a terrorist certified VPN?
What if I have private dns set up on my phone?
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
used an exploit to get vpn working on router...
Can't you just use a DNS provider that encrypts the traffic?
chadsix(10)