7 ms·

Google to default to SSL version for logged in users

236 points by cleverjake 15y ago

ck2 15y ago
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.
- cleverjake 15y ago
  Which cookies in particular? Tracking cookies? If so, why not use one of the opt out plugins, rather than search over http?
- aristidb 15y ago
  Well, you could also install a Cookie filter at the browser level.
- enneff 15y ago
  Your concern is not justified. The change only applies to logged-in users who - by definition - must be exchanging cookies with google.com already.
pingswept 15y ago
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.)
- joelhaus 15y ago
  Not for signed in users: http://analytics.blogspot.com/2011/10/making-search-more-secure-accessing.html 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.
  - hessenwolf 15y ago
    ...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.
- schammy 15y ago
  That doesn't make any sense to me. If you click a link on an HTTPS site, your browser doesn't send a referrer. So people coming from encyrpted Google to another site, that site would actually get NO referrer data at all.
cyanbane 15y ago
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?
- JonnieCache 15y ago
  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.
  - cyanbane 15y ago
    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.
  - will_critchlow 15y ago
    My reading of it has them blocking referrers even if the target page is https. See: http://searchengineland.com/google-to-begin-encrypting-searches-outbound-clicks-by-default-97435 http://searchengineland.com/google-to-begin-encrypting-searc...
    - JonnieCache 15y ago
      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.
    - Natsu 15y ago
      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.
raheemm 15y ago
This sets a good precedent. It will provide more thrust towards making SSL the default communication mode.
MikeGrace 15y ago
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.
kitcar 15y ago
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)
- boredguy8 15y ago
  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.
  - deleted 15y ago
    [deleted]
    - seiji 15y ago
      Counterpoint: http://www.google.com/search?q=site:github.com http://www.google.com/search?q=site:github.com
    - deleted 15y ago
      [deleted]
  - bzbarsky 15y ago
    > 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".
tlrobinson 15y ago
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.
- cleverjake 15y ago
  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.
stock_toaster 15y ago
I wonder if this is at all due to duckduckgo, and some of the issues they have championed (and generated news around).
- ceejayoz 15y ago
  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.
- nextparadigms 15y ago
  Google had encrypted search in beta at encrypted.google.com for almost 2 years now.
breck 15y ago
> 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.
dennisgorelik 15y ago
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?
- evmar 15y ago
  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.
  - dennisgorelik 15y ago
    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.
    - byrneseyeview 15y ago
      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.
      - dennisgorelik 15y ago
        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%23+memphis 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.
orionlogic 15y ago
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.
afdssfda 15y ago
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.
- ceejayoz 15y ago
  Unencrypted HTTP has its own detrimental effects.
- metageek 15y ago
  >HTTPS = more overhead than HTTP Is that true? Most encryption schemes include compression (since compression removes redundancy, and redundancy is where cryptanalysts attack).
  - tonfa 15y ago
    And I guess if you use chrome(ium), you're already using an encrypted channel with SPDY anyway.
  - afdssfda 15y ago
    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-performance http://stackoverflow.com/questions/149274/http-vs-https-perf...
taylorbuley 15y ago
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?).
- nkassis 15y ago
  So all in all a good thing :)
  - deleted 15y ago
    [deleted]
- slouch 15y ago
  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."
  - ry0ohki 15y ago
    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.
    - robryan 15y ago
      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.
philfreo 15y ago
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&answer=10528 https://www.google.com/adsense/support/bin/answer.py?hl=en&#...
- corbet 15y ago
  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.
- hospadam 15y ago
  This can't be said enough. Has Google even acknowledged this as a security issue?
- Natsu 15y ago
  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&answer=173733&topic=1678515 http://www.google.com/support/websearch/bin/answer.py?hl=en&...
tpiddy 15y ago
I predicted this change in February... http://tompitts.org/external-search-keyword-data-living-on-borrowed-time/ 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.
0x12 15y ago
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.
rshm 15y ago
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.
deleted 15y ago
[deleted]
karlzt 15y ago
first wikipedia: http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2011-10-10/Technology_report http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/20..., now google.
rdc 15y ago
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-analytics-premium.html http://analytics.blogspot.com/2011/09/introducing-google-ana...
AgentConundrum 15y ago
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.
- JonnieCache 15y ago
  >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_term_referer http://en.wikipedia.org/wiki/HTTP_referrer#Origin_of_the_ter...
  - AgentConundrum 15y ago
    > 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.
  - 15y ago
robryan 15y ago
Going from secure to non secure currently doesn't even give an indication that Google is sending the traffic, am I missing something?
- robryan 15y ago
  Actually it seems https://encrypted.google.com https://encrypted.google.com does this, simply acting as https to http normally would. Where as https://google.com https://google.com refers you through a http intermediate and simple sends across an empty query string.
jrockway 15y ago
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.
- jberryman 15y ago
  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.
lawnchair_larry 15y ago
Can HN do this too?
- AgentConundrum 15y ago
  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 https://news.ycombinator.com/item?id=3126309 [2] - https://www.eff.org/https-everywhere/ https://www.eff.org/https-everywhere/ [3] - https://news.ycombinator.com/item?id=2909103 https://news.ycombinator.com/item?id=2909103
  - throwaway64 15y ago
    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/ https://addons.mozilla.org/en-US/firefox/addon/https-finder/
  - lawnchair_larry 15y ago
    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.
  - abraham 15y ago
    For chrome you can go to chrome://net-internals/#hsts and enter news.ycombinator.com and Chrome will automatically only make requests to https.

236 points by cleverjake 15y ago

ck2 15y ago

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.

cleverjake 15y ago
Which cookies in particular? Tracking cookies? If so, why not use one of the opt out plugins, rather than search over http?
aristidb 15y ago
Well, you could also install a Cookie filter at the browser level.
enneff 15y ago
Your concern is not justified. The change only applies to logged-in users who - by definition - must be exchanging cookies with google.com already.

pingswept 15y ago

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.)

joelhaus 15y ago
Not for signed in users: http://analytics.blogspot.com/2011/10/making-search-more-secure-accessing.html 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.
- hessenwolf 15y ago
  ...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.
schammy 15y ago
That doesn't make any sense to me. If you click a link on an HTTPS site, your browser doesn't send a referrer. So people coming from encyrpted Google to another site, that site would actually get NO referrer data at all.

cyanbane 15y ago

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?

JonnieCache 15y ago
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.
- cyanbane 15y ago
  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.
- will_critchlow 15y ago
  My reading of it has them blocking referrers even if the target page is https. See: http://searchengineland.com/google-to-begin-encrypting-searches-outbound-clicks-by-default-97435 http://searchengineland.com/google-to-begin-encrypting-searc...
  - JonnieCache 15y ago
    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.
  - Natsu 15y ago
    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.

raheemm 15y ago

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

MikeGrace 15y ago

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.

kitcar 15y ago

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)

boredguy8 15y ago
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.
- deleted 15y ago
  [deleted]
  - seiji 15y ago
    Counterpoint: http://www.google.com/search?q=site:github.com http://www.google.com/search?q=site:github.com
  - deleted 15y ago
    [deleted]
- bzbarsky 15y ago
  > 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".

tlrobinson 15y ago

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.

cleverjake 15y ago
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.

stock_toaster 15y ago

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

ceejayoz 15y ago
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.
nextparadigms 15y ago
Google had encrypted search in beta at encrypted.google.com for almost 2 years now.

breck 15y ago

> 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.

dennisgorelik 15y ago

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?

evmar 15y ago
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.
- dennisgorelik 15y ago
  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.
  - byrneseyeview 15y ago
    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.
    - dennisgorelik 15y ago
      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%23+memphis 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.

orionlogic 15y ago

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.

afdssfda 15y ago

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.

ceejayoz 15y ago
Unencrypted HTTP has its own detrimental effects.
metageek 15y ago
>HTTPS = more overhead than HTTP Is that true? Most encryption schemes include compression (since compression removes redundancy, and redundancy is where cryptanalysts attack).
- tonfa 15y ago
  And I guess if you use chrome(ium), you're already using an encrypted channel with SPDY anyway.
- afdssfda 15y ago
  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-performance http://stackoverflow.com/questions/149274/http-vs-https-perf...

taylorbuley 15y ago

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?).

nkassis 15y ago
So all in all a good thing :)
- deleted 15y ago
  [deleted]
slouch 15y ago
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."
- ry0ohki 15y ago
  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.
  - robryan 15y ago
    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.

philfreo 15y ago

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&answer=10528 https://www.google.com/adsense/support/bin/answer.py?hl=en&#...

corbet 15y ago
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.
hospadam 15y ago
This can't be said enough. Has Google even acknowledged this as a security issue?
Natsu 15y ago
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&answer=173733&topic=1678515 http://www.google.com/support/websearch/bin/answer.py?hl=en&...

tpiddy 15y ago

I predicted this change in February... http://tompitts.org/external-search-keyword-data-living-on-borrowed-time/ 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.

0x12 15y ago

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.

rshm 15y ago

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.

deleted 15y ago

[deleted]

karlzt 15y ago

first wikipedia: http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2011-10-10/Technology_report http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/20..., now google.

rdc 15y ago

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-analytics-premium.html http://analytics.blogspot.com/2011/09/introducing-google-ana...

AgentConundrum 15y ago

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.

JonnieCache 15y ago
>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_term_referer http://en.wikipedia.org/wiki/HTTP_referrer#Origin_of_the_ter...
- AgentConundrum 15y ago
  > 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.
- 15y ago

robryan 15y ago

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

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

jrockway 15y ago

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.

jberryman 15y ago
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.

lawnchair_larry 15y ago

Can HN do this too?

AgentConundrum 15y ago
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 https://news.ycombinator.com/item?id=3126309 [2] - https://www.eff.org/https-everywhere/ https://www.eff.org/https-everywhere/ [3] - https://news.ycombinator.com/item?id=2909103 https://news.ycombinator.com/item?id=2909103
- throwaway64 15y ago
  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/ https://addons.mozilla.org/en-US/firefox/addon/https-finder/
- lawnchair_larry 15y ago
  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.
- abraham 15y ago
  For chrome you can go to chrome://net-internals/#hsts and enter news.ycombinator.com and Chrome will automatically only make requests to https.