DoH does wonders against ISPs which filter DNS traffic (including traffic to third-party DNS servers). This happens more often than many people realize. My ISP blocks traffic to a couple of random websites (perfectly safe and legal) just because their security system doesn't like them, and they can't do anything about that. I only wish for more websites to deploy ECH, because they are using SNI filtering as well.
This is surprisingly easy to beat using very funny methods, like splitting the request in the middle of SNI, or sending a request with a low TTL to an unblocked website first which gets dropped then repeating it to the correct SNI.
There are more methods all of which I find very funny for some reason. You can use GoodbyeDPI on Windows and zapret on Linux.
The disadvantage of those methods is that they require installing custom software, and they don't work on mobile devices unless you put them behind a router with custom firmware. In contrast, DoH works out of the box on most operating systems, and hopefully ECH will work as well.
I guess it depends on the situation then. My ISP doesn't pull such stunts and if they did, I would switch them in a moment. Fortunately others around here don't suck either. Cloudflare (or Google, or whoever) OTOH gets waaaay too much data from everybody. For my taste at least.
I'm glad your ISP doesn't do that, but there are a lot of people not as lucky as you, and we shouldn't deny them all a major increase in privacy just to avoid having you to change one browser setting.
Very true...
I used to be with Sky here in the UK, and at the time they were running a transparent proxy on port 53. Changing DNS providers made no difference to the dnsleaktest results. Don't know if they still do that now.
I'm now with a different ISP, and anyway have PiHole handling DNS queries on most devices in our house. It forwards DNS requests to dnscrypt-proxy running on the same Pi, which uses Quad9 over DoH.
If you're using insecure DNS, then you have no choice but to let your ISP see all your queries. But if you're using DoH, you can choose from plenty (see https://github.com/curl/curl/wiki/DNS-over-HTTPS) of other DoH providers instead if you don't trust Cloudflare.
Frankly, the article is doing a lot of disservice (and should be removed in HN because of its grossly outdated information). As josephcsible pointed out, there are many, many options for DoH.
Same goes for if you have an IoT device behind a corporate firewall and you are being forced to use a enterprise DNS server running on some Cisco or Juniper device which doesn't respect TTL's, filters TXT records, etc.
Ah, are you a data exfiltrator or a ransomware operator? I jest.
I think the network as a chokepoint will slowly go away due to improvements in cryptography, and we'll need the endpoint to do all the inspection and enforcement.
> I think the network as a chokepoint will slowly go away due to improvements in cryptography, and we'll need the endpoint to do all the inspection and enforcement.
That's exactly what I want, because any solution other than that one would allow network operators to snoop on other people's endpoints.
> A decent corporate policy will block or decrypt DoH, same as it blocks direct outbound DNS.
DoH is simply HTTPS traffic as far as a firewall is concerned so how are you going to block or decrypt it?
If you take it a step further and you are running a DoH server on the same place where the API endpoints (REST, gRPC or whatever) for your IoT device are running no one is going to see the anything but HTTPS traffic
HTTPS decryption in corporate environments is standard. Have a corporate root CA, install certs on endpoints, and man-in-the-middle the network traffic.
In Rust, if expressions are not place expressions. In the example, arr_ref is a reference to a temporary, not to an array element. In Rust, it is possible to take an address of any expression, but taking an address of a value expression will produce an address of a temporary.
I understand that some people prefer a dark theme. What I don't understand is why do some people think that everyone must prefer a dark theme, so they set up their websites to always use a dark theme, regardless of the browser preference?
At least, this website lets you switch to a light theme. But if you do, inline code fragments still use a background color from the dark theme, which makes them practically unreadable. Looks like the author doesn't care about people who prefer a light theme. Then why they complain about websites made by people who don't care about people who prefer a dark theme?
I agree that implementing two themes but not following browser preference is odd, although I'm a dark mode user. The weird thing is that the Hugo theme used (PaperMod) follows browser preference by default. The blog author had to explicitly turn that off.
It’s a consequence of thinking light/dark modes are personal preference when they’re accessibility features.
And when viewed from that lens you can see how off-putting it is when it’s a paid feature, or only adjustable when logged in, or a user-setting that seemingly always defaults to light.
Usually SSO means that you have to login just once to access all of your accounts. If it requires you to login multiple times a day then something is not configured correctly.
Well... at my current employer, we have 3 "SSO" providers.
By that, I mean three different Okta logins, and logging in to any of them will log you out of the other two. If I want to do anything, it means I need to log in again because it is unlikely that I am logged in to the right account.
Yes, I need all 3 multiple times daily. There is no logic about which one I need for which system.
IT knows this is not how it is supposed to be, but they assure us that this is a temporary situation. I guess 1.5 Years is still temporary.
If you can use Firefox, it allows you to create multiple "containers", each with its own set of cookies and other state. You can create a separate container for each Okta login, then you can be logged into all three accounts simultaneously.
Also you can create a separate browser profile for each account. This works with all browsers but is less convenient, because it forces you to have a separate browser window for each profile, and also you need to enter all preferences for each profile separately.
Solution: configure your browser to force new windows into new tabs. Also, if you are using an unpopular OS, they probably won't bother to copy the window style.
