Earlier quoted context omitted.
And what if I don't trust any of the "MAJOR SPONSORS".
You don't trust the EFF?
I do not, and I do not like them either. They are a liberal lobby.
Deprecating Non-Secure HTTP
161–170 of 318 posts
Re: Deprecating Non-Secure HTTP
#162Earlier quoted context omitted.
That's just FUD. Nobody is planning to block plain HTTP requests altogether. You can still put up a website on any computer and serve it over plain HTTP, and it will render correctly on most browsers. The plan is to disable some of the "more dangerous" features when the page is requested over HTTP, in order to entice webmasters to adopt SSL. The list hasn't even been written yet, but I'm guessing that most of those f…
This is not true. The suggestion is that essentially all new features will require https. You are effectively blocking http if I can't do anything interesting with it.
The proposal says:
> That would allow things like CSS and other rendering features to still be used by insecure websites ... [but] restrict qualitatively new features, such as access to new hardware capabilities ... [like] persistent permissions for camera and microphone access
If accessing my camera over an insecure connection is your definition of doing interesting things, I would be happy to block you.
In fact, I can't think of a single proposed addition to the current web stack that would be safe to use over an insecure connection.
You have every right to express your views using a static document and stylesheet. But anything beyond that tends to involve executing your code on my computer, and nobody has any obligation to let you do that, especially over an insecure connection. Requiring people to make some additional effort before they can access other people's property sounds like a nice balance of rights and obligations to me.
Re: Deprecating Non-Secure HTTP
#163So SSL on localhost? That seems a bit over the top? Can we then assume that all browsers will include a trusted CA/cert for localhost? That doesn't work with eg: ssh tunnels? Or will we need "developer" browsers and "app" browsers to work with localhost? Either for test/dev or for deploying "apps" with nodejs etc?
I'm not sure if considering localhost to be secure/"encrypted" (access to all features) would be a good or bad idea...
Re: Deprecating Non-Secure HTTP
#164As someone who participated in the referenced discussion and on HN, I have to say I am very happy with this outcome. Seems like reason has won. Now, if Google follows Mozilla's example, we might actually be able to pull this off.
Re: Deprecating Non-Secure HTTP
#165Earlier quoted context omitted.
This is not true. The suggestion is that essentially all new features will require https. You are effectively blocking http if I can't do anything interesting with it.
The proposal says: > That would allow things like CSS and other rendering features to still be used by insecure websites ... [but] restrict qualitatively new features, such as access to new hardware capabilities ... [like] persistent permissions for camera and microphone access If accessing my camera over an insecure connection is your definition of doing interesting things, I would be happy to block you. In fact, I…
You changed your opinion quickly. Previously you said:
> The plan is to disable some of the "more dangerous" features when the page is requested over HTTP
And now you're saying that every new feature falls into this category.
Listen, I'm all for going all-in on SSL. What I'm not for is doing until SSL is as seamless and inexpensive as HTTP.
What really concerns me is that the https-only nazis do not share this concern. It's never mentioned in their blog posts.
It actually really scares me that something that has been so important for making the web as powerful for the cause of freedom is not even on the radar of the people who are controlling the direction of the web.
Re: Deprecating Non-Secure HTTP
#166Earlier quoted context omitted.
And what about testing small applications on remote servers like "dev.my-personal-site.com"? I don't want to pay $15 for an SSL certificate and 15 minutes of my time just so I can get my dumb lunch break tetris HTML app running on the machine I SSH into from my tablet.
Google and Mozilla do not care about this use case. Full stop. Do. Not. Care.
No, they just assume quite reasonably that those people can install their own certificates on their client, too.
Re: Deprecating Non-Secure HTTP
#167I should be happy about this -- who wouldn't want the entire web to be encrypted -- but SSL is so broken for normal people. SSL is expensive (wildcard certificates run $70 a year and up), confusing (how does one pick between the 200 different companies selling certificates?), and incredibly difficult to set up (what order should I cat the certificate pieces in again?). If SSL doesn't change, this move will cut the li…
Can someone explain why we can't give SSL certificates along with domain registration? We already trust the DNS, don't we?
Re: Deprecating Non-Secure HTTP
#168Earlier quoted context omitted.
It just takes a tiny cost to turn off bright 10 year olds from experimenting.
Cloudflare's free plan has SSL now, which a 10 year could utilize. While that opens up a potential MITM attack, I don't believe it's worse than having no SSL at all (others argue it is, on the premise that it creates a false sense of security).
Amateur web development shouldn't depend on having an account with a 3rd party service which can arbitrarily decide whether or not to sign your cert.
Re: Deprecating Non-Secure HTTP
#169If things like "python -m SimpleHttpServer" don't work then developers will switch browsers. I don't think anyone is seriously considering what it will take to migrate the long tail of development tools that use HTTP on localhost.
Has Mozilla indicated whether HTTP2 connections with opportunistic encryption will get access to secure-site features? If so, then SimpleHttpServer could be updated to use HTTP2+oe.
Unless I missed something, opportunistic encryption isn't part of the HTTP2 standard.
Re: Deprecating Non-Secure HTTP
#170Earlier quoted context omitted.
The proposal says: > That would allow things like CSS and other rendering features to still be used by insecure websites ... [but] restrict qualitatively new features, such as access to new hardware capabilities ... [like] persistent permissions for camera and microphone access If accessing my camera over an insecure connection is your definition of doing interesting things, I would be happy to block you. In fact, I…
You changed your opinion quickly. Previously you said: > The plan is to disable some of the "more dangerous" features when the page is requested over HTTP And now you're saying that every new feature falls into this category. Listen, I'm all for going all-in on SSL. What I'm not for is doing until SSL is as seamless and inexpensive as HTTP. What really concerns me is that the https-only nazis do not share this concer…
No, I didn't change my opinion. I just clarified what I meant by "more dangerous", and IMO everything that involves javascript or access to surveillance hardware (camera, microphone, GPS, etc.) qualifies as dangerous.
My fundamental disagreement with you is that I don't think we can wait until "SSL is as seamless and inexpensive as HTTP". That will never happen unless we can pose a credible threat to the profit margins of web hosts and CAs. And sending a horde of unsatisfied customers in their general direction is one of the most effective ways to pose such a threat.