Shared publicly  - 
The Google +1 Chrome extension sends an RPC event to Google for every page you visit, https or not.

UPDATE: See +Jonathan McPhie's response in the comments below about fix coming tomorrow.

I hate to be a downer on cool stuff like this, but I really don't think this is acceptable. It's even sending the querystring, which could potentially contain a secure session token. All of the communication to the Google servers happens over https, but I don't think that fact excuses this. https:// traffic needs to be off-limits for automatic tracking of URLs.

I'd be OK if the button allowed you to disable auto-reporting of the current +1 count (this can default to 'on'), and added a default-off option to show +1 counts for https sites.

Thanks to +Louis Gray for quickly responding! "I filed a bug internally and sent an email to the right folks." I'll update this when I have more info.
Dustin Mitchell's profile photoEli Spizzichino's profile photoSlava Kravchenko's profile photoMike Silva's profile photo
Nice find and thanks for sharing. SSL should be off-limits, everything else I don't mind much.
The samy spy is used by plugin, I guess. I don't like that spying on me so I removed it completely.
+Randy McCall bit of an overreaction, its possibly an oversight they will fix. Google are pretty anal about privacy and letting people retain theirs
Is this true when browsing Incognito as well?
+Liz Quilty perhaps an overreaction, but the publicity from a government complaint about privacy issues on their new system will make them fix it faster.
+Lorin Olsen - Only if you've explicitly allowed the +1 extension to run in incognito mode. By default, all browser extensions are disabled for incognito windows.
+Shawn Drape i think the publicity or bringing it to their attention on g+ should do it
Louis Gray
+Matt Mastracci thanks for this. You're more geeky than I am, so I trust your judgment. I filed a bug internally and sent an email to the right folks.
+Liz Quilty this is no oversight. This is from the Plugin page:

"In addition to the practices described in the Google +1 Button Privacy Policy, by installing this extension, all of the pages and URLs you visit will be sent to Google in order to retrieve +1 information. Examples of this information include whether you’ve previously +1’d the page and how many people have already +1’d the page. Google’s use of this information is described further in the following help center article ( "
You know google analytics does this right, so you're saying that should be disabled as well?
+Ben Petro Google Analytics only does it for sites that have it installed. This sends every page you browse (http, https, and servers on your intranet) over RPC, whether or not the site has opted-in or not.
But still, the user has no say whether analytics is installed on a site they're visiting. If you don't want to be tracked, use incognito. I don't see an issue here.
+Ben Petro User add-ons shouldn't be enable tracking of https URL streams by default, unless the user specifically opts-in to the feature. I'm not saying that they can't add an option to allow this, but the default state of the extension should not send back https: URLs. There are both privacy and security implications to this.
Shit... I have disabled it until something is figured out.
This post is #2 on hackernews :) The right people know; hopefully they will have it fixed soon.
Hi all, G+ privacy guy here. I'm in touch with the engineers who developed the extension. We're looking into this and will have updates for you as soon as we can. Thanks for posting this.
This isn't really new or surprising, it's been like this since +1 was released. This was a very intentional feature of +1.

From their privacy pages,

Why does Google need this information?

When you do a Google search or visit a page with a +1 button, we send different pieces of your request to separate servers -- which helps the +1 button load quickly. To ensure those servers are processing your request correctly, and in the rare cases where we need to debug our systems, this information helps us find the source of the problem between servers and fix it.
+John Tantalo The http: tracking is expected (and understandable), but https: tracking is not - see above for a discussion of this.
Does the https traffic get sent via RPC in http only? If so, THAT is wrong, otherwise, I still don't think there's anything wrong with it. If it's https, it's still encrypted.
+Matt Mastracci I suppose I don't see why they should treat https any differently than http. The obvious solution (to hash) should apply to both. Why don't you care about your privacy on http?
+John Tantalo Yes, hashes would solve the problem. This is actually the way we went with DotSpots to protect user's privacy. Our service disabled itself entirely on https pages.

I have no expectation of privacy on http, but to be honest, I'm not going to use the +1 button in its current state if it's sending back every URL I visit (http or not). Sending back https: URLs is a big deal, however, and should not happen in any product without the user opting in to this.
+1 extension (and all other extensions) are disabled in incognito mode. For private browsing that's the best option available.
+Abraham Williams Until there's a way to state that "this page is a bank, do not track", there's not much else that can be done.
+Abraham Williams Chrome extensions can provide option pages - this could be done with a small amount of effort.

Ideally the extension would just default to not sending https URLs, with an option to turn this feature on. There should also be an option to turn off counts for all pages in the same spot. You could still be able to +1 an https page, with the understanding that you'd be sharing potentially private information. I would have no issue with this.
If the +1 Button used a supplied canonical URL or stripped off any parameters if none provided, then no private bits would be included. The +1 counts would be better aggregated as well.

On a related note to URL sharing with personal information: many Google Maps queries include your default location which gets shared.
Thank you for the many thoughtful comments in this thread. As several of you pointed out, we do take privacy very seriously, which is what led us to develop the disclosures mentioned above ( that explain why we send URLs back to our servers and why that helps our users in a safe way.

However, it’s clear from the discussion that our current behavior is not obvious to some of our users. As a result, we have decided to take a more conservative approach and remove some functionality from the extension. Tomorrow, we will be releasing an update that does not work for https URLs with query parameters. For the geeks out there who want to know more, check out my profile tomorrow for a post with more details. (Update: post now live!).

We’d like to add that functionality back, at least for users who want it, and are looking into options for doing so.
Add a comment...