I find 'IDEs' a bit cluttered. For web development I use Sublime[0], a browser with Live Reload[1] and that's it. The browser's devtools are also handy.
I swing between my comfort zone, and growth mindset. Sometimes projects just become maintenance mode for a while, other times I expand my knowledge, try new things, learn from mistakes. You have to have a beginner's mind, and be willing to look pathetic on your first try and leave ego at the door. Become vulnerable.
Caveat: This is a Flatpak and not all Linux distros ship with Flatpak. But I'll give it a whirl in my Fedora virtual machine. I've seen many flavors of this type of tool floating about, most of them leveraging Tesseract[0], and I've tried a few of them. It fails badly on grainy / noisy images or where the text is warped or skewed in some way. It will not solve CAPTCHAs for you!
...it's a pile of Vala code. What you probably mean is that the author did not make a package for your distribution, and there is no one else who had the time and inspiration to package it. You can be the maintainer you seek.
Other metadata like DNS, device fingerprints, SNI-leakage[0], timestamps, connection history, etc
You can encrypt DNS with DoH if you want, but the DoH provider still sees its you. You can take it a step further with Oblivious DNS over HTTPS if you really want to conceal DNS activity[1]. Note: this technology is rather new and experimental.
Another option is dnscrypt-proxy[0]. It will easily let you load-balance your DNS queries against a large set of resolvers, ensuring that no resolver gets the full picture. And enforces encryption of course.
It keeps Mullvad from intercepting DNS traffic: if you send cleartext DNS requests on UDP/53 through their network, they intercept it. But DNSCrypt packets are encrypted and authenticated, so they can't.
Bonus: DNSCrypt is still packet-based like UDP, so none of the downsides of DoH: no 3-way handshake, no connection pooling, no stream correlation attacks.
> It's worth noting that all our VPN servers hijack calls to our public DNS server and that the DNS requests are processed on a local non-logging DNS server installed on that VPN server.
"... ensuring that no resolver gets the full picture."
Unless the resolvers share data with each other.
These public DNSCrypt resolvers will publish claims like "no logging" but how does one verify this is a true statement.
It may be better to use mutiple third party DNS resolvers, whether DoH or DNSCrypt, than to only use one, but the best course of action is not to use third party resolvers at all.
"Do you run a DNS server that sends out DNS data? For example, do you run an "authoritative DNS server" such as tinydns or PowerDNS Server or BIND or NSD or MaraDNS or Nominum ANS to publish the IP addresses of your web server and mail server?
This page explains the benefits of adding DNSCurve protection to your outgoing DNS data."
DNSCurve protects outgoing data from authoritative DNS servers.
I use CurveDNS experimentally in homelab in front of tinydns and nsd. It is easy to set up and it works great. Unfortunately not many authoritative DNS servers on the internet are using it even though it is easy to set up and works great (based on own experiments).
As stated above, the best course of action is to avoid using third party DNS resolvers, i.e., public, shared caches. Instead one can run a local cache that sends DNSCurve-encrypted queries to remote authoritative DNS servers. For example,
When using dq or dqcache, packets are _not_ sent "in the clear" for an ISP to sniff.
But, as above, the number of authoritative DNS servers using CurveDNS is unfortunately small.
The problem I see with DNSCrypt is it encourages use of third party DNS resolvers, i.e., shared caches.
I use locally-stored DNS data. When I retrieve DNS data from the interet I retrieve it in bulk using a variety of methods and sources. An unconventional approach perhaps but it works great for me.
Encrypted DNS is arguably pointless if one is using a popular browser that always sends SNI, even when SNI is not required, e.g., websites not using a CDN, or when visiting websites that do not support encrypted SNI, e.g., websites not using a CDN that supports encrypted SNI (ECH). Glad to see that the grandparent comment mentioned SNI.
There is no such thing as a "CurveDNS resolver". CurveDNs is a forwarder that encrypts DNS packets.
For me it runs bound to a loopback address, as do the nsd and tinydns servers. None of this traffic uses the network, there are no remote queries. There is nothing for the ISP to sniff.
When placed in front of a remote authoritative DNS server, that server can be queried using DNSCurve, e.g., with dq or dqcache. The packets are encrypted. ISPs cannot read them.
The IP address of the ianix.com name servers, 104.207.143.9, and the DNSCurve key, dns2sdrnxskf5lqt46v34cdlfqb9q2lvvmpr95g3l1qh0148sf6, can be obtained from the com.zone file, which is available for free from https://czds.icann.org/home
No recursive resolver is used. No packets are sent "in the clear". There is nothing for the ISP to sniff. Unlike public DoH or DNSCrypt servers, there is no third party DNS provider involved. No middleman.
AFAIK, there is no such thing as an "authoritative resolver". Authoritative DNS servers are commonly called "name servers". Recursive resolvers, i.e., caches, are never authoritative. Some might pretend to be, I have found examples of this easily in the past, highlighting the potential for abuse by operators of third party DNS resolvers.
> Personally, instead of DNSCrypt, I prefer CurveDNS
Neither is a replacement for the other; they're orthogonal. They solve different problems.
You should use both of them.
From the CurveDNS link you posted:
> CurveDNS supports:
> Forwarding of regular (non-protected) DNS packets
These are being sent in the clear, and your ISP is most certainly logging them. You should tell your CurveDNS resolver to use a (local) dnscrypt-proxy instance for resolving "regular (non-protected)" queries that don't have DNSCurve entries. Then you have the best of both worlds!
> The question I have for DNSCrypt fans is _why_ AFAICT no authoritative DNS servers are using it
Because DNSCrypt is only for querying recursive resolvers!
... and DNSCurve is only for querying authoritative resolvers.
DNSCrypt is link-level encryption between you and your recursive resolver (the thing you put in /etc/resolv.conf).
DNSCurve is link-level encryption between your recursive resolver (or you) and the authoritative resolver (like this one, which is authoritative for cr.yp.to):
$ dig -t NS yp.to
yp.to. 3600 IN NS uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
It is a shame that the two names (DNSCurve and DNSCrypt) are so similar.
> to protect The Netherlands against Russian and Chinese hackers
So it's a noble cause then? Or does it have privacy implications for innocent netizens? I thought these exchanges would have been tapped in some form way before this announcement?
The new law also lowers the bar for Dutch law enforcement to obtain records from these taps significantly, removing the necessity of a judge to rule whether the request is justified in the investigation.
Surely no law enforcement would overreach when given tools like these, right? Right?
> so is this why valuation of Snapchat is that high
Snapchat was supposed to be the WhatsApp / Insta / Facebook killer, but its value is lower than all those platforms. It's still rather niche. In terms of privacy it's still a nightmare and looks like it won't be fixed soon because it's easy to monitor and the authorities like that.
[0] https://www.sublimetext.com/
[1] https://addons.mozilla.org/en-US/firefox/addon/live-reload/