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