Live data from Hacker News

Google Will Soon Shame All Websites That Are Unencrypted

motherboard.vice.com

311–320 of 369 posts

Re: Google Will Soon Shame All Websites That Are Unencrypted

#311
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'm jealous that you get to work for the New Yorker website. Any openings?

http://condenast.avature.net/careers/SearchJobsTechnology

Re: Google Will Soon Shame All Websites That Are Unencrypted

#312

Consider this: - Squarespace doesn't support SSL (other than on their ecommerce checkout pages) [1] - Weebly only allows it on their $25/mo business plan [2] - Wordpress.com doesn't support SSL for sites with custom domains [3] - 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…

Then maybe those platforms will finally implement it. In any case, there's an alternative: putting Cloudflare in front of the site. In fact, Google shows me a guide to do so when I search for "squarespace ssl". Of course, that's hardly as secure as end-to-end HTTPS, but still, I trust the path between CF and SquareSpace much more than between the user's browser and SquareSpace.

I wonder how it's even allowed for CF to do this. "your site" CF clients is a poor solution and it only hides that the connection is actually not secure. Isn't this a misuse of many CA's TOS and should result in certificate revocation? Maybe I'm wrong though.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#313
post #32
post #23

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? Seriously though. If secure is the default from now on, why can't it actually be the default?

Isn't that what Let's Encrypt is aiming for? Install a package, which configures a cronjob for you? https://letsencrypt.org/howitworks/ Which could just even become a default but optional dependency of your distro's web server package, or part of your Docker container, or whatever.

Let's Encrypt is awesome but you still need to have root access to the machine. I host my stuff on a shared 1&1 node and I can't seem to find any way to add SSL to my websites without having to pay them.

(Yes I should move to another host but that is too much hassle for me right now.)

Re: Google Will Soon Shame All Websites That Are Unencrypted

#314
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.

That is interesting. The Ads team is the same group that recommended turning off Transport Security in iOS 9 so you can run your Google's unencrypted Ads stack[1]. I'm sure there are two different departments that are fighting two totally separate wars. I've definitely seen this pattern in huge companies where one team is trying to push an agenda that forces another team to reshuffle their priorities.

[1] - http://googleadsdeveloper.blogspot.com/2015/08/handling-app-...

Re: Google Will Soon Shame All Websites That Are Unencrypted

#315
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.

It is really hard for DFP to not allow non-secure creatives as long as you can create 3rd-party creatives. They do try to detect non-secure assets though, so they won't run on secure pages. See: https://support.google.com/dfp_premium/answer/4515432?hl=en

Re: Google Will Soon Shame All Websites That Are Unencrypted

#316
post #286
post #244

Earlier quoted context omitted.

I never thought about the question of whether, in languages that require nouns to have grammatical gender, particular countries may have a different grammatical gender from others, but on reflection I already know examples where they do in Portuguese: o Brasil, o Canadá (amusing to me because of the national anthem), but a Argentina, a Alemanha. I wonder if this also happens in German; the only examples I'm thinking…

Apparently Iraq, Iran, Yemen, the Congo, Lebanon, and Chad are masculine in German: https://german.yabla.com/lessons.php?lesson_id=409

Actually I can't think of many cases where German would use pronouns with countries. The reason these are masculine is because they are typically referred to using a definitive pronoun (literally "the Iraq", "the Iran", etc). It's more common with names of regions -- which may indicate that these countries used to be mere geographical regions (rather than sovereign nations) when the names entered the German language.

It also happens with countries like the UK, the US, the Czech Republic and so on, but obviously for the same reasons as in English.

I can't actually think of a country that's feminine in German. The "die" you often see is actually indicating plural (e.g. "die vereinigten Staaten", the United States; or "die Niederlande", "the Netherlands").

Re: Google Will Soon Shame All Websites That Are Unencrypted

#317

Earlier quoted context omitted.

But if you have a child company, wouldn't you expect to associate the parent company with a feminine gender before a masculine gender? That's what I am getting at. An organization has that "motherland" feel in some way.

Not really, no. Motherland is a very specific term that's been ingrained into English most likely because of the close personal relationship between people and their native countries, which would have been Britannia for many English speakers when the language was developing. There isn't really that same deep and universal connection when talking about organizations, so a similar term probably wouldn't develop anytime…

Sure, but what about ships? If you've read any sci-fi, the term "mothership" should spring to your mind. Or "motherboard" in hardware.

The concept of "some larger entity that spawns smaller entities" seems to generally lend itself to the mother/daughter terminology if you want to be poetic about it.

That said, whatever happened to artistic liberties?

Re: Google Will Soon Shame All Websites That Are Unencrypted

#318

Earlier quoted context omitted.

I am not, sort of. You can refer to a country by "she", so why is it inappropriate for a company? I don't see any issues. You can view a company as a mother too.

That's an archaic and half-valid use, so stretching it to apply to a company makes it pretty much invalid. You could try to convince people to use the word that way, but at present it's just not done. Companies are 'it' or you can talk about the people that make up the company as 'they'.

If you try to dictate how language must be used you're just being ignorant of how she constantly evolves through her use by different speakers.

So, there.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#319

Earlier quoted context omitted.

Then maybe those platforms will finally implement it. In any case, there's an alternative: putting Cloudflare in front of the site. In fact, Google shows me a guide to do so when I search for "squarespace ssl". Of course, that's hardly as secure as end-to-end HTTPS, but still, I trust the path between CF and SquareSpace much more than between the user's browser and SquareSpace.

I wonder how it's even allowed for CF to do this. "your site" CF clients is a poor solution and it only hides that the connection is actually not secure. Isn't this a misuse of many CA's TOS and should result in certificate revocation? Maybe I'm wrong though.

Well, at least for several threat models, "your site to CF" is at least slightly better than "CF to clients". It's not vulnerable to things like unsecured wi-fi sniffing. Then again, neither are self-signed certs and for some reason all browsers consider them even worse than no cert.

On the other hand, it doesn't protect against government spying, but then again, I think some governments straight-up MitM HTTPS traffic anyway. For instance:

https://news.ycombinator.com/item?id=10663843

Re: Google Will Soon Shame All Websites That Are Unencrypted

#320

The article title really, really 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. Nevertheless, quite convincing security arguments aside, I feel this also has a very authoritarian si…

Blockchain technology (which powers the Bitcoin) can easily be used to replace CAs, or provide an alternative which browsers acknowledge, provided enough site owners use it.

And going by the high issuance/maintenance fee the CAs charge for issuing certificates, the industry is a sitting duck for disruption by a Blockchain DNS/CA app.

I, as a site owner, can just sign my 'certificate' myself and put it on the blockchain DNS/CA app. The certificate will have my domain name, public key. And slso an additional field 'ownership sign' which is something like https:// domain>.com/ownership_sign.pem (which is signed by my private key).

So if I am the true owner, I can self issue as many certificates to myself as I please. Or there could be some forced limitation to prevent any scalability (cough) challenges.

So, the problem you have pointed out is not really with enforcing/encouraging HTTPS, but with the entrenched CA bureaucracy. And I am really surprised, why is it not being disrupted already?

Post reply on HN