Google to default to SSL version for logged in users | Hacker News Reader

Google to default to SSL version for logged in users

googleblog.blogspot.com

236 pointscleverjake78 comments

Too bad Google is also preventing the rest of the web from also being secure as any AdSense-supported website can't have ads and SSL at the same time.

https://www.google.com/adsense/support/bin/answer.py?hl=en&#...

That's what I came here to say as well. The failure to provide an SSL version of AdSense is one of the biggest impediments to the implementation of SSL-only sites on the net currently. Until they fix that, they are not entirely serious about this.

This can't be said enough. Has Google even acknowledged this as a security issue?

I wonder how often this will be misused:

To utilize the NoSSLSearch option for your network, please configure the DNS entry for www.google.com to be a CNAME for nosslsearch.google.com. We will not serve SSL search results for requests that we receive on this hostname. If we receive a search request over port 443, the certificate handshake will complete successfully, but we will then redirect the user to a non-SSL search experience along with an initial message explaining so.

http://www.google.com/support/websearch/bin/answer.py?hl=en&...

This is a big deal. There are entire businesses built on this default (e.g. Compete.com's competitive keyword sniffing, or to some extent DDG's role as 'the good guy').

Seems like this will mean hugely asymmetrical information about search queries -- Google will still see all Google queries, but nobody else will.

This might also prevent even toolbars from seeing this stuff (remember when Google and Bing went tete-a-tete over that issue?).

So all in all a good thing :)

Adwords customers still get the data: "If you choose to click on an ad appearing on our search results page, your browser will continue to send the relevant query over the network to enable advertisers to measure the effectiveness of their campaigns and to improve the ads and offers they present to you."

They'll still get the paid keyword data, but it's going to be more difficult to figure out what keywords you need to pay for when you don't have a good picture of your organic traffic.

Yeah, i guess this could be a play to get more people to run more speculative campaigns to test the waters instead of letting organic do it.

Just to clarify what this means to web masters - expect to see a decline in some of your highest volume keywords, and a jump in keyword reports for "(not provided)" (i.e. search traffic remains the same, but a greater portion of visits is grouped in "keyword unknown" or similar)

If you're taken from one https to another https location, doesn't referrer still get passed? So possibly what it means is that you need to implement SSL. Google's choice here will hopefully motivate change around the web.

> If you're taken from one https to another https location, > doesn't referrer still get passed?

It depends. For Gecko, that's a configuration option (defaulting to "send cross-site" at the moment, but subject to change in general).

And as others have pointed out, sites using AdSense can't very well "implement SSL".

IIRC, (most?) browsers will still send the referrer (sorry, "referer") if you're going HTTPS->HTTPS, so if your your site is using SSL, you'll still get to see the referral data, wouldn't you? Whereas HTTPS->HTTP won't send referrer data and businesses would lose valuable information.

Perhaps this provides an incentive for sites to start serving HTTPS-Only, or at least showing Google only the SSL version (e.g. showing rel='canonical' with the HTTPS link). On the other hand, Google is still disincentivizing use of SSL through AdSense, which I believe is still HTTP-Only.

Even with the AdSense disincentive, it could still help. Knowing your referrer keywords is much more important to businesses than AdSense, and it's a very good thing for a site that wants my money to be served by HTTPS-Only, since you can MITM a site easier if there are any HTTP-Only pages on said site.

Sites relying heavily on AdSense, OTOH, would be more likely to be ad-supported rather than product sales-supported, and thus would have less need to be fully secured, since you're less likely to enter sensitive information there (excepting, of course, people who stubbornly reuse the same password everywhere).

I'd like to see this lead to a push of vendors who both sell a product and use AdSense to demand Google support SSL for AdSense, since they would need both referrer data and AdSense to survive. Once Google cracks and adds SSL support to AdWords, smaller sites will be more inclined to offer there content as HTTPS-Only.

It's a step in the right direction, at least.

>the referrer (sorry, "referer")

It isn't even an americanism, its a straight-up misspelling.

Every time I have to type it I die a little inside.

http://en.wikipedia.org/wiki/HTTP_referrer#Origin_of_the_ter...

> Every time I have to type it I die a little inside.

I rarely spell it "properly" on the first attempt. My brain just auto-corrects it as I type. I try to think of it as an inside joke or something, but - as you can see from my previous comment - it doesn't stop me from being snarky about it.

English is a living language. If that's how people start spelling the word, then that is how the word is spelled.

I know, you get far more entertainment for your buck complaining, but even so, who cares?

Side note: many things commonly refered to as "americanisms" cannot be accurately described as such. See color/colour. Pedants beware.

>If that's how people start spelling the word, then that is how the word is spelled.

I quite agree. Unfortunately, there aren't any people that spell the word with three Rs, only HTTP parsers, and I draw the line at bending my conception of language to the will of inanimate agents, as inevitable as this may turn out to be.

>but even so, who cares?

Let's make a deal, I'll stop being irrationally emotional about spelling when everyone else stops being irrationally emotional about brace placement. Cool? ;)

This isn't a bunch of schoolchildren inventing new words or some literary movement to change the spelling of a class of words. This is one mistake by a dude who wrote something years ago that now everyone has to duplicate. It is a terrible example of "living language".

Is it? When I'm writing about somebody who refers another person somewhere, I use "referrer." When I write about HTTP headers, I use "referer," even outside of code (i.e. in chat or prose). They're distinct concepts that now have distinct (but homophonic) words.

I think this is the most interesting part: "websites you visit from our organic search listings will still know that you came from Google, but won't know the exact query."

I wonder if Google Analytics will still list the queries. (They mention that Google Webmasters' Tools will give the top 1000 queries, but not individual results.)

Not for signed in users: http://analytics.blogspot.com/2011/10/making-search-more-sec...

  To help you better identify the signed in user organic
  search visits, we created the token “(not provided)”
  within Organic Search Traffic Keyword reporting. You
  will continue to see referrals without any change; only
  the queries for signed in user visits will be affected.
  Note that “cpc” paid search data is not affected.

This will make it much more difficult to measure organic search marketing efforts, but for Google, this should encourage more investment in paid marketing campaigns to measure keyword effectiveness.

...so I no longer get to see which queries brought users to our site? (we get a lot of organic search results, not from spam, but reasonably) Ouch.

This is nice, because I hate all the spam sites that take your Google query and put it in the text of the page somewhere. Before long, the spam page attracts hits for that query because the page now contains that exact text. By hiding your search from the site that you're visiting, they can't do this anymore.

I've always disabled cross-site referers because it's none of anyone's business how I got to their site. This seems to be the way the winds are blowing now.

It occurs to me that I haven't landed on a page that did that for a long time. Maybe I just don't notice anymore, or I'm better at not clicking through to them, but perhaps google has mostly killed that trick.

This sets a good precedent. It will provide more thrust towards making SSL the default communication mode.

Correct me if I am wrong, but this could have pretty big implications for people tracking query terms on anything that has been self created (for SEO purposes etc). Other analytics packages (self-rolled/3rd party) won't have near the amount of data that Google Analytics will correct?

Referer headers are still sent when you go from one SSL page to another. So, the greatest impact of this development will actually be to force the rest of the web to use SSL, because they need it for analytics.

I didn't' realize the referrer (and querystring param) was sent cross domain over SSL. So as long as you are utilizing SSL everything should remain the same.

My reading of it has them blocking referrers even if the target page is https. See: http://searchengineland.com/google-to-begin-encrypting-searc...

Yes well, regardless of what any SEO blogs may say, the fact is that browsers do send referer headers when travelling from one SSL page to another.

So unless gAnalytics is going to be deliberately ignoring incoming referer headers in particular circumstances from now on, things should remain the same if your page uses SSL.

I willing to believe however that they actually are going to be deliberately ignoring/discarding the data even when it's available. That would certainly make the EU happy.

Your use of "them" is a bit unclear.

The browser decides when to send a referrer, not Google. You can, for instance, tell your browser never to send them, or to send a specific one.

Google could wipe the referrer, though.

They can create a bounce page, but they have no control over what referrer actually gets sent. The browser, not the website, sends the referrer.

https://secure.wikimedia.org/wikipedia/en/wiki/HTTP_referrer

In HTML5 you can apparently request that a referrer not be sent, but that's a request, not a command.

Google Analytics won't have the queries either: http://analytics.blogspot.com/2011/10/making-search-more-sec...

So Google says 'we will play the game just like everyone else' and not report to you organic search terms coming from SSL (even though we have access to the data), but we also have a product (webmaster tools) that we can show you who is searching for what to get to your site, albeit slightly more obfuscated? It certainly sounds like a win for end users, not really sure it helps webmasters trying to see inbound search terms though. It sounds like it makes people have to put a little more value on the stats that Google provides via webmaster tools.

If referrers from HTTPS pages were sent to HTTP pages by browsers anyone sniffing the connection would know the URL the user visited. For a search engine, this would make SSL pretty useless as the main thing worth encrypting is search queries and people usually end up clicking links to non-SSL pages.

I presume they're working around it for ads and (telling webmasters the user is coming from Google) by sending the user through a HTTP page before they reach the result (like DuckDuckGo does, but for the opposite reason).

What this also does, and they won't mention this, is get their cookies through your firewall filter because they are encrypted and cannot be read except direct by your browser.

This is why I use https for gmail and http for search. But I guess I have to use browser based filtering now.

Which cookies in particular? Tracking cookies?

If so, why not use one of the opt out plugins, rather than search over http?

Well, you could also install a Cookie filter at the browser level.

Your concern is not justified. The change only applies to logged-in users who - by definition - must be exchanging cookies with google.com already.

> If you choose to click on an ad appearing on our search results page, your browser will continue to send the relevant query over the network to enable advertisers to measure the effectiveness of their campaigns and to improve the ads and offers they present to you.

What's interesting to me is they have a double standard: if you pay for placement, you'll get keyword data. If it's organic placement, you won't get keyword data.

I have no opinion, just thought it was interesting.

Grateful for this. This will help protect my friends and family who have no idea what they are doing or what information gets sent over the wire/air.

I predicted this change in February... http://tompitts.org/external-search-keyword-data-living-on-b...

It will also stop other search engines like Bing from utilizing keyword referral data in their search algorithms.

Unless I'm missing something this doesn't apply if you enter a search in the browser's search bar, only if you visit google.com

Of course you can manually change the search bar settings in most browsers to use encrypted.google.com.

if you are using the default search in chrome, I am sure that google will update it to be the encrypted by default. If you manually change to the unencrypted version, it'll likely stay that way. Pure conjecture, but really likely, in my opinion.

first wikipedia: http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/20..., now google.

Can HN do this too?

HN is already set up for SSL; the changeover happened around two months ago[1].

If your concern is that you should be forced to the HTTPS site, even if you mistype or bookmark the wrong version, etc., then you could try the EFF's HTTPS-Everywhere extension (Firefox only. I'm told Chrome's extension framework is fundamentally incompatible right now).[2] If you've noticed a lot of comments have linked to, for example, Wikipedia using a "secure.wikimedia.org/wikipedia" type URL, this extension is very likely how they got that way.

Out of the box, there is no ruleset preconfigured in HTTPS-Everywhere for HN, but the top comment[3] on the HN SSL announcement/discovery post gives a rule for it to configure it to always force HN to SSL.

[1] - https://news.ycombinator.com/item?id=3126309

[2] - https://www.eff.org/https-everywhere/

[3] - https://news.ycombinator.com/item?id=2909103

there is also the HTTPS Finder[1] add-on that automatically discovers HTTPS versions of webpages, and offers to generate HTTPS-Everywhere rules for them.

[1] - https://addons.mozilla.org/en-US/firefox/addon/https-finder/

Ah, thanks. I missed that, and haven't checked in 2 months.

I actually have HTTPS Everywhere, but it didn't find it for the reasons you mention.

If anyone at HN is reading, the certificate doesn't work if you visit via news.ycombinator.org (vs .com). It would probably be better to just make that a redirect to .com, rather than what appears to be an alias.

For chrome you can go to chrome://net-internals/#hsts and enter news.ycombinator.com and Chrome will automatically only make requests to https.

I wonder if this data will be available in the $100k+ a year Google Analytics Premium product they announced a couple weeks ago. http://analytics.blogspot.com/2011/09/introducing-google-ana...

May be google make an incentive for users to sign-in for increasing Google+ usage.

May be they are pushing Adwords channel by saying: "look you can arrange your campaigns in keyword level."

It's interesting to see this decision while they are improving Google Analytics very much lately. Maybe they will monetize by subscription model.

One more step along the way of making google the all knowing entity and slamming the door shut on everybody else that would like to go the same way.

Now if they would please allow adsense ads on ssl served pages elsewhere it would actually make some sense.

Google used to redirect the clicks, not aggressively before. But now since it is going to be a default behavior, i think google is aggressively using user clicks as the variable for their ranking.

Going from secure to non secure currently doesn't even give an indication that Google is sending the traffic, am I missing something?

Actually it seems https://encrypted.google.com does this, simply acting as https to http normally would. Where as https://google.com refers you through a http intermediate and simple sends across an empty query string.

HTTPS = more overhead than HTTP, so this is going to increase network traffic everywhere that uses Google that has people logged in for Gmail, which is just about everywhere to some extent. It will be minor, but could still have a detrimental effect.

Unencrypted HTTP has its own detrimental effects.

>HTTPS = more overhead than HTTP

Is that true? Most encryption schemes include compression (since compression removes redundancy, and redundancy is where cryptanalysts attack).

And I guess if you use chrome(ium), you're already using an encrypted channel with SPDY anyway.

SSL handshaking causes more traffic. It may be compressed, but small pages like the Google main search page (the heaviest hit) may show an increase in traffic, even after compression is factored in. Here's one place where HTTP vs HTTPS is discussed, and a few quotes:

"Servers that are heavy on serving a fairly small set of static pages that can easily be cached in memory suffer from a much higher overhead... SSL handshaking is the major cost of HTTPS."

http://stackoverflow.com/questions/149274/http-vs-https-perf...

I wonder if this is at all due to duckduckgo, and some of the issues they have championed (and generated news around).

I very much doubt it. Facebook, Twitter, and a number of other major web properties have been making moves toward more HTTPS usage. As of this month, for example, Facebook is requiring all FB app developers to have an SSL certificate for their app URLs. There are much better reasons for the switch than a niche site unknown outside of the techie community.

Google had encrypted search in beta at encrypted.google.com for almost 2 years now.

That security has significant price tag attached to it: Losing search query information would degrade usability on receiving web sites.

Currently my web site highlights keywords that user was searching for on Google. It will be impossible anymore for users who logged in to Google.

Is it possible to opt out from SSL search on Google?

I hate sites that highlight search keywords. I am sorry that this broke your feature, but overall glad that no site will be able to do it anymore.

Do you hate using Google search results too?

Search keywords in these results are highlighted.

If your goal is to hide your intent from web sites you visit - you can just turn off URL Referrer in your browser.

It's a rare search that takes me to a page that mentions what I'm searching for exactly once.

Search result pages and destination pages serve completely different purposes, and you can't apply the same UI to both. If you ran a restaurant, you might decide to laminate the menus, but I hope you wouldn't laminate the entrees, too.

If it doesn't make sense to highlight search keywords that web masters wouldn't do that would they?

Highlighting "salmon" menu entries on web site could make sense for the user who is searching for "salmon", wouldn't it?

But let's be more specific: I run a job board (PostJobFree) and recruiters frequently find resumes on Goolge in queries like this:

http://www.google.com/search?q=intitle%3Aresume+sharepoint+C...

If you open first result - you can see how these keywords are highlighted. I'm pretty sure that this highlighting is a convenient feature for recruiters who want to quickly scan resume.

Ugh, you really need some basic formatting. I can't even see where one job ends and another one starts. And the contextless highlight doesn't make that any better.

I don't like it because, often, the keyword I'm looking for is sprinkled throughout the whole page, putting highlights sporadically everywhere.

Curious: have you tested/surveyed user preference to having that feature or not?

I have not tested/surveyed users about, but I personally like highlighting in this case and in ~4 years nobody complained about highlighting.

a lot of people don't know what they want until its given as an option. Regardless, its exactly why A/B tests exist

It takes some effort to setup such test. There are more important things to do.

Besides - there is no point testing it now, considering that Google slowly takes away that option.

You're right -- it takes time/effort, you know your business better than anyone to figure out if it's worth testing and optimizing. However, the lack of complaints shouldn't be construed as approval or desire.

Have you asked? I wouldn't go out of my way to let a webmaster know, I would just be annoyed. From the looks of HN replies, this is not uncommon.

Reply on news.ycombinator.com