If 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.
Deprecating Non-Secure HTTP
31–40 of 318 posts
Re: Deprecating Non-Secure HTTP
#32I agree with trying to phase out HTTP, but I think their method is "annoying." What do features have to do with HTTP Vs. HTTPS? It just seems like an arbitrary punishment. Wouldn't it just be significantly easier to simply change the URL art style to make clear that HTTP is "insecure." Like a red broken padlock on every HTTP page? That has the following advantages: - HTTP remains fully working for internal/developmen…
The actions Mozilla proposes sound awful. I believe that a secure (from the NSA) Internet is the way forward. But this seems so goofy to me. There are legitimate reasons for a site not to be hosted on HTTPS.
* It is a static site with no forms or logins
* It is non-critical info
* The site operator can't afford a certificate (Let's Encrypt is only one site...)
Re: Deprecating Non-Secure HTTP
#33I agree with trying to phase out HTTP, but I think their method is "annoying." What do features have to do with HTTP Vs. HTTPS? It just seems like an arbitrary punishment. Wouldn't it just be significantly easier to simply change the URL art style to make clear that HTTP is "insecure." Like a red broken padlock on every HTTP page? That has the following advantages: - HTTP remains fully working for internal/developmen…
I can imagine a lot of personal sites will suffer from this. With most, they're sitting on something like Eleven2 or Dreamhost, who requires a dedicated IP for an SSL certificate, which the user then has to buy and figure out for himself (it's not trivial for the average "webmaster"), or buy the certificate from their host which is marked-up plenty.
Yes, the hosts could wildcard. Yes, there are other solutions out there. But for the average Joe who is blogging about his vacations and family? They're going to be completely lost.
Why don't shared hosts just wildcard? Shared certificate? Well, let's think about it... Charging ~$5/month/dedicated IP is a nice upsell, and getting $70 for an installed SSL cert that costs them $10 from their SSL cert reseller, that takes them 2 minutes to configure... That's a nice slice of pie. I'd take that bet any day.
Re: Deprecating Non-Secure HTTP
#34I agree with trying to phase out HTTP, but I think their method is "annoying." What do features have to do with HTTP Vs. HTTPS? It just seems like an arbitrary punishment. Wouldn't it just be significantly easier to simply change the URL art style to make clear that HTTP is "insecure." Like a red broken padlock on every HTTP page? That has the following advantages: - HTTP remains fully working for internal/developmen…
What features have to do with encryption is this. If a browser asks a user "Do you want http://example.com to be able to access your camera", what it is really asking is "Do you want http://example.com, anybody on your local network, state actors, anybody between you and example.com, people who can mess around with BGP and your DNS provider to be able to access your camera?". TLS mostly makes the first question more truthful.
Re: Deprecating Non-Secure HTTP
#35I'm very glad to see this. It's embarrassing to think that, just a few years ago, many major websites used HTTP for all but their login pages, and it took Firesheep to get them into gear. > For the first of these steps, the community will need to agree on a date, and a definition for what features are considered “new”. For example, one definition of “new” could be “features that cannot be polyfilled”. I hope that inc…
It's worth bearing in mind that in the beginning, https was a significant CPU overhead... Since 2004 or so, much less of one. And since around 2010 CPU is rarely the bottleneck for web applications.
I do find it interesting that someone starting out as a significant effort after 2010 would bother having a partially https site, with back and forth jumps for login. It seems to me like it's actually more work than just having it all https and flat.
Re: Deprecating Non-Secure HTTP
#36I agree with trying to phase out HTTP, but I think their method is "annoying." What do features have to do with HTTP Vs. HTTPS? It just seems like an arbitrary punishment. Wouldn't it just be significantly easier to simply change the URL art style to make clear that HTTP is "insecure." Like a red broken padlock on every HTTP page? That has the following advantages: - HTTP remains fully working for internal/developmen…
It sounds like this is mostly going to be focused on features that require user consent. The article gives the example of media devices (camera and microphone) but there are plenty of others: fullscreen API, geolocation, notifications, large amounts of offline storage, etc.
These capabilities are sensitive enough that you want to give users control over who is granted access. But if pages are being loaded over HTTP, the user can have no way of establishing the authenticity of the Javascript code they're granting permissions to.
Re: Deprecating Non-Secure HTTP
#37I 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…
Seriously, SSLs basically 2x the hosting cost for low end hosting packages. Not great for people running small websites.
SSL should be a universally available free resource. I expect that it will be in the near future. That said, it is still very cheap for small sites too:
$9 - $11 / year for perfectly good certs. Less than $1 per month is a small burden.
https://www.namecheap.com/security/ssl-certificates/domain-v...
Re: Deprecating Non-Secure HTTP
#38I 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…
Why this project: https://letsencrypt.org/ is so important. From the site: Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. Arriving Mid-2015
That's just one project, and it doesn't even exist yet.
The web is moving faster every day, apparently. I sure do hope that project will be all it's chalked up to be.
For example, I need IP-only certs for a new project I'm working on (waiting for DNS to propagate to all clients is too unreliable and slow). If letsencrypt doesn't do that... well then I'd have to hope real hard for a competent CA out there who has an automated process available that allows IP-only certs. And whatever their price, if companies start following Mozilla's lead too soon, I'll have to pay up.
The wording in the article is perhaps not so damning yet, but it's still making me uneasy that they put out this press release while there are currently ZERO viable solutions for this.
Re: Deprecating Non-Secure HTTP
#39For Tor and I2P hidden services, HTTPS is redundant so I don't really see the point in punishing people for things like this. Loopback sites are an obvious exception to the "HTTPS is better" rule as well.
[deleted]
Let me point you to the critical word, ok?
> For Tor and I2P _hidden services_
Re: Deprecating Non-Secure HTTP
#40Question: if I'm prototyping a webapp on my machine -- one that will ultimately run behind apache or nginx or an amazon load balancer or something -- can I still prototype it in my browser with new features enabled without getting a valid https setup running on my localhost?
Yes; localhost specifically counts as secure.
Hopefully they put in a whitelist option... (similar to IE's security zones)... so you can whitelist your development domains.. in the case of hostnames, or when you hit a local VM.
I agree with another comment that a red broken lock for HTTP connections would be a better approach.