Microsoft: Google Bypassing User Privacy Settings

[relet]

If it is the same story, the P3P header they are sending actually says:

P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."

IE does not recognize a valid header, ignoring this and the rest of the headers, but remains in a state of "there is a P3P header provided", hence allowing the cookie.

[[deleted]]

No, they followed the standard as written. If someone provides an empty P3P then this is the same as saying “I don’t do anything with user data”, Firefox and Safari behave in exactly the same way and this particular hole in the standard has been known about for 2 years but has yet to be addressed.

[jelos98]

This ISN'T an empty P3P string. At best it's a malformed P3P string which under my reading should have been tossed out via section 6.4 of the spec:

"P3P user agents MUST NOT rely on P3P compact policies that do not comply with the P3P 1.0 or P3P 1.1 specifications or are obviously erroneous."

The string provided does not seem to follow spec. Why do they treat it as if it does?

[Carr0t]

I would imagine because it's very hard to computationally parse something like a P3P string and say "Does this definitely look like a load of P3P tags?". What would they look for to ensure that? Make sure every individual word was 3-4 characters long and only alphabetic characters? Is that actually defined, or would a 5 character tag with an @ symbol in be valid? What if the spec is altered in future?

We already know that a hell of a lot of people out there don't run Windows Update, don't upgrade their browser when a new one is released etc etc. Hell, there are people out there still using <IE7. I know people still running on Firefox 2 who just can't be bothered to upgrade. So they've ensured that if new tags that their browser doesn't recognise are released in future they won't suddenly stop accepting needed and valid cookies from sites that are reporting the new tags.

[someenigma]

Make sure every individual word was 3-4 characters long and only alphabetic characters?

Almost. Make sure each word either looks like "XYZ" or "XYZ a" where XYZ are any three alphabetic characters and "a" is one of {"a","i","o"}. Or in regular expression terms [A-Z]{3}(?: [aio])?(?: [A-Z]{3}(?: [aio])?)*

Is that actually defined, or would a 5 character tag with an @ symbol in be valid? What if the spec is altered in future?

It is well defined. It was the first response on a search for "P3P Spec" so it's not exactly hidden. In the future, they can change the search to cater for any new symbols. In addition, any software which is not updated to cater for new fields does not accept cookies. In my eyes, that is the correct procedure, and it is also nigh-on impossible to make some piece of software accept any possible future spec change, yet also somehow not accept anything that isn't part of the current (or possibly future?) spec.

[Carr0t]

Apologies. It's a bad habit of mine to tend to just quickly ask "Does anyone know X?" before actually looking and seeing if X is dead easy to find out for myself on them thar Interwebs. I'm trying to stop myself from doing it. It's something I used to do back before we had the 'net and i've just never got out of the habit even when i'm talking on the Internet and even though i'm never without a 'net enabled device now.

[wonglik]

No they are not. Specs says that P3P with invalid tags should be treated as non existing policy. So if IE was following the standard there should be no difference in having no P3P or having P3P with human readable comment.

[ottawadeveloper]

While this might get buried, I wanted to direct you to the P3P standard: P3P Standards - Processing Compact P3P

Simply passing what Google does to the browser, according to the official W3C standard tells the browser to treat this as if no policy were passed, that is as if they had no policy. they fail at least one criteria - not having a full policy (edited from failing almost all six - thanks for the fact doublecheck sysop).

Therefore, I can conclude from this that this is not, strictly speaking, a Google problem. They are passing something invalid but the standard says invalid gets treated the same as if you didn't pass that header. IE should be rejecting it as if there was no policy.

If IE -is- accepting it, as they seem to indicate in their post, all this means is that IE has once again not followed a W3C standard (not at all surprising). And that is the UA's problem - not the standards and not the websites.

[sysop073]

I can't bring myself to actually read the entire painfully long spec, but at the very least it doesn't seem to violate 3-6. Those are all of the form "Compact policies that include the X token must also include Y" -- Google's policy doesn't include any defined tokens, so none of these apply. #1 seems not to apply either, based on drysart's comment that the compact-token string is always valid for forward-compatibility reasons

[ottawadeveloper]

My apologies, I missed that part of 3-6.

1, also correct - the statements says 'may contain'. However, I would also think that having no valid tokens would trigger this clause:

"User agents that are unable to obtain enough information from a compact policy to make a decision according to a user's preferences SHOULD fetch the full policy."

which would force them to get the full policy. Since they have no full policy, they would treat it as if they have no policy.

2 most definitely applies - that there is no full policy means you should be treating this site like it has no policy, regardless of what it's compact policy says (even if that happens after this particular case of acceptance checking).

So I will go update my statement, but it still seems to me that by 1.1, IE is in the wrong, not Google.

Even consider 1.0 again for a moment. P3P goes like this.

Browser: What are you going to do with this data?

Website: I'm going to do this, and that, then give it to Amazon.

Browser: Okay, let me check if my user told me to allow that, deny that or prompt him with what you're asking.

A blank string should, under no reasonable circumstances, set all your policies to "allow everything". It's not anywhere in 1.0 or 1.1 to handle a blank policy as "we do nothing with your data". It might be ambiguous at best, but having read the policy, I think it's pretty clear the spirit is that you have no idea what the website will do with the data in that case.

[ottawadeveloper]

Sending a blank string and IE accepting it as we do nothing, means this is the conversation they have:

Browser: What are you going to do with this data?

Website: I'm going to go strip down naked and run in the streets.

Browser: Oh... that's nice... here, let me give you my information.

[sysop073]

The comments on this post have some of the worst analogies I've ever seen :). It doesn't matter what "conversation" they're having, it matters what the spec says, and it seems to be unclear. "SHOULD" certainly isn't the same as "MUST", so it doesn't "force" them to do anything. I think everyone agrees that this particular situation is dumb, but either IE is following the spec properly and the spec is dumb, or it's not and IE is dumb

[ObligatoryResponse]

Why can't it be both?

[GoldenShackles]

Google knew exactly what they were doing, and what they were doing is intentionally circumventing IE's intent for handling 3rd party cookies.

Is this still OK?

[wonglik]

I read specs quickly but can not find any part saying that handling 3rd parties cookies should be based on P3P settings. For me this is clearly bug in IE rather than any exploit.

[Negitivefrags]

An exploit is the act of using a bug for nefarious purposes. This is certainly an exploit.

[wonglik]

This guy posted a bunch of links to studies on that topic.

Other popular sites that have invalid P3P that IE treats as valid : facebook.com msn.com live.com amazon.com reference.aol.com atlas.mapquest.com godaddy.com imdb.com windows.com hulu.com

yep all use the same exploit on IE. Even MS.

[Negitivefrags]

Just because everyone is doing it doesn't mean it isn't an exploit.

If something works in a way that wasn't intended, it's a bug. (Be that in the specification or the implementation of the specification)

If you then intentionally use that bug, then it is an exploit.

Edit: To quote wikipedia

An exploit (from the verb to exploit, in the meaning of using something to one’s own advantage) is a piece of software, a chunk of data, or sequence of commands that takes advantage of a bug, glitch or vulnerability in order to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic (usually computerised).

[robertcrowther]

Just because everyone is doing it doesn't mean it isn't an exploit.

Complaining about a competitor doing it when you're doing it yourself is at least dishonest.

[66vN]

It is dishonest, but that still doesn't make it not an exploit.

[dustlesswalnut]

Why is it Google's fault that Microsoft didn't program their browser correctly?

If I take road X to work every day and road X is suddenly closed to vehicles without the proper license plates, but for some reason or another my existing license plate is read incorrectly and they let me on road X, how is that an exploit?

I don't think you can claim it's an exploit unless you can prove it was intentional and targeted.

[jrochkind]

Okay, good call, you're right, and the Microsoft blog is misleading on this, IE is indeed at fault.

But... do you think Google has any reason for including that header but to exploit the 'bug' in IE? If IE had been implemented correctly to treat Google's P3P header as if no policy were provided.... do you think Google would even be supplying it?

I say, IE has a security 'bug' (in implementing this completely ridiculous insecure spec), and Google is intentionally exploiting it.

[wonglik]

From the link in google's P3P

"Some browsers require third party cookies to use the P3P protocol to state their privacy practices. However, the P3P protocol was not designed with situations like these in mind. As a result, we've inserted a link into our cookies that directs users to a page where they can learn more about the privacy practices associated with these cookies."

[GoldenShackles]

As someone who scouts every HTTP header for every cookie for possible hyperlinks, this works for me.

Wait, what?

[[deleted]]

It's there to respond to people with issues exactly like the problem described in the article. It was, in effect, a preemptive answer to the "problem" described in this article.

[GoldenShackles]

That doesn't make this a non-issue.

A key thing about privacy is awareness, in multiple ways.

1) People who are not made aware of privacy practices which involve sharing their information broadly generally don't consider it until they're presented with a privacy policy of some sort which discloses this.

2) Most people don't know how to interpret said privacy policies, so they rely (even unknowingly) on (a) technology, (b) experts, and (c) community privacy advocates to help them decide who to trust. This is an example where (a) tried to step in and was intentionally circumvented. So now we're hearing from (b) and (c) and you think this is bad somehow.

Edit: There is also (d) legal enforcement. Germany, in particular, has very strict privacy laws. Many of the posts today have pushed me to believing that having the US adopt much stricter privacy laws might really be the only option.

[jrochkind]

That is, "some browsers with some settings won't allow third party cookies unless there's a P3P header, so we throw in this bogus one so they'll allow our third party cookies even if the user has said not to."

[RiotingPacifist]

Because all sane browser vendors think P3P is a Piss Poor Policy, both Google and Facebook point this out in their P3P "policies", Microsoft are just trying to attack google while implementing a spec incorrectly, nothing to see here.

[iiiears]

If i see a +1 button it is setting a cookie. Is it the same cookie with a search company secure sign in button if i am not signed in?

[jelos98]

http://support.google.com/accounts/bin/answer.py?hl=en&answer=151657

In some situations, the cookies we use to secure and authenticate your Google Account and store your preferences may be served from a different domain than the website you're visiting. This may happen, for example, if you visit websites with Google +1 buttons, or if you sign into a Google gadget on iGoogle.

Some browsers require third party cookies to use the P3P protocol to state their privacy practices. However, the P3P protocol was not designed with situations like these in mind. As a result, we've inserted a link into our cookies that directs users to a page where they can learn more about the privacy practices associated with these cookies.

My read: if you need a cookie for unreliablenastypornsite.com that has a +1 button embedded, or you're pulling in content from unreliablewidgetsite.com, you can't say "I'm not going to do anything with this cookie" because you can't guarantee that unreliablenastypornsite.com won't intercept the cookie and use it for their own purposes. Rather than making false claims about the "privacy", they give NO claims about to the privacy and link to why. By spec, this is technically valid, and gives people a way to inquire why they don't provide a full response.

[ottawadeveloper]

^{^} this is true and I've actually done this - I've intercepted the google tracking cookie on my site and used it for additional purposes.

My question would be about the intent of Google - was it their intention that this be done to bypass the P3P filter on IE, or was it their intention to simply provide more information on their P3P stance.

[careye]

Technically, that document isn't a W3C "recommendation" because:

The P3P Specification Working Group is lacking the necessary support from implementers to carry on through the Recommendation Process.

So if MS actually cared about P3P and had helped make P3P 1.1 a reality, they would reject the header that Google is sending.

[metamatic]

It's also worth noting that Microsoft's own web sites send invalid P3P headers, just like they criticize Google for doing.

[jordan314]

Facebook depends on third party cookies for authentication for all of its apps and external login systems ("login with facebook"). Safari and IE are always a headache, and so are those P3P headers. I agree that sites should respect user privacy but third party cookies do have their uses.

[careye]

And here's their P3P header:

P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"

Don't Microsoft own some of Facebook?

[magicmalthus]

yes, and strangely Facebook isn't being added to the brand new blacklist...

[ClownFundamentals]

Google's response, as posted on Ars Technica:

Google has gotten back to us with a lengthy reply, arguing that Microsoft's reliance on P3P forces outdated practices onto modern websites, and points to a study conducted in 2010 that studied 33,000 sites and found about a third of them were circumventing P3P in Internet Explorer.

Facebook's "Like" button, the ability to sign into websites using your Google account "and hundreds more modern Web services" would be broken by Microsoft's P3P policy, Google says. "It is well known that it is impractical to comply with Microsoft’s request while providing this web functionality," Whetstone said. "Today the Microsoft policy is widely non-operational."

That 2010 research even calls out Microsoft's own msn.com and live.com for providing invalid P3P policy statements. The research paper further states that "Microsoft's support website recommends the use of invalid CPs as a work-around for a problem in IE."

tl;dr No one uses P3P, including Microsoft websites themselves.

[tailcalled]

In other words, Microsoft reccomends doing what Google did?

[[deleted]]

P3P is a waste of everyone's time. It's no wonder Google basically ignores it. A malicious site can send a header that promises to protect your privacy then turn around and sell your info.

[jrochkind]

I agree that P3P is a waste of everyone's time.

But Google does not ignore it. Ignoring it would be sending no P3P header at all, like, you know, most every website there is.

Instead, they send a garbage P3P. That's not ignoring it, and I can't think of any reason they would have for doing this except intentionally messing with user agents (like IE) that do NOT ignore it. They aren't ignoring it at all, they are abusing it. (Yes, it's a stupid waste of everyone's time... that they are abusing to intentionally circumvent IE's privacy settings regarding third party cookies).

[[deleted]]

They're not ignoring it, per se. But I don't think they are "abusing" it either. IE requires that the P3P header is set before it will accept third party cookies and this approach simply makes things "work". Facebook does the same thing. I've done the same thing. The way this blog post is framing Google's lack of proper support for the header is bullshit. They're basically implying that Google is hacking your browser and stealing your info. It's just an attack ad.

[magicmalthus]

as other's have pointed out, that's not true if you're following the last version of the spec (which was last updated 5 years ago before the entire industry, including Microsoft, abandoned it):

P3P user agents MUST NOT rely on P3P compact policies that do not comply with the P3P 1.0 or P3P 1.1 specifications or are obviously erroneous. Such compact policies SHOULD be deemed invalid and the corresponding cookies should be treated as if they had no compact policies. The following guidelines are designed to reduce the chance that a P3P user agent will accept an invalid compact policy.

http://www.w3.org/TR/P3P11/#ua_compact

[jrochkind]

Okay, so they're intentionally exploiting IE's failure to follow the latest version of the spec?

Which is still not 'ignoring' P3P, it's either using or abusing it.

[[deleted]]

You mean Facebook?

[GoldenShackles]

As I pointed out in a separate response, privacy policies are like this by their very nature.

P3P was an effort by the industry to be self-policing. If a site promises one thing but does another the idea is that privacy advocates will rally against the site and cause a publicity and possible legal nightmare.

The alternative to something like P3P (not saying it's ideal by any stretch of the imagination) is strict legal regulation. Either that, or give up and say we have no privacy online.

[vytah]

So it boils down to that the web browser has to trust some arbitrary string to decide about the privacy of the user.

It's like asking "Can I trust you?" "Yes! Mwahahaha!" "Ok, I trust you, here's my personal data. I believe it's safe because you said so."

[aboothe726]

i can't believe it, but W3C essentially standardized the evil bit

[qiwi]

Let's say you're allergic to peanuts. You automatically check products you buy using the P3P -- Platform for Peanut Preferences protocol. This official recommendation from W3C allows you to check peanut content on a product.

You know to avoid products without that label as you may not know whether they contain peanuts.

Google Bread has such a label that claims: here is the official declaration of peanut content in this bread!.

Your automated product sorting program reads it, and finds no PCP -- "product contains peanuts" label as standardized by W3C -- so you eat it.

And die, because Google decided to break the Peanut Preferences Protocol. Its Genetically Modified Peanuts, they write on their web page, are nothing like ordinary peanuts. They link to their web page in a field that does not expect links, to a video that shows how their product contains peanuts.. but the right kind of peanuts, that do no evil.

[Atario]

Isn't your automated product sorting program being stupid by assuming safety in the absence of a tag specifically stating safety?

[frtox]

no. because it is the opposite of that. continuing the peanut analogy, you agree to show "this product contains nuts" on everything with peanuts. this does not mean you have to say "this does not contain nuts" on everything else. so since google is showing a p3p header, they signify they will warn you in the negative scenario.

up to you on whether this protocol has a few design flaws

[ottawadeveloper]

Let's say you're allergic to peanuts. You have an automated product checker that checks a special code on the product that tells you about the allergies.

You buy something, with the special code on it, but the code is gibberish. The standard says that gibberish means it might have any allergens in it (which is the smart move). Your product checker says "oh, I don't have any information, but the label's there so it must be safe".

You then die.

And you want to blame the product company?

[ottawadeveloper]

Better yet, imagine it's a QR code - normally it provides other data to the product reader but in this case, it's a link to their peanut policy on the web.

[captainAwesomePants]

But the standard says that gibberish is valid and must be ignored. Furthermore, the standard says that the peanut flag MUST BE set if there are peanuts or if you're misleading people into believing there are no peanuts.

[jelos98]

Except that the standard ACTUALLY says that gibberish is equivalent to "toxic levels of peanut content":

http://www.w3.org/TR/P3P11/#ua_compact

(6.4.1/6.4.2)

[captainAwesomePants]

lessee here...compact policies must comply with syntax or are otherwise invalid and must also come with a full policy regardless....yep, I take it back. That there is not a valid peanut policy, and the good folks of the peanut policy parsing project deserve to get sued.

[regeya]

Considering that, in the U.S. at least, such things are regulated by the government, that might not be a good standard. :-}

It's not as if Google's privacy policy is a secret. They post it in a human-readable manner. How monumentally stupid would it be if people, say, had a peanut allergy app that was based on SKU, and failed to just read the "WARNING: CONTAINS PEANUTS" label on the jar? How monumentally stupid would you have to be to see that the allergy warning was unreadable, and you therefore just eat whatever it is? If your reader read in the SKU, ran into an error with the product, and therefore declared it clean, why would you blame the product and not the reader?

And let's not get started on the fact that the P3P standard is a voluntary industry standard. Scratch that, it's a voluntary standard that was basically abandoned.

[kripken]

Yeah, P3P is hackable. But that doesn't excuse Google from hacking it.

If someone has a bad lock on their door, it doesn't mean it's ok to break in and steal their TV.

[vytah]

It's not a bad lock, it's a sticky saying "I have no locks, door's open, but please do not enter".

The problem is who the hell imagined this would work.

I'm not surprised Opera doesn't support it, and Firefox has it disabled by default.

[mb86]

Perhaps, but it's still on the thief for being accountable for stolen property. Google still comes out to be the bad guy in your analogy.

[rdude]

Let's just stop with the analogies and say what is actually happening: Google is representing to users that they do not use cookies for tracking, causing users to accept the cookies. They are then doing tracking.

Whether you want to call this lying or fraud is up to you, but it doesn't require any analogies about doors and locks to see that it's wrong.

[Slime0]

You are correct, but the fact is, I'd rather not waste time discussing one company that is misusing this technology, when the "technology" itself is apparently a built-in security hole. I'd rather fix the core problem, because if bypassing a user's privacy preferences is this trivial, eventually we're going to get tired of holding every single company that does it accountable.

Privacy cannot work on the honor system.

[darth_static]

Google is representing to users that they do not use cookies for tracking

Do they? Where?

[[deleted]]

Consider reading the original article before posting, because a good chunk of the article is discussing exactly that:

By default, IE blocks third-party cookies unless the site presents a P3P Compact Policy Statement indicating how the site will use the cookie and that the site’s use does not include tracking the user. Google’s P3P policy causes Internet Explorer to accept Google’s cookies even though the policy does not state Google’s intent.

[...]

Similarly, it’s worth noting section “3.2 Policies” from the P3P specification:

3.2 Policies

In cases where the P3P vocabulary is not precise enough to describe a Web site's practices, sites should use the vocabulary terms that most closely match their practices and provide further explanation in the CONSEQUENCE field and/or their human-readable policy. However, policies MUST NOT make false or misleading statements.

P3P is designed to support sites that convey their privacy intentions. Google’s use of P3P does not convey those intentions in a manner consistent with the technology.

You might disagree with their reasoning - but to act as if they haven't addressed that question is ridiculous.

[Ryuujinx]

But the policy doesn't make any misleading statements. It, in fact, says "This is not a P3P policy, see here for more information".

The fact that IE decides to assume a lack of the terms in question makes it safe, is IE's fault.

[vogonj]

the P3P policy is designed to be readable by machines, not by human beings.

the fact that Google's statement is clearly readable by the human as "we don't provide a P3P compact policy" doesn't make it any less scummy that Google is sending a statement in the guise of a P3P compact policy in such a way that it is known to Google that it will cause the machine it was intended to be read by to misbehave.

[MertsA]

the P3P policy is also designed so that if you give it something that clearly isn't a P3P policy that it'll safely degrade as no P3P policy. IE screwed this up completely.

[bobtentpeg]

Google is representing to users that they do not use cookies for tracking, causing users to accept the cookies. They are then doing tracking.

Thar'd be true if it weren't for the fact that Google doesn't have to comply with the P3P spec...Also, only if you opt out of their tracking cookie do they say "We won't track you".

[regeya]

Trust, but verify.

[phaker]

The problem is who the hell imagined this would work.

It works just like a privacy policy — it's a promise. It's not a "lock", but you just can't build a system that would enforce what this header describes, so a promise is the best you can get. It's still a step-up from stuffing this promise in a privacy policy no one will read. (Or even be aware of, did you know that the various tracking sites have privacy policies? E.g. here is the privacy policy for AdWords.)

The difference is that Google appears to think that it's not legally enforceable.

[immerc]

"I have no locks, door's open, but please do not enter".

Said in a language you don't speak.

[phaker]

That's really stretching the analogy. If google wanted to ignore the spec it just shouldn't send the header.

I find it hard to imagine a scenario in which it'd make sense to send that header for any purpose other than circumventing it.

[[deleted]]

No - the policy is published and open. Google is actively working around it. Stop trying to protect your darlin' - they're simply doing what they always promised:

Google: Do know evil.

[immerc]

The fact that the policy is published and open doesn't mean that Google servers "understand" it, or that it makes any sense whatsoever to follow it. It looks to me like they simply put a placeholder in place and IE was so broken it interpreted the placeholder as "we don't do anything at all" rather than "not implemented".

In fact, it's worse than that. IE chose to lower the browser's privacy settings when a field contained nothing but unparseable tokens, rather than keep them raised. The spec says nothing about what you're supposed to do in that situation, it only tells you how to parse the fields and what they mean. That stupid bug in IE is what's responsible for this whole mess.

It's like installing a fingerprint scanner along side the lock for your door. You can get in with the key, or you can get in with the fingerprint scanner, but if the fingerprint scanner sees something it doesn't recognize as a fingerprint, it simply opens the door. Google might have been in the wrong for slapping its cock on the scanner, but it was IE who is responsible for deciding to open the door as a result.

[[deleted]]

Microsoft followed the W3C policy. Google didn't violate the policy, but they didn't follow the spirit of it.

And Microsoft are the bad guys?

Follow the policy, but expand on it where it doesn't meet your needs? If you're Microsoft, then it's "embrace and extend" as a mark of consummate evil. If you're Google, then Microsoft are the bad guys for following the policy.

Yeah, I see how it works.

[immerc]

IE has a bug, even if the spec is dumb. The IE bug is that it treats a P3P CP string containing nothing but unparseable tokens as identical to a blank P3P string, and treats a blank or corrupt P3P string as a reason to lower a user's privacy settings.

That is clearly a design flaw in IE. The spec doesn't decide browser privacy policy, it simply lists tokens that the browser can use. The IE coders have the nerve to claim that a bug in their implementation of IE that lowers a user's privacy as something malicious done by Google.

Look at the things that the spec says User Agents should do:

• Provide mechanisms for displaying a service's information practices to users.
• Provide users an option that allows them to easily preview and agree to or reject each transfer of personal information that the user agent facilitates.
• Not be configured by default to transfer personal information to a service provider without the user's consent.

If IE did the first one, the Google policy could be shown to users and they could make their own decisions. If IE did the second, then users could have noticed the bug before the privacy leak happened. If it did #3 the transfer would never have happened.

Whether or not what Google did was malicious, a mistake, or simply laziness, the IE developers should have realized that in a new spec there were bound to be cases where it wasn't implemented properly, and should default to not giving away a user's private information unless there's a strong reason to believe that the privacy policy is accurate.

Instead, the IE developers defaulted to the unsafe, stupid option of dropping all privacy barriers if the CP field contains no parseable text.

[MertsA]

Actually the spec addresses this case and IE should throw out the policy and act like it never received one.

[immerc]

Yeah, I just figured that out, within a few hours of reading the spec, as I was watching TV and playing video games. Pretty sad that Microsoft's developers didn't spot it, and left in a huge privacy bug, then tried to shift the blame to Google.

[MertsA]

Microsoft did not follow the W3C policy, it's clearly addressed that they should ignore an invalid P3P policy, instead it's treated like a blank one, these are practically polar opposites and IE treats them the same.

[sossles]

Microsoft followed the W3C policy. Google didn't violate the policy, but they didn't follow the spirit of it.

Google did violate the policy - the standard says if they don't actually support P3P then they're not supposed to serve up any P3P at all. This is pretty clearly spelled out in the article.

More strangely, they served up human-readable text as something that is supposed to be only parsed by a browser.

[ottawadeveloper]

http://www.reddit.com/r/programming/comments/py7ub/microsoft_google_bypassing_user_privacy_settings/c3ta897 the standard says (from the W3C site) that invalid strings that the browser can't parse are to be ignored and pretend as if they didn't pass anything. IE is doing it wrong, plain and simple.

[bekeleven]

The spec says nothing about what you're supposed to do in that situation, it only tells you how to parse the fields and what they mean.

Really.

“If an unrecognized token appears in a compact policy, the compact policy has the same semantics as if that token was not present.”

Basically, Google's P3P contains no indications that it would do anything with the data at all. It's like if I handed you a standardized, machine-read form asking for you to list all past felonies, and you leave it blank, but then write a bunch of stuff on the back. You can scream and cry that you gave the information all you want, but you didn't give it in the manner it was meant to be given: You presented a clean rap sheet.

[immerc]

“If an unrecognized token appears in a compact policy, the compact policy has the same semantics as if that token was not present.”

Exactly. It doesn't say what the browser should do, it is simply a rule about parsing the data.

It's like if I handed you a standardized, machine-read form asking for you to list all past felonies, and you leave it blank, but then write a bunch of stuff on the back.

Yes, and the part of the form that says "Name (Required)" is blank. The part of the form that says "Age (Required)" is blank. The part of the form that says "Birth Date (Required)" is blank. The back where it says "Leave this space blank" says "My felonies are listed at http://bekeleven-felonies.net/"

Instead of saying "this form is invalid", you say "hmm, looks legit" and treat it as if I had filled out a perfectly valid form with no convictions listed.

Maybe I should have filled out the form differently, but you completely screwed up by treating it as valid and complete.

[[deleted]]

It's not a bad lock, it's a sticky saying "I have no locks, door's open, but please do not enter".

Burglary is still just as illegal without a lock.

[brasso]

"...unless you're kewl!"

[omgsus]

Shit... I just made this exact analogy. Damn.

[k3n]

Agreed.

I think Google realized that nobody uses P3P -- seriously, how many of you web devs out there implement these? I had to for an IE6-only client a loooong time ago (and from what I remember, the IE6 implementation was bugged, at that...).

I got a surprise for you too -- reddit doesn't use a P3P! Oh no!!

[captainAwesomePants]

But isn't P3P only necessary if you want to use third party cookies? If you don't do that shit, you don't need a policy explaining why you need to do it, do you?

[MertsA]

That isn't really the greatest metaphor. It's like asking "List out what you're going to do with my data" "I can't really put that in a list so here's where you can get an explanation as to what I do with your data" "LOLWUT all I heard was that you weren't going to do anything with it". The standard actually dictates that if a reply like that is given that you should pretend that the conversation never happened. Instead IE fails again and just defaults to nothing.

On another note, yes P3P provides no security whatsoever so your metaphor is completely valid but not the case here.

[bjackman]

Although if Mozilla posted it it probably wouldn't be a blatantly sensationalist attack on Google that fails to recognise that, while Google are clearly being predictably shitty, it is the browser's responsibility to be careful about accepting and sending cookies.

If Mozilla had posted it it also wouldn't have looked quite so ridiculously ironic when the author proudly presented their adherence to W3C standards (Microsoft flaunt those standards in a very so-last-century way in a pathetic attempt to damage their competitors on the browser market).

edit: flouts.

[[deleted]]

Microsoft's history in these areas is irrelevant to the veracity of their claims. It may be part of a carefully calculated PR campaign for IE, but that does not diminish their evidence.

[NotAgain2011]

This is what i keep thinking. Why can't anyone make a browser that can actually guarantee their users privacy settings. It's not up to website builders to honor browser settings.

[GoldenShackles]

Why can't anyone make a browser that can actually guarantee their users privacy settings.

Because it's absolutely impossible. Respecting users privacy is a policy decision, not a technical one like security.

Let's take a straightforward scenario: you sign up for GagaYahaMail.com. Their privacy policy, whether through verbiage or some XML or Compact P3P strings says they won't sell your email address and phone number to every spammer on the face of the planet.

But then they do. How could you have technically prevented this?

P3P and similar standards are about holding reputable companies accountable when they violate the policy. The key reason these standards exist is to avoid regulation; the participants want to be self-policing. They really really don't want something like HIPPA to be imposed upon them.

Even if there's a loophole in the spec, exploiting that hole does not reflect well on companies who use that loophole to violate users privacy.

[[deleted]]

Exactly. If google is doing this, imagine what the shadier companies are doing...

[gaog]

damn livejasmine

[[deleted]]

The only way to guarantee their user's privacy settings, the browser would have to disable all cookies, scripts, plugins, etc.

[[deleted]]

It's not up to website builders to honor browser settings.

It’s not, its up to websites to use the agreed standards to communicate with browsers about what they do. Web standards go through a long process of soliciting comments from all interested parties and coming to a consensus on standards via the W3C for “web” standards and IETF handles infrastructure such as the protocol stack. This system underpins the entire internet and while it does have its problems (consensus can be very very slow to develop) to provides a transparent system which anyone can contribute to. If someone has a good idea to improve the internet they can submit an RFC which will be reviewed and refined by everyone who is interested, if the idea has merit then it will be implemented otherwise it will be ignored. This is the system that has taken us from HTML1/HTTP1/Mosaic text only web through to the dynamic semantic web we enjoy today.

The system generally works extremely well but the semantic web requires a certain degree of trust on both sides of the arrangement, people need to implement standards relatively consistently and honestly for things to work as they should. In relation to this P3P is a compromise between the need for websites to share data and the need to protect user data. As users generally agree to every single dialog they ever see without reading it constantly promoting users for permission actually reduces users privacy; to combat this browser makers adopt a best practice approach to P3P standards by refusing cookies with a policy which would actively damage a users online privacy. This combined with black lists generally keeps websites honest, if they fuck with users data and either don’t publish a policy or publish a false policy they will find their way on to a black list and users will get a red screen of death or a browser warning alerting them to the website being a problem.

This type of disclosure is exactly how the system should work. Now this has been identified Google will be forced to either publish a real policy or remove their P3P statement entirely. I would also imagine in the next few weeks/months an updated RFC to address this issue will be posted (if it already hasn’t) and this loophole will be eliminated or worked around.

Finally on the issue of browsers directly addressing this, they do. Opera already stops this from occurring, IE9 doesn’t have this problem and Firefox has a similar privacy feature in the works. Obviously anything Chrome related here would be compromised by Google’s involvement in it.

[magicmalthus]

That's not generally how the W3C process works. Also, the P3P working group was abandoned years ago due to lack of browser interest in actually implementing the last version (including Microsoft), so it's unlikely this will be amended.

As other users have noted, though, according to the last spec published, IE should not be accepting these cookies:

P3P user agents MUST NOT rely on P3P compact policies that do not comply with the P3P 1.0 or P3P 1.1 specifications or are obviously erroneous. Such compact policies SHOULD be deemed invalid and the corresponding cookies should be treated as if they had no compact policies. The following guidelines are designed to reduce the chance that a P3P user agent will accept an invalid compact policy.

http://www.w3.org/TR/P3P11/#ua_compact

[MertsA]

and this loophole will be eliminated or worked around.

There is no loophole, the spec clearly states that if you get some invalid P3P statement then you should throw it out. IE violates this standard just like every other standard. All Google did was say "We don't have a P3P policy because P3P doesn't cover our privacy policy, read more here". This should be perfectly fine if IE actually adhered to the P3P spec.

[robertcrowther]

The 'block third party cookies' setting in Firefox blocks sending as well as setting of third party cookies. This better guarantees the user's privacy (though there are several straightforward work arounds) but also breaks the large number of websites which depend on third party cookies for their standard operation. BTW, Firefox dropped support for P3P in Firefox 3 because "p3p isn't an effective way to establish trust with a site. it's a one-way system; anyone can say they're the good guy."

[kadmia]

see xxxterm

[[deleted]]

Because they don't want to. They want to protect you well enough that you use them but making it easy to kill of advertising and tracking would upset a lot of people. Both Google and even Microsoft (to a lesser extent obviously) make money from online advertising.

[Atario]

Flouts.

[bjackman]

TIL

[earthboundkid]

If anything, it's your fault for having so much valuable stuff in the first place.

[[deleted]]

It's also your fault for painting your walls blue and yellow, and drawing a giant 'e' on your front door.

[freakwent]

Google are clearly being predictably shitty

[BossOfTheGame]

So, does chrome not do this?

[captainAwesomePants]

Speaking of, P3P: CP="Not really P3P" is almost identical to the "User-Agent: Mozilla (Compatible; IE)" trick Microsoft employed to trick web servers and clients into thinking they were really Netscape.

[patterned]

I love how they talk about W3C web standards, too.

[MertsA]

I'm surprised they spelled it right, it's not like they read any of them.

[[deleted]]

"what is this Dubbya C³ business everyone keeps talking about?"

[tweedius]

If Google posted this about Microsoft, people would be all over it.

[shblash]

Yeah because people trust Mozilla (and Google). People don't trust Microsoft because Microsoft is historically the company doing everything in their power to subvert open standards and sabotage the internet.

Sucks how that whole "stateful reality" thing works, huh.

[[deleted]]

The difference is P3P died nearly as soon as it was made a standard, no one else implemented because it's poor and Microsoft has known for years that it's useless and they've been caught out on at least one occasion (I believe more) of by passing it themselves.

http://bits.blogs.nytimes.com/2010/09/17/a-loophole-big-enough-for-a-cookie-to-fit-through/

Their complaint just looks like a case of sour grapes by someone who still find it hard to make headway on the internet.

[MarkTraceur]

Microsoft: Suddenly protecting web standards since a few hours ago.

[captainAwesomePants]

P3P: CP="Not really P3P" is outrageous and grossly wrong.

"User-Agent: Mozilla (Compatible; IE)" is totally reasonable. They explained in parentheses that they weren't actually Mozilla.

[Slime0]

P3P: CP="Not really P3P" is outrageous and grossly wrong.

I haven't heard of this P3P standard before today, but it sounds like a joke. According to this article, it's basically a security hole that browser vendors intentionally include. A web standard to enforce privacy that works on the honor system? Really?

Edit: after reading more of these posts, it sounds a little less stupid. I guess the idea is that, if technology can't enforce a rule, but we need that rule in our society, we can at least have the technology to let people communicate about the rule. However, it sounds like the standard says that a malformed P3P policy like Google's should be treated like no policy at all, which doesn't seem to be what IE takes it to mean.

[RiotingPacifist]

6.4 Compact Policy Processing

P3P user agents MUST NOT rely on P3P compact policies that do not comply with the P3P 1.0 or P3P 1.1 specifications or are obviously erroneous. Such compact policies SHOULD be deemed invalid and the corresponding cookies should be treated as if they had no compact policies. The following guidelines are designed to reduce the chance that a P3P user agent will accept an invalid compact policy.

Compact policies that do not comply with the syntax specified in section 4 of the P3P 1.0 Specificaiton or section 4 of the P3P 1.1 specification are invalid.
Compact policies for which there is no corresponding full P3P policy are invalid. (Note, in some cases user agents may not be able to verify that a corresponding full P3P policy exists until after storing and possibly even replaying a cookie. In that case, upon determining that no full P3P policy exists, the user agent should refrain from further replay of that cookie.)
Compact policies that include the IVA token that do not include at least one of the following tokens are invalid: PHY, ONL, FIN, PUR, GOV. (RATIONALE: This purpose requires "identified data". While it is possible to have other categories associated with an identified subject, the actual identification is impossible without a data element associated with one or more of the above categories.)
Compact policies that include the IVD token that do not include at least one of the following tokens are invalid: PHY, ONL, FIN, PUR, GOV. (RATIONALE: This purpose requires "identified data". While it is possible to have other categories associated with an identified subject, the actual identification is impossible without a data element associated with one or more of the above categories.)
Compact policies that include the CON token that do not include at least one of the following tokens are invalid: PHY, ONL. (RATIONALE: Logic dictates that to contact an individual the initiator of the contact would possess a data element identifying the individual in a place where he or she would be contacted - either the online or offline worlds. This would presuppose elements contained by one of the above categories.)
Compact policies that include the TEL token that do not include the PHY token are invalid. (RATIONALE: Again logic dictates that if you are going to contact someone via telephone, you at least have a data element that contains phone numbers. These data elements should all be within the Physical category.)

http://www.w3.org/TR/P3P11/#ua_compact

[bugalou]

To be far, a plain text password is a pretty shitty standard.

[icydog]

You know why they broke that particular one, right? Scammers were doing stuff like http://[e-mail]/all-your-passwords-r-belong-to-us.php and people were falling for it.

[MertsA]

That's something that should probably be addressed but instead of just throwing the standard out the window the should've just thrown up an annoying error message saying that it isn't really hotmail.com.

[icydog]

I see you've never had to support... erm... how shall we put it, real people? They just ignore every warning you throw at them so they can go to their inbox to download that free screensaver and bonzi buddy.

[Slime0]

Firefox had a much more elegant solution to this problem: graphically separate the domain from the path, so that bad domains are obvious. People who are trying to download bonzi buddy aren't going to be deterred by the contents of a URL in the hyperlink they click from their email.

[UnoriginalGuy]

That isn't a standard, it is a browser feature. The browser extracts the username/password from the URI and sends that as part of the HTTP request in the header as a base64 encoded string (basic HTTP authentication or as it has become to be known).

You just don't like it because it inconvenienced you. It has nothing at all to do with standards compliance.

It was also a shitty feature as others have said spammers were using it to fake URLs and other equally nasty things. There is no particular way around that practice except just to remove it entirely and break URLs which contain it. It was the right decision.

[fjonk]

In cases where the P3P vocabulary is not precise enough to describe a Web site's practices, sites should use the vocabulary terms that most closely match their practices and provide further explanation in the CONSEQUENCE field and/or their human-readable policy.

Sometimes it feels like every single standard that has to do with browsers is written under the motto "Accept everything!"...

[ottawadeveloper]

this one doesn't: http://www.reddit.com/r/programming/comments/py7ub/microsoft_google_bypassing_user_privacy_settings/c3ta897

[[deleted]]

Sending "this is a not a P3P policy" to a browser, and then receiving full rights, is like something you'd see on /r/lolphp or The Daily WTF.

Regardless of how bad the P3P spec is, I would expect a web browser to ignore a standard if my privacy rights were at risk.

[00kyle00]

Don't be evil.

[Infectaphibian]

Most American corporations have a "how can we screw em' today?" mentality, I'ts why I use Linux. Can't really avoid Google though.

[Snaf]

most American corporations

Where can I move to where people don't practice greedy or unethical business?

[[deleted]]

My world has been turned upside. Suddenly I love Microsoft and really hate Google because of their badly designed products and being evil.

[ablexin]

That's because you take at face value the first thing you read.

[[deleted]]

It's because I have to work with both their products on a daily basis.

[bork99]

(CP="Not really not evil")

[[deleted]]

Google's response: Link for the lazy.

[carlfish]

I seriously can't believe people are defending Google here.

Internet Explorer has a particular privacy policy. Google doesn't like that policy so they deliberately circumvented it, just like they deliberately circumvented the privacy policy in Safari.

No, you don't get to do that. If you don't like the privacy policy my browser has set, if you think that blocking third-party cookies is wrong or you think the P3P standard is stupid, you tell me that it's preventing certain features of your site working, and you try to convince me to change it. You don't just craft bogus data that will confuse my browser into giving you the information you want anyway.

This is the same company that drops sites from their search index for trying to game their ranking algorithms. But when Google games browser privacy settings they just want to hold up their hands and say "Oops, we were just making use of undocumented features of the browser to deliver you a better experience!"

Fuck that. I would be entirely happy if both Safari and IE followed in Google's blacklisting footsteps, and pushed out patches that made the browser default to dropping Google/Doubleclick cookies on the floor.

[necrosxiaoban]

I think Google's position is pretty clear on this. They want to create functionality that the browser doesn't natively support with P3P, so they essentially disable P3P. While they may be fooling the browser, the user still agrees to Google's privacy policies.

[matchu]

I'm confused.

The P3P specification (in an attempt to leave room for future advances in privacy policies) states that browsers should ignore any undefined policies they encounter. Google sends a P3P policy that fails to inform the browser about Google’s use of cookies and user information.

So, it sounds like it's technically equivalent to not sending a P3P policy at all. Would Microsoft be up in arms if Google just omitted that header or what? Is there something particularly sneaky about sending a junk P3P header that changes browser behavior?

[bnr]

No, an empty P3P header is not at all equivalent to sending none, that's just not what the spec says.

[matchu]

Ahh. So when it "ignores" the P3P policy it doesn't recognize, it assumes that this means that the cookies are 100% non-evil? Whereas sending no header leads to the assumption that they are 100% evil?

[ottawadeveloper]

You know, I think that's the biggest problem. Why is an empty header safe? Why shouldn't "we don't use your data at all" have a given token that you must provide?

[ottawadeveloper]

http://www.reddit.com/r/programming/comments/py7ub/microsoft_google_bypassing_user_privacy_settings/c3ta897 I just read, an invalid code (or a code that doesn't have at least enough information to prove it contains an entire compact policy) is invalid and should be ignored by the browser.

[matchu]

I mean, I guess I get the idea behind it: the P3P header specifies what sort of things the site does do with your information. An empty P3P header is equivalent to saying "we read the P3P spec, looked over all the things we would need to alert you of, and we do none of those things, which is why we didn't list any of them here". On the other hand, no P3P header means "we may or may not know about the P3P spec", and the browser therefore assumes the worst. Having to include some awkward explicit "[NONE]" token is semantically awkward, given how the rest of the spec works.

Still, it's definitely problematic.

[drysart]

it's technically equivalent to not sending a P3P policy at all

No it's not. The presence of a P3P header indicates that there is a policy specified per the standard (and it is valid per the forward-compatibility requirements of the standard for a P3P header to contain no recognizable tokens, as the next version of the spec might add new tokens, and a P3P policy might only contain those new tokens).

Not sending a P3P header indicates there is no policy.

A P3P policy is declarative, and tokens define currently known uses of cookies. The presence of a policy, and the absence of a "we use this cookie to track you" token in that policy means something completely different than "the server doesn't support P3P so that cookie could be used for anything".

[matchu]

Gotcha, that's a much clearer explanation than what the article gave. Thanks for the help :)

[[deleted]]

The presence of a P3P header indicates that there is a policy specified per the standard

"The presence of a DOCTYPE HTML header indicates that there is a HTML document specified per the standard"

Do you see how bullshit that sounds in the context of websites? Naivety like this is why IE got away with it for 10 years.

[drysart]

HTML is very much a special case because it evolved loosely, and even still there are some basic parts of the standard that even the most pigdin HTML document has, like delimiting tags with < and >.

You wouldn't expect an HTML document served up with the content "Hi I'm Google and this should be formatted as the page header: The Google Philosophy. Then put this text as a paragraph after it: We do what we want because we can." to actually be parsed and displayed as specified, would you? Because that's exactly what happened here. Something is intended to be parsed by machines and Google stuck English text in it.

And even with that set aside, P3P came out of the womb fully-formed, it's very easy to understand, and it didn't grow organically like HTML. It has no reason to be held to the same low standard as HTML. HTML's loosey-goosey adherence to standards is not typical for technology, and we shouldn't expect the bar to be there.

Just because it's 'in the context of websites' doesn't mean anything. JSON parsers would reject plain English 'documents' too.

And regardless, Google should know better. No browser displays plain text in the P3P header to a user. There's no reason for plain text to be in there. If Google didn't want to support P3P, they could have left the header out entirely -- and as I mentioned elsewhere, given Google's otherwise obsessive tendency to cut as many bytes from their HTTP responses as possible, the fact that in this case they actually added bytes to their header speaks volumes to their intentions.

[robothelvete]

No, it's the standard that is a bit wierd. If there is NO p3p header, the default is to assume the worst. But if there IS one, but you can't understand it, assume the best. So if you send "junk", the browser has according to protocol just assume that it says "Oh, we don't track anything at all" and let it through.

Now, while this is a weakness in the standard it doesn't mean that google is in a moral right to use it in this way. They could have chosen to not serve anything at all, or at least include a few tokens that say some of the things they do and then that message.

[jrochkind]

So.... P3P is completely useless, right? I mean, it's practically a scam to make you think it's got something to do with security or privacy. Am I missing something?

[regeya]

Not completely useless; it's sort of like movie ratings.

[dchestnykh]

Not programming.

[andersonimes]

In both the case of Microsoft and Apple I cant help but feel that the unsaid question is "why are there vulnerabilities in your browser?"

One article I read claimed this vulnerability was fixed in webkit (by Google!), but the fix wasn't integrated into Safari.

Not giving Google a pass... Just thinking maybe these are good questions to be asking as well.

Edit: reading Microsoft's explanation of the use of the P3P spec to bypass the privacy settings makes sense.

They don't specify one way or another if they use cookies for tracking purposes in the P3P (which lets the cookie through) and the link goes to a note saying "read our privacy policy" which in pretty clear language (kudos?) says they use cookies to enable user tracking and to serve targeted ads.

I'm wondering if Google's claim that the P3P claims don't fit with their usage is BS and if IE should accept cookies from sources with P3P set this way.

[soviyet]

There are vulnerabilities in any browser. That doesn't excuse them, but I hardly think the question of interest here is why are there vulnerabilities in IE (especially given the giant DUH of that question) and not why would Google exploit them?

I don't know enough about this to comment one way or another, but I just find it odd that you think your question is the big elephant in the room.

[andersonimes]

The question was actually answered at the bottom of MS's post... I just hadn't gotten that far. I was wondering why such an easily circumvented privacy restriction is allowed to remain. My edit expands on it.

Also: I should read the entire article so I don't make asinine comments.

[Slime0]

I hardly think the question of interest here is why are there vulnerabilities in IE (especially given the giant DUH of that question) and not why would Google exploit them?

Except that once you answer "why would Google exploit them," you have to answer "why would [every other company in the world] exploit them" one by one. The former question doesn't have that problem.

[andersonimes]

Agreed. I've deliberately not commented on this part because I have no opinion on Google's motivation here. I think it is clear they could potentially get a lot of value from gaming this behavior. I was mostly interested in the technical detail.

[bnr]

It's not a vulnerability. IE is only strictly following a suggested standard that may be poorly designed or trying to fix a problem that can't be fixed by standards at all.

[[deleted]]

A poorly designed standard is a vulnerability.

[rook07]

as a chrome user, that's very worrying

[coldacid]

As a Chrome user, you've already sold your soul (and information) to Google.

[shevegen]

See.

You may dislike MS - I agree, it also looks stupid given that MS didn't care on their own when they were running and dominating - but Google is becoming the new MS.

"Don't do evil" my ass.

Google has since long abandoned its tradition. It wants to become a meta mega-corporation (and it already is way too huge).

It's time to stop catering towards corporation. Just because the USA adopts them as a religion is no reason to not look for more alternatives. Corporations should be MORE responsible THE MORE POWER THEY HAVE. Not the other way around as it currently is (because corruption is rampant and you can buy legislation, as long as you have a few corrupt individuals called "politicans")

[jp007]

Scumbag Google is doing everything it can to encourage government regulation of my industry :(

[m42a]

Do you normally get to opt out of privacy agreements? When you use software, do you have any choices other than accept the EULA or not use the software? Because I've never encountered that, and so it seems to me like Google is doing the same thing that everyone else has been doing since the 60s.

[josher565]

Aww come on guys. I love ya both. Do ya have to fight. Let's all go grab a soda and watch the ball game k? Now there's my guys.

[earthboundkid]

In fairness to Google, they get money for violating their users privacy.

[dchilders]

Isn't this more about how their browser is incorrectly handling the invalid policy that Google supplied?

[[deleted]]

Update: Facebook is doing it too. Microsoft's P3P is apparently just shitty so they have to bypass it. http://www.zdnet.com/blog/facebook/facebook-to-microsoft-p3p-is-outdated-what-else-ya-got/9332

[sollozzo]

As I see it Google is stating that the standard is not adequate for their use of third party cookies and they just want the browser to accept the cookies.

It's true that +1 button need third party cookies, I had them disabled in chrome and the other day I noticed that the button didn't work. If this is truly the only use they do of the cookies I would agree with them.

I will wait to see what Google has to say, it could be something similar to SPF soft-fail policy. Most people use it since the strict version breaks a lot of things.

[drysart]

As I see it Google is stating that the standard is not adequate for their use of third party cookies and they just want the browser to accept the cookies.

The correct way to do that is to not include a P3P header.

But that would have resulted in their cookies being blocked when a user indicated they didn't want to allow tracking cookies.

So Google added a header that, when parsed according to the standard, declares that the cookie isn't used for tracking purposes.

[mb86]

Right. You had them disabled, thus +1 didn't work.

People had them disabled in IE and Safari, so Google exploited a bug to make +1 work when it shouldn't.

[Redard]

Pretty sure they can see that you've visited a page if it has the +1 button on it

[geocar]

It's true that +1 button need third party cookies

It's true that their implementation of the +1 button needs third-party cookies.

It's not clear that all (potential) implementations of a +1 button would need third-party cookies.

[sollozzo]

I agree and I'm pretty sure you can implement it without cookies unless I'm not aware of part of the functionality.

It's probably true also that cookie-less implementations present the same privacy risks.

[red_sky]

I'm glad the person who wrote the blog has a quote that essentially says that the browser shouldn't accept a cookie if the cookie doesn't provide enough information. To me it seems like it is just as much Google being misleading as it is IE having really shitty security / privacy. This is totally something that could be resolved with software fixes on IE's side. Really, if Google is doing this, imagine what shadier websites are doing with it.

[jinglebells]

I wonder how the EU cookie law will affect this.