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.<p>In short; Google will penalize me because I use Google.<p>The universe has a sense of humor.
The article title really, <i>really</i> needs an extra word: "Chrome", between "Google" and "Will". At first glance I thought it would be about the search engine, which would be a very disturbing thought indeed; it's already hard enough to find the older, highly informative and friendly sites --- which often are plain HTTP.<p>Nevertheless, quite convincing security arguments aside, I feel this also has a very authoritarian side to it: they are effectively saying that your site, if it is not given a "stamp of approval" by having a certificate signed by some central group of authorities, is worthless. Since CAs also have the power to revoke certificates, enforced HTTPS makes it easier to censor, control, and manipulate what content on the Web users can access, which I certainly am highly opposed to. I can see the use-case for site like banks' and other institutions which are already centralised, but I don't think such control over the Web in general should be given to these certificate authorities.<p>With plain HTTP, content can be MITM'd and there won't be much privacy, but it seems to me that getting a CA to revoke a certificate is much easier than trying to block a site (or sites) by other means, and once HTTPS is enforced strongly by browsers, would be a very effective means of censorship. Thus I find it ironic that the article mentions "repressive government" and "censor information" --- HTTPS conceivably gives <i>more</i> power to the former to do the latter, and this is very much not the "open web" but the centralised, closed web that needs approval from authorities for people to publish their content in.<p>There's a clear freedom/security tradeoff here, and given what CAs and other institutions in a position of trust have done in the past with their power, I'm not so convinced the security is worth giving up that freedom after all...
Consider this:<p>- Squarespace doesn't support SSL (other than on their ecommerce checkout pages) [1]<p>- Weebly only allows it on their $25/mo business plan [2]<p>- Wordpress.com doesn't support SSL for sites with custom domains [3]<p>- If you've never experienced the process of requesting, purchasing, and then installing an SSL certificate using a hosting control panel like Plesk or cPanel, let me tell you–it's a nightmare.<p>All that to say, this is an interesting development that will leave a large % of small business websites with a red mark in their browser.<p>[1] <a href="https://support.squarespace.com/hc/en-us/articles/205815898-Does-Squarespace-support-SSL-access-" rel="nofollow">https://support.squarespace.com/hc/en-us/articles/205815898-...</a><p>[2] <a href="http://www.weebly.com/pricing" rel="nofollow">http://www.weebly.com/pricing</a><p>[3] <a href="https://en.forums.wordpress.com/topic/support-for-https-for-custom-domain" rel="nofollow">https://en.forums.wordpress.com/topic/support-for-https-for-...</a>
This is how it always should have been.<p>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.<p>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.<p>Even phishing sites should be DV secure.
Sounds good. I wonder when Google Cloud Storage will start supporting https on static websites hosted through them:<p><a href="https://cloud.google.com/storage/docs/website-configuration?hl=en" rel="nofollow">https://cloud.google.com/storage/docs/website-configuration?...</a><p>If they don't then they're not keeping up with hosting on Amazon's S3, which does support it.
Google should offer stupid SSL certificates either for free or for $1/yr.<p>Perhaps at least to customers of Google domains. I won't mind switching from namecheap to Google domain in latter case.
In the hopes that it will help spread adoption of HTTPS, I wrote a web server that serves your sites over HTTPS by default, using Let's Encrypt: <a href="https://caddyserver.com" rel="nofollow">https://caddyserver.com</a> - It also redirects HTTP -> HTTPS.[1]<p>There's a lot of misinformation out there about certificates and HTTPS, but don't let it stop you from encrypting your site. Regardless of Google's move, there is no excuse for any site not to be served encrypted anymore.<p>[1] Here's a 30s demo: <a href="https://www.youtube.com/watch?v=nk4EWHvvZtI" rel="nofollow">https://www.youtube.com/watch?v=nk4EWHvvZtI</a>
Why 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?<p>Seriously though. If secure is the default from now on, why can't it actually be the default?
Is there a strategic business reason for this on Google's part other than a safer web is better for all? I don't doubt that a more secure web is better for everyone, I'm just more curious about the business drivers of this from their perspective.<p>The reason I'm wondering is because with AMP, there seems to be a clear strategic benefit from having all of that ad serving data running through them even if the advertisers and publishers are not using the DoubleClick stack or Google Analytics.<p>By bringing this to market from the standpoint of "improving" the mess publishers have brought upon themselves and speeding everything up, there's definitely a clear win for consumers here. That said, it leaves the door open for something similar to mobilepocolypse where Google updated their ranking signals on mobile to significantly favor mobile-friendly sites. I could easily see this going a similar route where it is a suggestion...until its not because if you don't implement it you'll lose rankings and revenue (and coincidentally feed Google all of your ad serving data in the process).<p>To be clear, I don't knock them for taking this approach, because if it works it is a very smart business move that will be beneficial to a lot of parties (not just Google). Just looking for other insights into the business strategy behind something like pushing for encryption, and AMP.
For Google, it’s not just about providing a secure environment and secure websites. In fact, Google actually has a monetary incentive to get as many websites to move over to HTTPs as possible: convincing website owners to move to HTTPs will help get rid of competing ad networks.
I 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.<p>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 HTTPS at all and would just as likely ignore it as anything. The only people that would see and understand this new red X for what it represents would know that it doesn't really matter that the lolcat meme they just downloaded came through an unsecured channel.
Main problem still is Google: They consider HTTPS and HTTP links the same. When switching a site to HTTPS you lose all your incoming links. Redirects only transfer a small amount of juice. You're toast.<p>We tried migrating several times to HTTPS only, every time got a huge penalty from Google.<p>So Google is the main driver for HTTP websites.
Just enabled Chrome to show the little crosses by default for <a href="http://" rel="nofollow">http://</a> and I already like having this showing. If you wish to be an early adopter go to:<p>chrome://flags/#mark-non-secure-as<p>It is good to see how sites that matter are mostly <a href="https://" rel="nofollow">https://</a> already for me. The <a href="http://" rel="nofollow">http://</a> tabs I have open such as this article actually are insecure when you think about the amount of trackers on them, so the 'x' is very apt.
They should do something useful for the web and remove most if not all the current root certificates. There are so many places that have what is essentially a master key to the internet - and that master key is only going to be more important as more and more sites become SSL.
All of this raises the question: why does the new default state require action, while the non-default state requires none?<p>Is that more or less bass-ackwards?
Should static content be encrypted over https? I think it's fair for chrome to call out with an x as I've literally seen local lunch joints take orders with credit card info over http but to serve mostly static pages like the new yorker over http only means that the user's privacy is compromised in that people can see what you're reading - does that warrant down ranking searches? I'm just curious - I work mostly on platforms so I'm not too aware of all of the incentives for trying to move everyone to https as it's not my problem domain necessarily.
How will this impact page-speed?<p>I recall switching the product pages of an e-comm site, which had up to 50 small images per page, from https to http and the change very significantly increased page load speed for the end user
Several weeks ago I have installed certificate to my web site on NGINX and it wasn't hard. It was fun to do. Also I got A+ from Qualys SSL Labs. What I mean is it is easy to deploy an HTTPS site.
HTTP + HTTPS is fine<p>HTTPS for SaaS and e-commerce web apps is fine<p>HTTP for normal websites is okay (for me, I have no hidden agenda)<p>HTTPS-only for normal websites is silly, why not offer HTTP too? Every request is unique, no internet anonymity.
While I am a fan of HTTPS everywhere, there are just some use cases that are not feasible for HTTPS.<p>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.<p>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.
Surely it could be a lot easier...<p>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.<p>Then it could work pretty much like SSH, but with the browser doing out-of-band public key checking. Rather than needing a certificate chain, the browser just checks the server's public key matches the published one. If ok, happy to encrypt. If not, wave flags, and yell "spoof".<p>Verifying the registrar isn't a fly-by-night can be as complicated as needs be, but that way the registrar (who already gets paid to register the domain) does the complex hassle, while the ordinary domain-buyer just has to keep their server's public key up-to-date with the registrar (ie, fill in one web form at the time you register the domain or whenever you change the server key).<p>But alas it is not so at the moment. Instead, the current process puts hassle onto millions of individual domain-owners, while keeping life easy for the few (paid) certifying authorities. And then we wonder why so few people want to do it.
I feel a bit of dissonance on hn on the issue of https. On issues of surveillance and spying the responses are often measured and there is generally a balanced debate, and yet on ssl suddenly its a matter of extreme urgency with strident positions backed up by references to mitm, spying and isp injected ads.<p>This is not as urgent a matter as some here tend to make it, better to resolve it properly than rush into half baked solutions like Google shaming websites. Why should a private company have the ability to shame websites and drive decisions a certain direction without any consultative process and accountability. Surely these are decisions for industry groups and wide consensus, and not individual corporates driven by self interest.<p>Corporates routinely mitm ssl traffic and no one is shaming them or the equipment makers for that, so ssl and mitm is hardly going to be problem for state actors. For protection against less influential actors, banks and those who process sensitive data have been on https for a long time now so where is this urgency and the need to take action coming from?<p>Everyone agrees security is good but the mechanism to enable this cannot be given up to browser makers and CAs. This is a complete loss of end user control and a significant step back from the open net that cannot just be brushed aside.<p>Not everyone needs https and for ads injections the pressure should be on ISPs to stop the illegal behavior. Why can't we shame ISPs instead of forcing all websites to https?<p>Other solutions like signing content that empowers individuals rather than corporates and vested interests should be explored. The same browser makers went ahead and arbitrarily started flashing grave warnings on self signed certs without any consultative process or accountability.
Why don't I like this?<p>I don't think it's HTTPS.... I think I don't like that one company has this much power over the web.<p>This seems awfully familiar...
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 <a href="http://xkcd.com" rel="nofollow">http://xkcd.com</a> continues to work.
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.
Yes, shame all libraries/swimming pools giving their schedule online without HTTPS. Shame gutenberg project, the documentations for OS, code, your washing machine.<p>Why would money from libraries gutenberg project, NGOs informations go to more expansive OPEX for web hosting when an information is clearly designed and OK to be public?<p>And does not require adds or payment.<p>Google has some <i>godwin point</i> very authoritative views on the internet and the protocols that make me dislike them.<p>Especially that their business model it is to not pay transit for distributing their contents. Basically every fucking internet users pay the 95th percentile transit to google products even if they don't watch videos on youtube, don't use gmail or else.<p>These people are like ... catholic priests. Do as I say, not as I act and be good members of the community.
So what would this mean for web development agencies and the likes, who've made hundreds of thousands of websites (most without SSL) and would now be forced to convert them all to use https?<p>How many clients would be willing to pay to cover some of the time wasted doing that?<p>And how about the potential SEO impact? I mean, Google says switching to https shouldn't affect things, but I've seen tons of sites lose rankings after a change.<p>Okay, using https is a good thing and all, but the inconvenience caused by having to make this change could be massive.
It's very surprising that Google doesn't sell certificates on Google Domains or offer any ssl support in GCE storage stack and yet they are going so strong after web encryption.
What about setting an example ?
Sounds good to me, thanks to Let's Encrypt. All my personal sites are now on https and HTTP/2 (thanks to Go 1.6). I don't use ads so I have nothing blocking me from https.<p>The only situation where I still want to use HTTP is one page I serve, which uses websockets, and I don't want to use secure websockets, but that's the only exception.<p>I'm glad to be in this boat. Once again, it's mostly thanks to Let's Encrypt being awesome, and I'm thankful to it.
Cue 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 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.
My website runs on a vps with NodeJS as the backend. I could easily self sign a certificate but chrome displays a huge warning to users. How about signing certificates for free google. Https is easy to implement but the fact that it costs is bs.
"mark non-secure origins as non-secure." The name of that option seems to be chosen to apply a bit of pressure to anyone who sees it. Nothing wrong with that of course - it's our existing habits of trusting HTTP that are strange.
I think 80% of web sites will be labelled as red-unsafe.<p>SSL layer security is good but sometimes a certificate is expensive and not free. Suppose that you have 10 domains and not all of them are for SNS, banks and etc..<p>At what minimum cost will you purchase a HTTPS certificate?
<a href="https://news.ycombinator.com/item?id=5238164" rel="nofollow">https://news.ycombinator.com/item?id=5238164</a><p>Still not solved... calm down Google!
I used Cloudflare's free SSL - is this enough?<p><a href="https://www.soundshelter.net" rel="nofollow">https://www.soundshelter.net</a>
Yeah. Still not paying for a cert on my person home-pages just so I can have my own page come up first when people google my (worldwide unique) name.<p>That page contains static HTML and does not need SSL, and it's not "insecure" just because you may be on a network which MITMs traffic. That makes <i>your network</i> insecure, not my page.<p>So yeah. Not interesting. Not worth it.
HN could do its part: for example, start marking all <a href="http://" rel="nofollow">http://</a> links red. For our content sites, we can also announce to users this change and roll something out.
Basically efficient, low-latency caching for html and css content is over unless there's SRI for them. It makes sense to have a mini webpage delivered securely that lists hashes for all static assets, and then serve some static assets insecurely to take advantage of CDNs as long as they don't disclose individual app actions (assets everyone sees on many pages). The downside is the balancing of risk for activity leakage based on insecure assets. Of course, some dynamic content and sensitive state needs to remain secure. The issue is that securing everything depends on whether you're willing to trust your CDNs and caches with your certs and private keys (granted, you already trust them to display the correct content.). That sort of technical risk management needs to be considered carefully if insecure assets can dramatically speed up UX (because TLS sessions take some or a lot more work... since how would the browser and backends do session caching or pipelining across infrastructures and providers that likely have multiple IPs? One connection per provider, each keeping their own cache for their HA boxes?)<p>Maybe there needs to be an insecure HEAD or CACHE open standard to check content freshness of a secure page via crypto hash (say canonical uri, etag and last modified) to avoid building up a full TLS session to see nothing's changed?