Re:Building fast.com
by nippoo on Tuesday August 09, 2016 @03:34PM
(#12257176)
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...
[ Parent
| 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.
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?
Re:Building fast.com
by safewayclubcard on Tuesday August 09, 2016 @07:29PM
(#12258401)
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.
Re:Building fast.com
by madeofpalk on Tuesday August 09, 2016 @08:15PM
(#12258627)
oh wow thanks for that. That's /much/ better than my DIY solution of using selenium to automate it...
Re:Building fast.com
by wilsonjonash on Wednesday August 10, 2016 @02:57PM
(#12264018)
I created a basic Windows service to do this (20 mins by default). Pull requests welcome.
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).
Re:Building fast.com
by scrollaway on Tuesday August 09, 2016 @07:19PM
(#12258354)
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 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.
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.
Re:Building fast.com
by scott_karana on Tuesday August 09, 2016 @10:00PM
(#12259036)
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 ;)
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.
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.
They don't need to : they just host a speedtest.net server on their own network, which the client will select by default.
Re:Building fast.com
by BurningFrog on Tuesday August 09, 2016 @04:39PM
(#12257553)
Still a win for Netflix.
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.
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.
They may also just unthrottle for the first x MB of video.
Re:Building fast.com
by davidsawyer on Tuesday August 09, 2016 @03:56PM
(#12257313)
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.
Re:Building fast.com
by olejorgenb on Wednesday August 10, 2016 @04:33AM
(#12260290)
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.
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.
Re:Building fast.com
by bckygldstn on Tuesday August 09, 2016 @10:39PM
(#12259168)
Is this what DNSSEC is supposed to prevent?