New standards for a faster and more private Internet(blog.cloudflare.com) |
New standards for a faster and more private Internet(blog.cloudflare.com) |
And while we're explaining things... ODoH (indirectly mentioned in the article via the Encrypted DNS link) comes with a big bold warning it's based on the fundamental premise that the proxy and the target servers do not collude. When both are operated by the same company, how can you know they aren't colluding? Is there some mechanic in the protocol to help protect users from colluding servers?
You don't. At best the client can check domain names and IP addresses, but that's hardly a guarantee.
To solve that problem, you can combine multiple parties. For example, you can use https://odoh1.surfdomeinen.nl/proxy as a proxy (operated by SURF [1]) to use the Cloudflare servers for lookup.
I think for ODoH to work well, we need a variety of companies hosting forwarding services. That could be ISPs, Google/Microsoft/etc. or some kind of non-profit.
Or Apple[1,2].
[1] Oblivious DNS over HTTPS, https://www.ietf.org/rfc/rfc9230.txt
[2] About iCloud Private Relay, https://support.apple.com/en-us/102602
I'm thinking that maybe I'd like to be able to avoid mentioning the server I'm interested on, and simply send a hash of it (you can cut a prefix such that a bunch of matches are found, but not too many)
Yeah, and unfortunately it increases the moat such companies have. They can offer a privacy screen that smaller orgs just can't match.
This isn't privacy. This is centralized snooping.
It's like Google's approach to third party cookies. Nobody other than Google can have tracking information.
It will be when everyone adopts ECH. It's a fantastic start.
The CDN can't give you content you're asking for without knowing which content you're asking for.
This improvement prevents your ISP and the government from reading your packets to get that same information.
I'm all for being wary of large-scale consolidation, but I feel like these lazy gripes aren't assessing the pros and cons dispassionately.
I think these are important issues and worth talking about.
Maybe some PIR protocol can also eventually change this (if the users and Cloudflare don't mind the computational and network overhead!).
These parameters are described in the v1.5.6 release notes [0]. ZSTD_c_targetCBlockSize is the most notable, but ZSTD_c_maxBlockSize can also be used for a lower CPU cost but larger compressed size.
Are you using these features at Cloudflare? If you need any help using these, or have any questions, please open an issue on Zstandard's GitHub!
Given how branchless algorithms are helping optimize not just network transport (compression) and even OS system libs (no citation for this one, but I’ve heard), that I really wish colleges begin teaching this along with DS/Algo course material.
Data Structures & Algorithms is also sometimes abbreviated as DSA
Edit: just look at how many sites you're locked out of if you don't have JS enabled or run an uncommon configuration.
Given we now have two strictly better algorithms than gzip, I also wonder about a hybrid scheme that starts with Zstandard but switches to Brotli when the compression time is no longer significant for given request. We might even be able to cheaply convert the existing Zstandard stream into Brotli with some restrictions, as they are really LZSS behind the scene?
The faster Brotli levels could probably be made to match Zstandard’s compression speed. But we’ve invested a lot in optimizing these levels, so it would likely take significant investment to match. Google is also contributing to improving the speed of Zstandard compression.
A cheaper conversion from Zstandard to Brotli is possible, but I wouldn’t really expect an improvement to compressed size. The encoding scheme impacts how efficient a LZ coding is, so for Brotli to beat Zstandard, it would likely want a different LZ than Zstandard uses. The same applies for a conversion from Brotli to Zstandard.
ECH seems directly opposed to Chinese governments control of the web.
It means nothing. Countries always ask nicely first for a domain to be blocked for IPs from their countries. Companies like Cloudflare or Akamai can either honor the request, or find their IP range blocked (yes, including all the other serviced domains). They usually take the first option.
South Korea is infamous for their internet censorship.
https://en.wikipedia.org/wiki/Internet_censorship_in_South_K...
They do not have anybody else's best interests at heart and are actively centralizing that which was explicitly intended to not be centralized.
CF blocks Tor; you can't get past the captcha.
I use the elite hacking tool know as FIRE FOX and I get CF gatekept all the time.
[1] https://github.com/facebook/zstd/blob/dev/contrib/seekable_f...
Source?
ECH makes it hard to block known scam sites at the network layer, for example.
End users who want to protect themselves can easily install blacklists on their end. All major browsers support something like Google Safe Browsing out of the box, and these blacklists are more likely to be kept up-to-date than those of the average ISP.
Idk about Iran, but Russia and China just block eSNI, QUIC and whatever their DPI firewalls can't really handle on the fly.
I remember when you can just change your DNS provider to bypass censorship. Nowadays, browsers and OS provide safe DNS by default, and thus censors had mostly switched to DPI based method. As this cat and mouse game continue, inevitably these governments will mandate spyware on every machine.
These privacy enhancements invented by westerner only work for western citizens threat model.
let the cat and mice game between deep packet inspection (DPI) vendors and the rest of the encrypted internet continue. it’ll be amusing to see what they come up with (inaccurate guessing game ai/ml “statistical analysis” is about all they’ve got left, especially against the large umbrella that is cloudflare).
game on, grab your popcorn, it will be fun to watch.
This approach won't work on apps like Facebook or Instagram, but I don't think there's a legitimate reason to permit-but-snoop on that sort of traffic anyway.
> Zstandard
I get "faster" but how does it make the internet "more private". The word "private" only shows up exactly once on that page, in the title.
> This means that whenever a user visits a website on Cloudflare that has ECH enabled, no one except for the user, Cloudflare, and the website owner will be able to determine which website was visited.
So you must use entity which controls the DNS and this entity makes the request further for actual website. Feels like just worse VPN.
However, the word "privacy" shows up 10 times in the article.
Companies aren't binary good or bad. They go through a lifecycle. Today's young and scrappy startup fighting for the people and the CEO making house calls is tomorrow's big tech with AI chat support.
It's worth noting where a company is in its lifecycle, and what the world is likely to look like if it continues to grow.
How do we know that? Who else benefits from most of them?
Trust isn't being moved, though. Cloudflare could, by design, always see what website you were accessing. The difference is with ECH, there is one less party (someone listening in on your internet traffic) that can see which hostname you're accessing.
They eventually found out that the third party provider was in fact the Australian Federal Police, reading all their messages in clear and in real time.
The government only needs to compel a corporation if that corporation has an adversarial relationship with them.
We have tried the centralized model pushed by Cloudflare before, it was called the Minitel.
I assume the seeking implies a significantly faster way to skip the first N bytes of the decompressed output without the actual decompression. "Significant" is here defined as a time complexity strictly less than linear time in the size of compressed or decompressed data in that skip, so for the RLE sequence like `10a90b`, seeking to the 50th byte should be able to avoid processing `10a` at all; reading `10a` but not actually emitting 10 copies of `a` doesn't really count.
Virtually every compression algorithm has two main parts, modelling and coding. Modelling either transforms the input into a more compressible form, or estimates how much is particular portion of the input likely. Those results are then coded into one or more sets of symbols with different probabilities, resulting in a compressed bit sequence. Both parts can be made as complex as needed and will likely to destroy any relation between the input and output byte. Many algorithms including Zstandard do come with some framing scheme to aid with data verification, but such framing is generally not enough for actual seeking unless each frame declares both the uncompressed and compressed size and can be independently decompressed from each other. That's what the Zstandard's seekable format actually does: both sizes for every frame, and an implicit promise that a new frame is generated every so often. (Zstandard frames are already defined to be independent.)
There do exist some compression schemes that retain the seekability by design. Texture compression is a good example; a massively parallel nature of GPUs means that a fixed-rate scheme can be much more efficient than a variable-rate and thus inherently sequential scheme. There are also some hybrids that use two interconnected algorithms for CPU and GPU respectively. But such algorithms are not a norm.
Wtf, you were the one who brought that up.
This alongside people smuggling in starlink is making censorship useless.
That's said, it will not come to that. They'll just mandate spyware installation.
And starlink can be traced. It’s only time before some people start getting arrested.
Iran does not.