I wonder if this will reduce malware that injects advertising into users' browser sessions. Seems like a win-win, but I don't trust Google at all. They want all private data un-encrypted and available for their own analysis/mining/auction when it comes to their own servers and services.
Google Will Soon Shame All Websites That Are Unencrypted
71–80 of 369 posts
Re: Google Will Soon Shame All Websites That Are Unencrypted
#72This is how it always should have been. It was mind boggling that mixed content was "insecure" but HTTP was "secure." HTTP is and always has been insecure and should be marked as such. I know there are a few people who will moan and groan about how overkill HTTPS is, but this isn't about banning HTTP it is just about reminding users that they shouldn't be entering sensitive information into a HTTP site. Even phishing…
Mixed content is insecure because of active content to be very honest. Most people don't care about passive, but of course, you can make some fake banner if you are able to MiTM. You'd like javascript coming from HTTPS rather than HTTP. HTTP itself is insecure but doesn't mean every website has to be over HTTPS. However, given HTTPS is cheaper to deploy it should be encouraged. Do I really need HTTPS to show an album of cat photos I share with the world? No. But I do anyway.
However, the biggest challenge is actually internal traffic are almost always over HTTP, and the reason is almost always "because self-signed cert is invalid." In some way this is okish since internal traffic is a darknet, but as we have proper toolset make Let's Encrypt available, more people should consider deploying full SSL support for internal traffic as well. At this point, the toolchain to actually make Let's Encrypt simple and useful is still, ugh, a little hackish. Cron job here and there. Sort of complicated process to get started...
Re: Google Will Soon Shame All Websites That Are Unencrypted
#73Why do we have to go through this whole SSL certificates thing and can't just have a simple, automatically secure, I-do-nothing-and-my-website-is-secure protocol? Seriously though. If secure is the default from now on, why can't it actually be the default?
If apache and nginx follow along the lines of Caddy[1], we might. [1] https://caddyserver.com/
I tried Caddy the other day and was pretty impressed. It's a single binary, it automatically installed a Let's Encrypt cert for itself and it had a bunch of other nice features.
I'm not going to switch production to it yet, but it's looking like it'll go on my home server pretty soon.
Re: Google Will Soon Shame All Websites That Are Unencrypted
#74Why do we have to go through this whole SSL certificates thing and can't just have a simple, automatically secure, I-do-nothing-and-my-website-is-secure protocol? Seriously though. If secure is the default from now on, why can't it actually be the default?
If apache and nginx follow along the lines of Caddy[1], we might. [1] https://caddyserver.com/
That's... impressive. I'm going to mess around with this over my weekend - thanks for sharing!
Re: Google Will Soon Shame All Websites That Are Unencrypted
#75This is how it always should have been. It was mind boggling that mixed content was "insecure" but HTTP was "secure." HTTP is and always has been insecure and should be marked as such. I know there are a few people who will moan and groan about how overkill HTTPS is, but this isn't about banning HTTP it is just about reminding users that they shouldn't be entering sensitive information into a HTTP site. Even phishing…
HTTP was never marked as secure.
Mixed content was marked insecure because there were assets on the page that might not be from where you think they were from. It was an indicator that the little https lock in the URL bar wasn't telling you the whole story.
Re: Google Will Soon Shame All Websites That Are Unencrypted
#76Which 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.
Similarly, Google claimed they would start penalizing websites that showed full-page ads for mobile apps instead of showing you the website. But every single time I try to get to Gmail, or Drive, or Calendar, or any Google service on the web using a mobile device, I'm shown a full page ad for a mobile app. Google has been doing this for years, and it seems like it's also been a year since they said they'd punish all sites that do that. But Gmail still turns up as #1 in search results for email, so does calendar, etc. It seems to me that they have whitelisted themselves and choose not to punish any Google property that breaks the Google rules, despite claiming to do so.
Edit: Typically, when a service tells me "no you can't use this service until you view a full page ad" I just give up and not bother continuing to the service. But the same is not true for Google. I reluctantly click through the full page ad every single time. It's incredibly annoying that I let them get away with this and still use the services. They are so outrageously arrogant about it and it bothers me greatly, but still, I don't change.
Edit 2:
Going to calendar.google.com: http://i.imgur.com/fNRhhYx.png
First results for searching 'calendar': http://i.imgur.com/l3A5Wlh.png
Re: Google Will Soon Shame All Websites That Are Unencrypted
#77I think it's pretty funny that on the HN front page right now is a NYTimes article from the company's Google beat reporter about how trying to interview Larry Page is "emasculating" and then this announcement is accompanied by an image "shaming" the NYTimes web site for being unencrypted. As to the feature itself, I don't think it's a big deal at all. We all know that the average internet denizen doesn't understand H…
I work for a SaaS company, we absolutely have customers who email us complaining about putting credit cards in a page served over http.
Certainly, and I would be one of them. I'm not saying nobody does care or that nobody should, only that enough people don't care enough to make this "red X of shame" that shameful, really.
Chrome and Firefox have both had to take extreme measures for very similar things, such as web sites using expired (or even unvalidated/spoofed) SSL certificates. Google even reported that using a giant red page with warning labels didn't stop people from clicking through!
Re: Google Will Soon Shame All Websites That Are Unencrypted
#78I think one of the big problems with unencrypted websites is shared hosting, who refuse to use SNI certificates (often because it would require upgrading their infrastructure). So users have to pay for a static IP which effectively doubles their hosting costs so most don't bother.
Re: Google Will Soon Shame All Websites That Are Unencrypted
#79Cue the sound of 100,000 static-hosted S3 bloggers grabbing their free Amazon SSL cert and setting up CloudFront. And man that AWS console sure is wonky.
I tried setting up SSL with Cloudfront yesterday and it was a complete mess. The validation method is sending an email to the domain contacts as listed in whois. So if you have whois privacy enabled, you cannot receive the email and therefore cannot setup the cert.
This is definitely a bug, because the system supposed to also send emails to admin@domain.com, hostmaster@domain.com, and a few others. With whois privacy enabled, I never received any of those emails.
Even with whois privacy, you are supposed to be able to receive an email via the privacy registrar's proxy email... but Amazon parses it incorrectly and ends up sending the email to legal@whoisproxy.com
I'm not the only one:
https://forums.aws.amazon.com/thread.jspa?messageID=698280&t...
Re: Google Will Soon Shame All Websites That Are Unencrypted
#80Earlier quoted context omitted.
HTTPS does not kill referrer or referer headers. See https://referer.rustybrick.com/
..so why are all of the search terms suddenly gone from google searche referer headers? Which happened at the same time google defaulted to https?
At that time they started using horribly annoying redirects.