Yup. This is pretty much the reason Netflix created fast.com. They wanted a speed test service that couldn’t be gamed by ISPs. Many ISPs will prioritise traffic to know speed test services (like Ookla’s speedtest.net), making their services appear faster than they’re under more normal usage.

By placing fast.com on Netflix IPs, ISPs either have to prioritise all Netflix traffic (which they’re very unlikely to do), or accept that fast.com is going to provide a more realistic measurement of their performance.

When netflix IPs was blocked by this ISP, it's pretty much impossible to use netflix because the only way to get around the block was to use VPN, but netflix itself blocks VPN access.

Surely it would essentially saturate your fibre if there was net neutrality, unless you don't pay for full fibre speeds?

Internet2 is used by hospitals, among other things, and as such has higher robustness requirements than Internet1. The pandemic created much higher demand for bandwidth from hospitals, forcing Internet2 providers to scramble to keep up in areas. As such, blocking high-bandwidth sites which are clearly lower priority than medical traffic might have actually been a reasonable move.

[1] https://en.wikipedia.org/wiki/Internet2

It might have been difficult relative to the infrastructure at some hospitals - but that is to my point that hospitals in general are not very demanding bandwidth wise and I would be a bit surprised they’re more than a rounding error on the Internet2 in general - especially compared to all the academic research involving large models and just video streaming in general that blew up during the pandemic.

Remote Desktop and even PACS are not huge bandwidth consumers in this day and age of 4K streaming. At my large academic institution usually only the radiologists use the PACS client directly on workstations - all the other clinicians are using a “zero footprint” viewer over Citrix like everything else.

> If everyone used it

Like many large facilities I’ve been in the US, the EMR and PACS viewer (for non rads) are often over Citrix (ie every workstation is a Citrix client). But how many people are simultaneously viewing images - it’s only a minority of users (both in general - the ancillary staff is not) and at any given time (most clinicians are not viewing images at any moment)

This is a large university affiliated center - the bandwidth used by the medical center is a drop in the bucket compared to the size of the pipes they (the uni) have.

Neither of them actually ran any traffic over it.

Thinking about it, it seems like watching habits could make streaming be more or less "efficient" compared to downloading once and storing it locally (depends on how one chooses to calculate efficiency tbh).

People that have things they regularly re-watch are obviously gonna benefit from having a local copy they can access entirely on their own terms.

It hadn't occurred to me until recently, but the way I watch stuff has me going through a pretty large amount of data yet I'm also excessively unlikely I re-watch nearly anything that I've seen in the previous 2 years. Whether something is streamed or stored local, it has to be downloaded the first time it's watched. If it'll take 2 years before I re-watch something, it's a waste of time and money to keep a backlog of multiple disks worth of video

Very wasteful if I did much streaming.

They may have an ISP-local netflix cache, from Netflix themselves not some home-grown hack, so they can achieve that with some reliability without it costing as much as it otherwise would for bandwidth peering.

(PDF): https://openconnect.netflix.com/Open-Connect-Briefing-Paper....

But they're intentionally otherwise indistinguishable from any other real movie on Netflix.

Mb = megabits

1 byte = 8-bit

Perhaps HNers know better, but among lay people, pretty much no one talks about megabits. For example, people know that an MP3 is about 5MB. They know that they can email attachments up to 20MB (or sometimes 10). But I've literally never heard a lay person talk about bits, or bits per second.

And the fact that ISP's transfer caps are denominated in bytes makes things all the more confusing.

(As a historical side note, there was even a weird transitional period where a “1.44 MB 3.5 floppy” held 1.44 * 1000 * 1024 bytes, or what everyone at the time would have called 1440 kilobytes.)

Personally I think it’s unfortunate that standards bodies and even courts have sided with the disk manufacturers. I also find the SI binary prefixes utterly revolting on an aesthetic level, so I’d much rather join whatever parts of the tech industry are still holding out.

It is really trivial to do basic traffic snooping and see what people are looking at. I'm surprised it isn't more common.

I figured it would be harder, or perform worse, but I easily wrote a little piece of software that filters the TLS ClientHello for arbitrary domains. Maybe 10 years ago hardware wouldn't have been able to do this, but I bet it's no big deal now. So your filter chain just looks like <Netflix IP range> -> <has fast.com ClientHello> -> unthrottle. You don't need to do packet inspection on every packet, just ones that you might be interested in (e.g. Netflix IPs).

It's crazy to me that the many people who care about privacy and censorship in tech haven't pushed ECH (encrypted ClientHello) harder. It's such a gaping hole in web privacy that you can still passively snoop domain names sent in cleartext. It makes DoH/DoT almost pointless.

Incidentally, my speeds on fast.com are always terrible (about 1/8 of what I get elsewhere), despite the fact that I'm fairly confident it is not being throttled. That's because the speed I see is >100 Mbps, which is like 4 Netflix UHD streams. Wouldn't be much point in throttling to that speed, you'd want 10 Mbps max, and less on wireless.

The correct mental model is that it’s good enough to convince 1990’s US internet users to type their credit card into a web page. (Where the downside of a breach is that you have to dispute some charges and change your CC#.)

If you need stronger security than that, then many, many caveats start to apply.

For instance, by default, anyone that can reliably man-in-the-middle port 80 on your website can get an acme certificate for your domain from a reputable certificate authority.

Also LE actually knows this attack is possible and mitigates it by validating the challenge from multiple sources so the attacker would need to be in the middle of all the LE validators and your servers.

https://portswigger.net/daily-swig/lets-encrypt-deploys-new-...

You might have access through editing a proxy rewrite rule, for example.

In the attack above you use your own SSL provider for a cert (LE not involved) and you overwrite the cert in a sense that existed before. You choose a provider that just validates with a file location. It's an attack which already requires compromise.

It’s not hard to monitor cert transparency logs, which will show this new cert.

I think it’s more likely you are not considering the full picture of the TLS ecosystem, or are making arbitrary distinctions like “cert transparency logging isn’t actually part of HTTPS.”

Consider that Symantec basically did what you suggest (mis-issue a cert) and not only was it detected and mitigated, they lost their CA business entirely over it.

You are leaving out a huge caveat here - exactly where the MITM is taking place matters a lot. In 99% cases this isn't possible unless the victim server network is effectively compromised.

Sure, they could apply some kind of advanced DPI assessment based on packets sizes over time and other crap, but if anyone complains it's much easier to just say "well, does speedtest.net work? What about Google's speedtest? Hmm, strange, must be fast.com being slow then!". If they just check for fast.com in the SNI header, I know I'd be loading the speedtest every time I want to watch Netflix.

ECH is slowly coming along, but it's still perfectly possible to detect these speed tests. It just takes much more time and effort to set up right.

I'm honestly surprised the article shows enabling a VPN actually working to fix the messed up network here. That would be a perfectly valid solution in my opinion; if I notice my ISP is messing with my network like this, there's no way I trust them enough not to use a VPN.

They don't count the "shaped/throttled" sites against your data plan limits, so I can see some people liking it.

Some throttling by default for video actually is sort of for your benefit, at least indirectly, although I don't know if carriers are throttling more than that amount.

A surprisingly large number of people nowadays watch movies on their phones or small tablets. On screens that size at the distances they typically hold them from their eyes 4K and usually 1080p won't offer any visible improvement over 720p. On some devices even 720p probably won't offer an improvement over 480p.

It is to everyone's benefit if other people on the network don't stream at a higher resolution than is necessary to reach the limit of what is visible. Since most people aren't going to change any settings from the default, defaulting to low speed streams maximizes benefits.

Therefore, I have a background bash loop just looking up fast.com every 30 seconds all day long.

I’m working on using a Smarty (Three UK-owned budget label MVNO, for those unaware) SIM card in a 5G modem as a backup line, and haven’t been super impressed with speeds — so curious about trying your tip.

Technically the website fast.com resolves to an Akamai IP, but the actual speed test it loads does use a Netflix server IP.