Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Will Soon Shame All Websites That Are Unencrypted

motherboard.vice.com

Post reply on HN
Print view View original

191–200 of 369 posts

Re: Google Will Soon Shame All Websites That Are Unencrypted

#191

Post by Dylan16807 »

cryptoz wrote: post #187
solotronics wrote: post #183

Earlier quoted context omitted.

No offense meant but why not get the app? I understand not wanting an application for a news website or something like that but something you use often like google calendar it would seem like the application would be better than the mobile page.

I do have the app. And that fact makes this double-annoying. When trying to visit a website, I'm told not to do that. That would be annoying on its own, and in fact it was for the first few years that it happened. But that's not at all what is frustrating me right now. What's super annoying is that Google claimed last year that they would penalize websites that do this, because they find it annoying too. Except they…

Why do you assume they're not being penalized?

Showing that they rank above "timeanddate.com" doesn't mean a lot.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#192

Post by icebraining »

ryanlol wrote: post #105
forgottenpass wrote: post #59

Earlier quoted context omitted.

SSH gets this right No, it doesn't. When was the last time you verified a host key out of band? And if you're using SSH, you know well enough to know why you should do the damn legwork to verify the key. What do you expect for end users? Furthermore, if nobody is doing out of band verification on the first pass, how do you expect users to distinguish between an attack and legit host key change?

But the worst case scenario with SSH MitM isn't someone being able to eavesdrop on your connection. But someone pretending to be the server, which is hardly as serious. (Unless you're using password auth, in which case you deserve to get owned)

If someone impersonates your server, it can then pass the authentication request to the original, and gain full MITM without your knowledge. Yes, even if you use public key auth.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#193

Post by cryptoz »

Dylan16807 wrote: post #191
cryptoz wrote: post #187

Earlier quoted context omitted.

I do have the app. And that fact makes this double-annoying. When trying to visit a website, I'm told not to do that. That would be annoying on its own, and in fact it was for the first few years that it happened. But that's not at all what is frustrating me right now. What's super annoying is that Google claimed last year that they would penalize websites that do this, because they find it annoying too. Except they…

Why do you assume they're not being penalized? Showing that they rank above "timeanddate.com" doesn't mean a lot.

Being ranked #1 in a Google search for 'calendar' does mean a lot. Also, let's say they are penalizing themselves, but the penalty isn't enough to change their ranking. Why, then, would they claim that they are making this change because it's better for users to not have these ads but to still run these ads themselves?

> Our analysis shows that it is not a good search experience and can be frustrating for users because they are expecting to see the content of the Web page.

https://googlewebmastercentral.blogspot.com/2015/09/mobile-f...

This would imply that they know the experience is bad for users, they know that the penalty won't hurt their ranking, and so they will continue to show the bad experience regardless? That's just as bad as them not penalizing themselves for the full page ad.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#194

Post by pdappollonio »

nailer wrote: post #167
jtreminio wrote: post #162

Earlier quoted context omitted.

> You can pretty much say Yahoo actually "put herself above others" Do you mean `itself`? Since when are tech companies assigned genders?

Parent poster might not be from an English-speaking background.

This. I would've written the same by mistake.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#195

Post by girvo »

ryanlol wrote: post #149
yeukhon wrote: post #143

Earlier quoted context omitted.

No. Obviously less is wrong. Here is an example: login over HTTP deliberate because the site doesn't support HTTPS is definitely not less sensitive.

Of course, but there's a general expectation that stuff served over HTTP isn't sensitive. Breaking HTTPS where it's deliberately used is something that certainly deserves a warning.

> Of course, but there's a general expectation that stuff served over HTTP isn't sensitive.

For us, sure. For the other 95% of the population, not really, which is why Google is doing this

Re: Google Will Soon Shame All Websites That Are Unencrypted

#196

Post by arikrak »

siquick wrote: post #137

I used Cloudflare's free SSL - is this enough? https://www.soundshelter.net

Yes. Google can't know what happens between Cloudflare and your server. (Communication there is also less likely to be intercepted as between the user's browser and the internet.)

Re: Google Will Soon Shame All Websites That Are Unencrypted

#197

Post by icebraining »

wbillingsley wrote: post #87

Surely it could be a lot easier... Everyone already has a known public third party authority -- their domain registrar. Surely the browsers could come up with some protocol where you generate your own keypair, register the public key with the registrar and keep the private key on the server. Then it could work pretty much like SSH, but with the browser doing out-of-band public key checking. Rather than needing a cert…

So the browsers need to do a secure request to a server of a registrar for each connection? Even assuming you cache the result, latency has just been shot. And what if those servers are down, or slow, or under DoS attack? And what about EV certs?

Re: Google Will Soon Shame All Websites That Are Unencrypted

#198

Post by incompatible »

donohoe wrote: post #64

Which is hilarious because the reason I can't switch The New Yorker website to HTTPS is because of ads - which I'm getting from Google DFP which allows non-secure ad assets. In short; Google will penalize me because I use Google. The universe has a sense of humor.

I have a page hosted on Google Sites. It seems that Google Sites doesn't support HTTPS on custom domains either.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#199

Post by nandhp »

afarrell wrote: post #144

There are occasionally times when I want to suffer a MITM attack. For example, when I am on an airplane, at a hotel, or basically any other time I have to fill out a webform to get online. Perhaps those forms should not exist, but until they don't, I hope http://xkcd.com continues to work.

To clarify, you don't want to suffer an MITM attack; that's just the current standard way of finding the captive portal login page. I believe the Wi-Fi Alliance is working on Hotspot 2.0 (Passpoint) to fix this problem:

http://www.theruckusroom.net/2014/10/hotspots-get-hotter-wit...

Briefly, it looks like there's a secure (WPA2) hotspot for internet access and an associated open hotspot if you need to sign up for an account (with a published signup URL).

Re: Google Will Soon Shame All Websites That Are Unencrypted

#200

Post by coder-otherstuf »

While I am a fan of HTTPS everywhere, there are just some use cases that are not feasible for HTTPS.

One edge case I am familiar with is a case where a webapp is used to setup a headless device (like a wireless repeater or hub for example). In this scenario, a user loads the page from a web server, the page instructs the user to put the device in a mode that it acts as a WiFi access point, the user then changes the access point of their machine, the page can now make AJAX requests to the device access point which is also acting as a server allowing the user to POST things like WiFi credentials for the device to use.

In this edge case one of two things need to happen, either the original page must be served as HTTP since no CA will issue you a cert that can be served by such a device. Or the device must act as more than a simple API server and would have to serve HTML pages which would get linked to by the original page. While the second solution is fine to get HTTPS everywhere (with the exception of while connected to the device), it means that the development and improvement of setup UI is tied to device firmware updates as opposed to speed and flexibility of web development.

Post reply on HN