So far in in most of the world even platter disks (which have really poor performance with modern Windows) are faster than network. Which means you can download description of the difference and reorder the file locally much faster than downloading it. Yes it needs the file to made in a way that is update friendly - most current compression algorithms can be configured like that. Yes, compression will be slightly lower, but you will save on both download size AND disk space, because right now most patches require you to download patch and then apply it, requiring twice the space. If you have 5% larger asset file but can patch it with a few memcpy on a mapped file it is a win in every way imaginable.

It is just really poor programming, nothing more. And it's everywhere. If find source >/dev/null takes 6 seconds there is no reason for gradle to take 2 minutes on a rebuild. If the dev is used to that, why would they even think about patch optimisation?

Microsoft made sure in windows 10 that it's almost unusable without SSD. SO you big binary blob file have random r/w access.

Most backup software is able to do good binary deltas of arbitrary data for decades. Even dumb checkpointing resolves problem of downloading 25 versions - you download latest checkpoint and deltas from there.

Don't excuse poor design and programming, when you know a file structure, creating a differential update should be short task. With a tiny bit of algorithmic knowledge you could even optimize the process to only download needed assets inside of you big binary blob - if the asset was changed 7 times during your last 25 version you only need to download the last one.

So you would like basically modern gopher? And some RSS for a good measure?

There is no such mechanism in TLS, but HTTP Range header and wikipedia supports it.

So if you want to be protected agains this side-channel problem you can use Connection: Keep-Alive header along with Range header to split each request into a few Range requests.

As TLS pads data to the block size you can introduce uncertainty of 0-8 bytes per chunk. Put some random delays between chunks and while it will be slower and with a bit higher overhead passive attacker won't tell if you're requesting one article in chunks or a few other.

And all this can be implemented client-side.

Anything that is in web browser (like e.g most uses of protonmail) offloads all security to the security of the TLS connection.

Unless you also ensure proper certificate pining, if someone can get a court order for any accepted CA to give them a valid certificate for your domain you won't notice a thing while that someone gets your browser to run any code and e.g. dump keys, certificates or messages.

What's missing is a way to pin web apps so that you always get the previous version (and can opt in to subsequent versions after checking their hash from a trusted source).

There is a clever way of doing this, using a bookmarklet, a dataURI, and SRI, but the UX isn't great.[0] If something like Hashlinks[1] were supported by browsers, though, this could work quite nicely.

[0] https://news.ycombinator.com/item?id=17776456

[1] https://w3c-ccg.github.io/hashlink/

> I think all major browsers require certificates to be logged at this point

None of the browsers require by policy that certificates be logged. What this means is that the existence of a certificate which wasn't logged is not by itself a misissuance. Whereas for example the Apple 398 day rule is a policy rule, so a certificate which breaks the rule not only won't work in Safari, but it is also a misissuance and your whole CA might get distrusted by Apple.

However, all the major browsers except Firefox require that certificates they are shown which purport to have been issued after a mandate are presented with SCTs. We'll discuss what that means below. For Chrome that mandate begins after 30 April 2018, which means it doesn't catch certificates issued in a small window of time when certificate lifetimes up to 39 months were still allowed at the start of 2018, the last of these certificates would expire at the end of next month, May 2021.

In practice no public CA was selling unlogged certificates intended for web servers by the point the mandate triggers, it would have been a needless business risk to sail so close to the wind, so chances are no certificates in this category exist today.

Signed Certificate Timestamps are issued by the log, they are like "proof of posting" when you send a letter. The log warrants that any certificates for which it has issued SCTs will appear within the Maximum Merge Delay (for public CT logs this is 24 hours).

That might seem like a long time, but it's a do-or-die promise. Logs which experience a problem making them unable to show a consistent log with the corresponding certificate within 24 hours are disqualified and you need to start over, because without such a rule obviously you can smuggle anything into an outage.

Google and Safari's policy (I don't know the Edge policy) dictates two or more SCTs, at least one to be from a log controlled by Google. So this gives Google the handy property that they don't need to trust any combination of third parties, you must show all certificates to Google itself.

But those numbers without context are just that - numbers. It's the context that makes it information. GPS coordinates by itself are the same, they're just numbers, but by attaching meaning to them you may make them dangerous or illegal to publish. And sometimes enough meaning is "don't let anyone know it" - the rest can be gathered from the context and other data.

"95601890" is just an arbitrary number, the same as any other.

Additional metadata, such as "it's a driver's license number", "it relates to person X" gives it context and makes it information. 4037 is a bank pin code for millions of people, but as long as you don't combine it with a person it's just a 4 digit number. When you combine it it becomes information protected in many countries.

If you're the only person that knows a particular sequence of letters or numbers you own it.

If you remove all knowledge of that information you destroy it. And by "all knowledge" I mean every known way to generate it, not just a simple representation.

There is nothing special among any single number in 160 byte string, but it contains all SMS ever sent. Some of those messages are of special interest to some people.

Punching holes doesn't work only when network devices in between are broken or are actively preventing it.

From the network point of view it looks the same as two hosts starting an outgoing TCP connection through nat - if that works then hole punching should work too.

Not TCP. UDP - there are no connection in UDP, so the routers / firewalls don't really differentiate between a new connection and packets that happen to have the correct ip+port.

Some are trickier than others, as there are 2 IPs and 2 ports in a packet (at any point), and it can be hard to match all of them for the stricter devices, esp. on NATs that do source port randomization.

> when network devices in between are broken or are [maliciously] actively preventing it.

Those are called "middleboxes" (IIRC) and they're unfortunately somewhat pervasive.