Live data from Hacker News

Https hurts users far away from the server

antoine.finkelstein.fr

61–70 of 128 posts

Re: Https hurts users far away from the server

#61
post #3

There is also another problem on how much and how often is Googlebot indexing your site because your site speed is one of the factors of so called Google index budget. My users are in Germany so my VPS is also in Germany to be fast for local user (~130ms for http reply), but for US Googlebot is my site slow (~420ms for http reply). So you are penalized also for this.

Hi - I know some tools report a slow site in this case, but these reports are not accurate - don't believe them! Google is not that stupid ! :D I am currently working as a dev in an SEO-Agency (in Austria), and we never believed this hypothesis - so we tested this once with a bunch of our sites: When moving sites with a German speaking audience to a VPS in America, your rankings at google.de/google.at will decrease (…

That sounds like a really interesting experiment. Kudos for taking a scientific approach to SEO.

A bit off-topic, but out of curiosity, have you run any other interesting experiments like this? I would love to read a blog post about them.

Re: Https hurts users far away from the server

#62

It seems to me that it is worth considering that HTTPS is not always a panacea of goodness. We should think about two things. First that almost every firewall out there right now supports https snooping via MITM. Example: https://www.paloaltonetworks.com/features/decryption Second, I just got back from rural China where most unblocked american webpages take between 5-15 seconds to load on my mobile phone many of them…

Is there an easy way to pipeline those requests over one TCP connection? Or is that only possible with http/2?

I wonder if it would be lower latency to open a single websocket tunnel on page load and download assets over the tunnel. Although at that point I suppose you're just replicating the functionality of http/2.

Re: Https hurts users far away from the server

#63
post #20

Earlier quoted context omitted.

> Many ISPs I think that's a bit sensationalist.

Vodafone in the UK did this to me.

Vodafone is the worst. Although it's really the U.K. surveillance state that is the problem.

When I popped my SIM into my iPhone it forced me to download a configuration profile with a self-signed Vodafone cert, which means they can mitm any connection. I think this is required by the government so they can block adult websites by default? (I've also seen torrent websites also fail silently with misleading "server not found" errors)

I haven't looked into if they're doing the filtering via DNS or mitm, but I avoid the censorship by connecting to a vpn.

Re: Https hurts users far away from the server

#64
post #3

There is also another problem on how much and how often is Googlebot indexing your site because your site speed is one of the factors of so called Google index budget. My users are in Germany so my VPS is also in Germany to be fast for local user (~130ms for http reply), but for US Googlebot is my site slow (~420ms for http reply). So you are penalized also for this.

Hi - I know some tools report a slow site in this case, but these reports are not accurate - don't believe them! Google is not that stupid ! :D I am currently working as a dev in an SEO-Agency (in Austria), and we never believed this hypothesis - so we tested this once with a bunch of our sites: When moving sites with a German speaking audience to a VPS in America, your rankings at google.de/google.at will decrease (…

Report tool I use is Google's official webmaster tool (420ms an average time in "crawl stats").

And here is the article on budget https://webmasters.googleblog.com/2017/01/what-crawl-budget-...

Re: Https hurts users far away from the server

#65
post #54

Earlier quoted context omitted.

A mini audit along the lines of 'builtwith'. Hm. Good idea, why not go a step further and turn the 'no server signatures' advice on it's head: full disclosure, server signatures on, in fact, list each and every component in the stack so that end users can (through some plug-in) determine whether or not a site is safe to use. Of course nothing bad could ever come from that. /s I'm all for making the use of for instanc…

It would have to work without the site's permission, so the browser (or maybe a third party service) would do a basic vulnerability scan. Maybe orange could mean "a script kiddie could pwn this site in under an hour", and yellow would mean "we don't see how your ISP could mitm this, but server side providers (aws, google, azure cloudflare) definitely could." FWIW, my personal website uses let's encrypt, so it would b…

> FWIW, my personal website uses let's encrypt, so it would be yellow or worse.

This shouldn't effect your security stance.

There's a common misconception that you trust your private keys with your CA and they can somehow transparently MITM you. But they only have your public key, not your private keys, so they can't do that.

The security threat from trusted CAs is that they can MITM anyone, regardless of if you use them or not. BUT the attack isn't transparent, and things like cert pinning are effective in the real world from preventing attacks.

Re: Https hurts users far away from the server

#66
post #54

Earlier quoted context omitted.

It would have to work without the site's permission, so the browser (or maybe a third party service) would do a basic vulnerability scan. Maybe orange could mean "a script kiddie could pwn this site in under an hour", and yellow would mean "we don't see how your ISP could mitm this, but server side providers (aws, google, azure cloudflare) definitely could." FWIW, my personal website uses let's encrypt, so it would b…

Wait, why does letsencrypt allow mitm by server provider?

Domain validation only requires an HTTP response. They can easily MitM that specific response to fake a certificate for your domain.

Re: Https hurts users far away from the server

#67

It seems to me that it is worth considering that HTTPS is not always a panacea of goodness. We should think about two things. First that almost every firewall out there right now supports https snooping via MITM. Example: https://www.paloaltonetworks.com/features/decryption Second, I just got back from rural China where most unblocked american webpages take between 5-15 seconds to load on my mobile phone many of them…

> First that almost every firewall out there right now supports https snooping via MITM. Example: https://www.paloaltonetworks.com/features/decryption

Seems prudent to mention that this requires cooperation of the client bein MitMed. Specifically, the client needs to install a root certificate.

Re: Https hurts users far away from the server

#68
post #4

I don't understand why I need to use https on a static marketing webpage. No login stuff, no JavaScript, nothing. Just straight up HTML and CSS. Right now I need to pay about $150 every year for something that's only used to satisfy Google PageRank (I can't use LetsEncrypt with my hosting provider). Why?

2 reasons. The first is practical: integrity. Https guarantees the site your visitors see is the site you sent them.

The second is more moral. Making https the default means more and more of the web will be encrypted and authenticated. This is a good thing.

Re: Https hurts users far away from the server

#69
post #3

There is also another problem on how much and how often is Googlebot indexing your site because your site speed is one of the factors of so called Google index budget. My users are in Germany so my VPS is also in Germany to be fast for local user (~130ms for http reply), but for US Googlebot is my site slow (~420ms for http reply). So you are penalized also for this.

[deleted]

Re: Https hurts users far away from the server

#70
post #66

Earlier quoted context omitted.

Wait, why does letsencrypt allow mitm by server provider?

Domain validation only requires an HTTP response. They can easily MitM that specific response to fake a certificate for your domain.

Got it. But this only happens once when you apply for the cert (or renew it), correct?
Post reply on HN