Slashdot Mirror
Google Proposes To Warn People About Non-SSL Web Sites
mrspoonsi writes The proposal was made by the Google developers working on the search firm's Chrome browser. The proposal to mark HTTP connections as non-secure was made in a message posted to the Chrome development website by Google engineers working on the firm's browser. If implemented, the developers wrote, the change would mean that a warning would pop-up when people visited a site that used only HTTP to notify them that such a connection "provides no data security". Currently only about 33% of websites use HTTPS, according to statistics gathered by the Trustworthy Internet Movement which monitors the way sites use more secure browsing technologies. In addition, since September Google has prioritised HTTPS sites in its search rankings.
Really Why? what content on Slashdot justify's the need for encrypted content? I really don't get this huge push for SSL everywhere. give me SSL when I need it, I don't want SSL for accessing a forum or a news site or just generally browsing the web.
Yep, same here.
On topic, Google, I appreciate the focus on security, but stop deciding to simply implement however YOU THINK the web should be working. Ok, technically, it's just a change in the browser, but the semantics are obviously meant to "encourage" everyone to switch to HTTPS. However a good idea some of us think that is, it's not up to you.
This is why people are getting freaked out about the power you hold. You're starting to demonstrate that you're not afraid to *use* that influence to simply push things to work however you want them to. You've already done that once already by pushing forward an SSL-related change far ahead of when it really needed to be, and now it looks like you're floating a trial balloon to go one step further.
Am I overreacting here? Or is Google going too far, too fast with this?
Irony: Agile development has too much intertia to be abandoned now.
Currently only about 33% of websites use HTTPS, according to statistics gathered by the Trustworthy Internet Movement which monitors the way sites use more secure browsing technologies. In addition, since September Google has prioritised HTTPS sites in its search rankings.
Um... Secure != Trustworthy and, seriously, most web connections DO NOT NEED to be HTTPS.
Furthermore, I cannot filter HTTPS via my proxy filter (Proxomitron) to strip out annoying things, like the fucking Google sidebar and other forced "user experience" settings - which is why I use nosslsearch.google.com ...
It must have been something you assimilated. . . .
It also increases costs and management overhead.
Does Fred Bloggs lyrics site need to be SSL? Probably not. But throwing a warning up is going to cause fear, uncertainty and doubt.
It's not nuts. It's sly. What they're trying to do here is force increased purchasing of SSL certificates from third parties. It's about profit and the wealthy and powerful scratching each other's backs. Sure, you can put in your own, but the the browsers will all put up scare dialogs about how they don't know who issued the cert, and away go your visitors / customers.
Do you NEED to have SSL for your blog? For your comic strip? For your aquarium how-to pages? For your archive of 50's pinups? For your CGI that calculates pixels-per-planet for specific lens magnifications and sensor densities? Doubtful. Well, they're looking to change that. It'll be SSL or no visitors, and the web gets hooked even further into the pockets of commercial interests, while the cost of entry slowly inches away from the poor.
Coincidence? Hardly.
Google's pissing directly on your heads here and trying to tell you it's rain.
Encryption has a cost, it isn't free. ... This is a dumb idea. A very dumb idea.
Agreed. For most sites, there are only two areas where I care about encryption: 1) login authentication and 2) session tokens (cookies). For #1, briefly switching to SSL/TLS is no big deal.
The problem today is that there is no satisfactory solution for #2. In order to encrypt your cookies in your HTTP header, you have to encrypt everything. As previously mentioned, this can have some adverse side effects. It is also complete overkill. What HTTP needs is a middle option.
Enter explicit HTTPS.
When a client requests a protected URL, it can be given a challenge and negotiation method for TLS not unlike how NTLM authentication over HTTP occurs. It should also negotiate what HTTP headers should be private. When complete, the client then sends encrypted data using a PROT: [session id] [base-64 payload] header. If you wanted to be fancy, you could make the system tolerant of upstream proxies or load-balancers inserting their own cookies.
Now you have a system where your session tokens cannot be eavesdropped upon, but yet the payload of the HTTP request can be cached.