Excellent, thanks for the quick response! Are there any plans to add support for full-cone NAT as well, in order to improve compatibility with some games?
(we are moving to a bit bigger office in the neighboring building, no nice photos on google yet)
We do not have a dedicated team page on the website, but we’re not hiding our faces, the team can be found on Github. Members of the team often visit AFDS [1] [2], you can see some faces there (including mine).
In Cyprus, companies are usually incorporated via a corporate service provider, who also provides the registered office address and PO Box services. Basically, if you need to reach out to us by mail, you should use the "legal address" from the website.
More or less, built on top of it with added udp/icmp.
When writing server and client a lot of time is consumed by additional features, not on implementing the spec itself. For instance, in order to be truly stealthy we have to make sure that it looks *exactly* like Chromium on the outside, and then maintain this similarity as Chromium changes TLS implementation from version to version. Or here’s another example: on the server-side we need to have an anti-probing protection to make it harder to detect what the server does.
We support both H2 and H3 and this is necessary. QUIC is not bad, but there are places where it either does not work at all or works too slow.
And one more thing, even though the code and spec is only published now, we’ve been using TrustTunnel for a long time, started before CONNECT_UDP became a thing.
We’re considering switching to it though (or having an option to use it) just to make the server compatible with more clients.
Ah, so you resolve domains before to apply the routes to the profile, I see. As per the spec, network extensions are not allowed to reroute traffic outside the tunnel, destinations set in the tunnel network settings must be routed inside the tunnel. This means that users have to know their domains upfront, the app cannot do this dynamically, if only to comply with apple rules.
Actually, no, we don't resolve them. We scan the incoming ClientHello before making a decision on where to route the connections. If the connection should be bypassed we make a connection by ourselves and proxy traffic. Implementing it that way requires having a TCP stack right in the client.
One interesting thing I’ve noticed is that AdGuard means different things in different parts of the world. In some places, people know us primarily as an ad blocker, in others we’re best known for our DNS service and in some regions AdGuard is associated almost exclusively with our VPN. The reality is that AdGuard makes several different products, not just one.
One clarification that may not be obvious: open-sourcing this isn’t primarily about signaling or auditability. If that were the goal, a standalone protocol spec or a minimal reference repo would have been enough.
Instead, we’re deliberately shipping full client and server implementations because the end goal is for this to become an independent, vendor-neutral project, not something tied to AdGuard.
We want it to be usable by any VPN or proxy stack and, over time, to serve as a common baseline for stealthy transports — similar to the role xray/vless play today.
Happy to answer questions or clarify design choices.
We do, and from what we know a bigger problem in China is detecting traffic patterns. SNI filtering is not that big of a deal, in order to block your domain it needs to first learn which one you’re using. What for the traffic patterns, people in China prefer to selectively route traffic to the tunnel. For instance, the client apps allow you to route *.cn domains (or any other domains) directly. It makes it harder to detect that you’re using a VPN.
This is actually supported by both the client and the server.
To use it in mobile clients you need to specify two domain names like that: fake-sni.com|domain.com where “fake-sni.com” is the domain thay will be in the SNI and “domain.com” is the domain in your TLS certificate (used to check the server’s authenticity)
I tried the method you suggested on the Android client, but it doesn't seem to work. After setting the domain name to two domains connected by `|`, the client fails to connect to the server and remains stuck in a “connecting” state.
You mean in TrustTunnel apps? You can create a routing profile there and select which domains/ips are bypassed, and then select that routing profile in the vpn connection settings.
>GFW has been able to filter SNI to block https traffic for a few years now.
SNI isn't really the threat here, because any commercial VPN is going to be blocked by IP, no need for SNI. The bigger threat is tell-tale patterns of VPN use because of TLS-in-TLS, TLS-in-SSH, or even TLS-in-any-high-entropy-stream (eg. shadowsocks).
Performance reasons aside, TrustTunnel is developed by the team whose main language is C++ (and the client library is actually written in C++) so Rust was a more natural choice for them.
Likewise interested in the authoritative answer, but: if I needed to write a decent chunk of code that had to run as close to wire/CPU limits as possible and run across popular mobile and desktop platforms I would 100% reach for Rust.
Go has a lot of strengths, but embedding performance-critical code as a shared library in a mobile app isn't among them.
I can't thank Adguard enough for providing so much to the community, they are a BIG part of my privacy-funded lifestyle.
Out of the topic — but if you by any chance work on the mobile apps.
Do you know why the iOS version is still sub-par compared to Android?
You all add more features for rooted Android but what about Jailbroken iOS devices?
I have bought 20+ Adguard licenses and have never regretted buying them. Only if the iOS version could be much better.
We are very cautious with Apple as we suffered from them before [1]. So we're trying to stick to the APIs they provide. I hope the new URL filtering API [2] will improve the situation with the system-wide filtering, but our request for API access is still being reviewed by Apple.
Regarding jailbroken iOS devices, unlike Android the numbers are really marginal so it won't be feasible to support them.
Thank you so much, I also regularly read your blogs.
I am looking forward for better iOS support. :)
Hope Apple can be much reasonable.
Also, what network trackers do you think are most harmful for privacy? — WebRTC, hardware fingerprinting, etags, cookies?
Do you think Adguard will hone themselves much more in the future from just being an ad-blocker to evolving into an all-in-one privacy protector?
Also, I apologize for asking too many questions, I just got a bit excited when I saw you comment.
Uh, I guess it's a little bit off-topic here:) It's hard to say what's more harmful, I'd say cookies still take #1, but I think we're not far from the moment when your email address or its derivative will be used as the main advertising ID. Regarding evolution, well, definitely possible, the time will show.
This is not a common issue tbh. What sometimes may happen is that after an iOS update the content blockers in Safari becomes corrupted and the only thing that fixes it is not just a reinstall, but uninstall + reboot + reinstall after that. If even this doesn’t help please contact me at “am at adguard.com”, I will try to help.
I would advise against using unbound on the client side as this way all your DNS queries will be unencrypted and visible to your ISP. Besides that, the DNS responses can be modified, this kind of censorship is very popular and used in many countries.
IMO it is safer to use a big popular DNS recursor (google, cloudflare, adguard, quad9, etc), use DoT/DoH/DoQ and maybe add some additional filtering on top of it.
I tried not to share too much details while we were still in process of figuring out the details.
The legal advice we got was basically “block asap or risk jail time”. Moreover, the risk would still be there even if the complainant is shady or hiding their identity.
So it took us some time to do the digging and make sure that illegal content was removed which was the prerequisite to unblocking.
The digging is not finished btw, we’ll later post a proper analysis of our reaction and the results of the research.
Thanks for understanding and sorry if my comment sounded too harsh. Over the past few years we went through a lot and when I hear that AdGuard is just registered I may overreact.
What for your position, I respect it and as much as I’d like to say otherwise, under certain circumstances it can be reasonable.
It's not the first time I've noticed you spreading this misinformation on HN, so let me respond.
Most of AdGuard's staff relocated in 2022, and I (CTO and co-founder of AdGuard) personally live in Limassol, Cyprus. We commented on that publicly, but it seems that random forum posts often regarded as more reliable sources of information.
I am totally fine with anyone not trusting AdGuard for any reason, but please keep your statements factually correct.
PS: Sorry for sticking a small promo in the comment, but this year we're organizing the annual summit (adfilteringdevsummit.com) for ad blockers' devs on our home turf in Limassol, a perfect opportunity to meet us, other ad blockers and even browsers' devs.
If you've still got most of your devs working in Russia, and it looks like that from your github projects, I'm not sure what part of the comment you responded to is not correct or misinformation.
Most of the employees relocated including senior staff, devs and people with access. We still have some contractors working from there, mostly in support service, content and qa. Not "most" or "a lot", but nevertheless.
We encourage people to move closer to the head office, but as long as it's not required by law, we’re not going to force people to move out, as I know very well how hard it is.
> and it looks like that from your github projects
You do realize that a russian name != working in Russia, right?
> I'm not sure what part of the comment you responded to is not correct or misinformation
The parts where:
1. It's implied that the company is just "registered".
2. It's implied that the company is not European.
3. It's said that devs reside in Russia.
All three are factually incorrect.
AdGuard has been around for 16+ years, and throughout this time I've seen similar accusations many times. I am generally fine with them — that's life — but today I just wasn't in the mood, sorry for that. Anyways, this is one more reason to have more code published to open source, a win-win for all.
reply