Skip to main content

Netizens who reside in the meatspce known as the US, take note.

Https:// can help.

ONI-DoH encrypts your dns requests from a server in Amsterdam that keeps no will at the very least make mass collection of web browsing history very difficult.

2 people reshared this

Also, working on a resilient backbone Cyberian VPN service, but it was shelved due to time constraints.

Time to rethink that and get it moving again.

Cyberpunk 2020 was an accurate prediction.
Man...I was having a nice day. At least my senators voted against this idiocy. can I help? It really feels like Wireguard is the right protocol...but how do you ensure good performance and defray the egress costs for your endpoints?
yeah, working on that.
I understand.

FWIW, this blocks malicious sites and ads through pihole lists... I am trying to help as best I can.
Hey @silverwizard, what's your take on this project as my go-to paranoid person?
Exit is in a datacenter in Amsterdam. GDPR is good for what we are doing.

No logging, and as such no data retention.
Thanks for the elaboration. As a rule of thumb, I do not believe "no log" claims from third-parties because I cannot verify them and even if it was true at some point, it could change without notice.

Furthermore, this seems to be trading a centralized system for another. Trading an evil I know for a potential evil I don't. It might be well intended, but I still need more information to build trust.
Then roll your own, the instructions are out there.

I don’t bank on trust either, I get that.
Does rolling your own solve the problem? Isn't one of the major value-adds of this that many people are putting their traffic through it disguising what traffic is you?
I agree that additional entropy is a bonus, but you could roll your own and put it outside of jurisdiction.
My general rule is "DoH is dangerous by default"

It trades on the wire encryption for *a lot* of extra data sent to the provider. And if you are concerned that your ISP is evil, I have bad news about your ISP having CAs and the ability to lie to you about what IP you've connected to.

It's a problem where DoH requires a specific kind of paranoia that I can't get behind. Trying to use a less evil DoH server doesn't make me feel safer (though it definitely stops most of the say to day abuses of DoH - but my solution is to use an ISP I trust - which is a luxury, and also to block all DoH traffic proactively), in fact it just moves the trust to actors I trust least generally.

But this is very much a partisan stance on the DoH issue. If you're in a space where DoH has to exist, this is better.

It's like when people offer me workarounds to problems in systemd - sure, they make the problem better - but they still let the root problem exist, and I'd prefer to put my energy toward fighting the root problem.
The specific issue here is the FBI getting US private browsing data warrantlessly and opting out of it. But yeah, it would force me to trust a smaller provider.
Yeah - I generally recommend using DoT in places where you can - with DNSSec. But yeah - point is - I don't *trust* the providers who want to cheat with DNS to not intercept all kinds of DNS traffic - which is annoyingly possible to MitM. DoT is only trustworthy if you explicitly minimize your trusted cert, rather than just trust the pool of CAs.
Oh yeah - people don't have to use your DNS lookups to get your history.

"Did connection to DNS, then connected to a Google IP"
"Did a connection to DNS, then connected to a Amazon IP in the AWS block"

Evil logs are really easy to make evil
I thought I was clear on the DoH subject, and then this popped up in my feed, and now I'm confused again:
This is the standard thing - the people who think that encryption is security, and people who think that security is maintaining privacy.

Part of that is that what you are protecting will depend on your threat model. Now, Bert is a person with skin in this game (works with DNS basically all the time), but is also an expert. And he claims that putting your DNS on port 443 and then encrypting it, since the attacker that most people claim to worry about (your ISP) can find the data via other methods. Ptacek seems to be saying that this doesn't matter, because more data streams protected the better, and it's stupid to not encrypt DNS.

Now, what I personally feel is that we should be using DoT backed by keys distributed via DNS (I know I know, chicken and egg, but HTTPS does it too) and then use DNSSEC to back that (to confirm the keys). That way the DNS Root is what we trust, and since we're using DNS, that is already implied by the protocol anyway, so it minimises the amount of trust. Adding DoH means you need to trust the people you trust for HTTPS *whom I emphatically distrust*.

So, if you don't trust your ISP, and you trust Google, or have the tools to make your own DoH endpoints, you're probably safe. Until DPI can identify a DoH packet.
all true... which is why we spun it up in the first place... it is not a part of a siloed service, and provides proxied DoH.

With no data retention policy.
Never mind, I just realized the Vivaldi browser doesn't have DoH capabilities, but when it does I probably will use Projekt ONI.