Hacker News Reader

Comment by nippoo | Hacker News Reader

This is beautiful. By using Netflix's actual CDN and requesting actual video files over HTTP, they're preventing ISPs from whitelisting fast.com without also whitelisting Netflix itself. Of course there'll be a game of cat-and-mouse with DPI, but it's a super-neat way of making it much harder for the ISPs to misrepresent actual video download speed...

View on HN

Yeah right. Just wait until a user visits fast.com and unthrottle their connection for 20 minutes.

I strongly suspect some ISPs already do that with speedtest.net.

Well the same tech could be built into Netflix apps on various devices, no web visit necessary. They also made a command-line tool available.

Still a win for Netflix.

Note to self: set up cronjob to ping speedtest.net and fast.com every 10 minutes, just in case.

I did that, works great and with speed test cli it (did it without that at first) it's even better!

https://github.com/sivel/speedtest-cli

If you are going to setup a cronjob/service for it, I suggest using the --simple flag.

Any before/after stats to show this made a difference in speed?

Could you clarify the question?

Do you have any proof that running a cron job impacts internet performance?

I believe you replied to the wrong person. I never made that claim unless I am going crazy.

speedtest-cli has a lot to offer as a tool

What did you mean "works great" for then? Just that your cron job works?

The actual tool I was suggesting was what I was saying works great. speedtest-cli has a lot more options available to you that a simple wget does not have.

It provides cleaner information quicker. Yeah you could certainly setup a cron job using wget and have it do everything you want it too down to the bits it changes in memory... That just offers a quicker way to do all you may want too with that information.

oh wow thanks for that. That's /much/ better than my DIY solution of using selenium to automate it...

I created a basic Windows service to do this (20 mins by default). Pull requests welcome.

https://github.com/jonashw/SpeedTestPingService/tree/master

I've thought about that as well. Is there any evidence/reports for this?

I've never seen any, but I've also never seen anyone try and find out.

That'd actually be great. The moment there's any evidence towards that happening I'm adding a cron script to visit fast.com every 15 minutes.

Make sure you update your user agent string to the latest Chrome every couple of weeks too. (I'm assuming any ISP doing this is already doing all kinds of sneaky things).

Since fast.com is https, the headers are encrypted. Correct me if I'm wrong, but unless the ISP has the CAs private keys they wouldn't be able to tell your user agent.

The DNS-Query or IP could be used to identify somebody accessing fast.com.

That still doesn't allow the ISP to tell the difference between e.g. wget and a browser via a current User-Agent-String, thanks to HTTPS.

The domain is exposed over various ways, yes, but that's the point of the idea to connect to fast.com regularly to trick theoretical shaping based on it.

List of supported ciphers is unencrypted and very UA-specific.

The CAs private keys can't be used to decrypt https. All the CA does is sign your public key in a certificate that shows validity and the domain name.

That would work for speed tests, but users will still get full HD streams suddenly (and reliably) downgrading to 320p after 20 minutes. That's still more likely to reflect negatively on the ISP than Netflix, I strongly suspect ;)

They may also just unthrottle for the first x MB of video.

We need a speedtest website hosted on tor :D Then ISPs won't be able to know when you visit the site.

Tor is over an order of magnitude too slow for this to work. You might get a result, but that doesn't tell you much about the speed of your internet connection.

As someone who works on multi-terabit networks, this would be very difficult for most network operators to handle. Don't overestimate the competence for malice here. Usually the tactics of shitty ISPs are much more simple, such as not lighting up peering ports that their eyeball customers are in effect paying for.

They don't need to : they just host a speedtest.net server on their own network, which the client will select by default.

Wow, I hadn't thought of that before! That really is genius.

It is beautiful, and even if it weren't harded to misrepresent video download speeds, it's a significant step up from speedtest.net. And now there's no need to leave the command line, which is even better. That said, perhaps "making it slightly harder... to misrepresent... video download speed" is more like it.

https://github.com/sivel/speedtest-cli

They could block or override the A RR for fast.com so that a client can't connect.

The only times I use my ISP's DNS servers are when I initially set up a computer and forget to change the settings.

Yeah but unless you tunnel your DNS traffic they can modify responses very easily. Not that this is super common yet.

Is this what DNSSEC is supposed to prevent?

Yes and no. It is what DNSCurve is designed to prevent.

At a certain point if they're going out of their way to mess with the connection I'm paying for I'll stop paying for it and go elsewhere.

Reply on news.ycombinator.com