Slashdot Mirror
Concerns Over Google Modifying SSL Behavior
Lauren Weinstein writes "Google is handling SSL search queries on https://www.google.com/ in a manner significantly different than the standard, expected SSL end-to-end behavior — specifically relating to referer query data. These changes give the potential appearance of favoring sites that buy ads from Google. Regardless of the actual intentions, I do not believe that this appearance is in the best interests of Google in the long run."
Google passes Referer info from https to http how?
Please read TFA. The question is not over use of SSL, which the author of TFA "applauded."
You know, I'd be a lot more concerned about this kind of thing if we weren't hearing Slashdot stories crying wolf practically every day. I'm just not impressed with people trying to call Google evil anymore; none of these so-called revelations have panned out so far, so how likely is this one to go any differently?
I know exactly who the 'product' and who the 'consumer' of Google is.
Its irrelevant to this. When traffic is HTTP or HTTPS for Google searches, Google gets that traffic either way. When the traffic is HTTPS though, that means LESS people are getting it (wireless sniffing, routers along the way, etc.) in an unencrypted format. I really could care less what information the sites I go to are missing from the search I entered that brought me to them.
That's not the point at all. Frankly, this has only little to do with SSL.
The point is that if you pay for Google-ads, you will receive the referer-information, regardless of whether your site uses HTTPS or not, even when its breaks security for the user. If you don't pay you won't get the info.
Summary for the security conscious: since you switched to using https://encrypted.google.com months ago, you're fine, nothing new here. Move along.
Summary for the masses: Google is now using security by default (if you're logged in), but it isn't quite as secure as is possible.
I don't see why it's such a big problem.
Solutions/workarounds:
a) just don't click on the ads
b) block google ads from their search page.
Should be easy to do a) right?
If I am paying per click for certain search terms, then this data SHOULD be passed along. The other alternative is to just get a bill from google and trust that it is accurate?
As an advertiser I need this information. First to make sure I get the clicks google is charging for me, and more importantly to determine which words don't have a conversion rate worth paying for.
This is why you disable third party cookies, and use ad block plus and noscript.
Users have to be proactive about security. Nearly every fucking site out there is actively working against good security practices even when they're not compromised by an attacker. The browsers are all in a race to reach stupid version numbers, pass some arbitrary and ridiculously convoluted css benchmark, and enable javascript bloat by endlessly tweaking the performance of the js engine.
I hate referer information when I come from google, mostly because of sites that either:
1) Highlight my search terms in the page. You don't need to highlight every instance of 'of' in the page, and even highlighting the keywords is distracting.
2) Put a big fat "Welcome Google User!" (often with horribly colored letters for Google) that beg you to subscribe to the RSS feed.
I wish there was a chrome extension to hide referrer data just so that I could avoid that.
BTW: If you want an example of useless highlighting, google for VirtualBox and click on the VirtualBox website. I can't believe someone thought that people who can comprehend what VirtualBox is don't know how Ctrl+F works.
The right to protest the State is more sacred than the State.
First of all, any well-architected clustered app spends more time waiting for I/O at the web tier than it uses CPU, so the 2% "penalty" is on an underutilized resource anyway. Second, terminating SSL at your load balancers is standard practice, be they Amazon ELB SSL termination, F5 BigIPs, or reverse proxies. Again, all otherwise I/O-bound implementations which can spare the CPU.
The fact that SSL obscures the requested URI from intermediaries seems in-line with the goals of Wikipedia for free information sharing -- with SSL operating properly, an intermediary may be able to tell that you were on Wikipedia, but not what you were looking at.
SSL/TLS and/or its successors everywhere is in everyone's interest if maintaining privacy from ubiquitous snooping is a concern.