

Facebook and many other sites also bypass Internet Explorer privacy controls - nikcub
http://nikcub.appspot.com/posts/facebook-also-doesnt-honor-p3p

======
magicalist
> Microsoft explicitly called out Google for their behaviour but either
> neglected to mention or didn't investigate Facebook (skeptics may believe
> that this is because of Microsoft's shareholding in Facebook and their
> partnerships in search and advertising)

I have trouble believing that they didn't check any other websites when they
were preparing that blog post (and facebook would be the obvious next choice
to test), but another reason not to mention facebook may be that not many
people would notice the effect of the doubleclick cookie's _absence_ in the
ads that they see, but most people who use Like buttons (and facebook embeds,
etc) _would_ notice when they suddenly stopped working.

So if people did use that new IE9 blocking feature with the suggested addition
of google, and then facebook and all the sites found here were added
too...you'd get the theoretical hit to facebook revenue, yes, but you'd get
the definite hit of users all thinking your browser is broken because it won't
load Facebook anywhere but facebook.com. Imagine those support tickets.

(I believe this kind of interaction is almost the exact reason Mozilla decided
not to block third party cookies by default and why Apple decided to add the
exceptions in Safari...someone posted a bug earlier with an Apple engineer
arguing for the exceptions specifically because of Facebok and Microsoft Live
logins, among other things).

edit: the bug was in comments on the ars coverage:
<https://bugs.webkit.org/show_bug.cgi?id=35824>

~~~
eli
I doubt Facebook shares have anything to do with it. Microsoft wanted to
embarrass Google, but the alleged crime is very common because IE's
implementation of privacy controls is flawed.

~~~
CWuestefeld
_IE's implementation of privacy controls is flawed._

It really doesn't matter what MS does; they get bashed either way.

In this case, their implementation is perfect: afaik, they're the only browser
that actually follows the spec. FF, Chrome, etc., are just ignoring the
standard. The problem here is that it's a really stupid standard, so that
implementing it correctly results in brain-dead "protection". But Microsoft
played by the rules, and now gets grief for it.

~~~
rbanffy
They played by nonsensical rules and got grief for it. It's kind of fair,
actually.

Yet, I refrain from criticizing them - P3P is a broken standard, but Microsoft
followed it. I'm criticizing them for singling out Google when, in fact,
ignoring P3P or actively disabling it is widespread practice.

I'm surprised live.com doesn't do it.

~~~
robertc
I think live.com does (or did) do it. See page 8, second column of the CMU
paper in this reddit comment:
[http://www.reddit.com/r/technology/comments/py9h5/now_google...](http://www.reddit.com/r/technology/comments/py9h5/now_google_caught_bypassing_user_privacy_settings/c3t9703)

~~~
DaveMebs
It's really unbelievable how this paper keeps getting cited as proof Microsoft
is doing this too. Page 7 was cited on the other thread; you can read my
response here: <http://news.ycombinator.com/item?id=3615267>

Re: Live doing it too. No, that is not what the paper says. From page 8:

"Only one of these websites, microsoft.com, displayed a full P3P policy."

"Websites under the msn:com domain exhibited a CP that includes the invalid
CUSo token. Two other Microsoft owned sites, microsoft:com and windows:com use
the same CP. These websites display the TRUSTe EU Safe Harbor Privacy seal. We
believe that these websites are likely attempting to comply with P3P; however,
they are not using P3P properly."

"The live.com CP does not include any ACCESS tokens. This CP suggests
collection of PII, but does not provide any information about whether users
can access their personal information."

Microsoft does not always fully comply with the letter of the law, but based
on everything that I have read in that paper, they sure seem to be trying to
comply with the spirit. It's ridiculous to claim that sending a deliberately
misleading P3P header is the same as sending a P3P header that suggests PII is
used but does not provide the access policy. One is designed to exploit a
weakness in P3P and avoid blatantly lying to browsers in order to track users.
The other indicates that PII is used, but does not fully specify how this is
used. It seems fairly clear that one company is at least trying to support
P3P, even if they are unable to completely reflect their privacy policy with
these tokens. To claim these situations is analogous is fairly dishonest IMO.

(NOTE: Page numbers are based on the PDF document for quick access. Subtract 1
for the number printed on the bottom of the page.)

~~~
robertc
_It's really unbelievable..._

It's not really that unbelievable: Microsoft is berating Google for sending
invalid P3P headers and this paper describes that Microsoft is sending invalid
P3P headers.

 _Microsoft does not always fully comply with the letter of the law..._

In this case what constitutes the letter of the law isn't really clear. As far
as I can tell this is the latest specification for the P3P header:

<http://tools.ietf.org/html/draft-marchiori-w3c-p3p-header-01>

I'm going to quote a small portion:

 _This Internet-Draft will expire on August 6, 2002._

So it's at least arguable that there isn't a standard for the P3P header, and
whatever anyone wants to put in it is just whatever they put in it, nothing is
invalid and everyone is fine.

Only IE supports it anyway, and it's not like it prevents websites from doing
things they've said in their P3P headers that they're not going to do. And the
header is required to make IE accept 3rd party cookies (which are needed for
lots of quite normal stuff on the web) you need to send it one of these
headers.

RFC 6462 also has some interesting comments:

<http://tools.ietf.org/html/rfc6462#section-4.3.2>

------
stiff
The article makes it sound a bit like the big companies are doing something
very evil to the users data just because they are evil and greedy. I
encountered this problem in my development work, and in reality it's much more
complicated, while some companies might well be evil and greedy, the real
problem is that the means available in the browser for doing cross-domain
integration of web services while controlling privacy are really poor.

The P3P header is just a formal way of describing the companies privacy
policy. Now, the problems is that when targeting MSIE, there is no way for a
company to make their P3P header honestly reflect their existing privacy
policy and still do integration with a third-party vendor on their page,
because if the privacy policy described in the P3P is not restrictive enough
IE blocks the cookies and there is nothing you can do about it, there will not
even be a popup window for the user to decide what he wants do about it, it
simply won't work.

Example: let's say you want to embed a facebook widget or whatever in your
page and you have to do it via an iframe because that's the way facebook
supplies it (and it might well be that for technical reasons no other way
would work OK for both facebook and you). Then, after the user does something
with the widget, you want your page to be called again, while maintaining the
users identity (with the user still being logged-in in your page). This works
well by default in all browsers, except for IE, which without the privacy
policy being restrictive enough (as described in the P3P header sent by your
page), will simply ignore the session-id cookie and log the user out in the
iframe.

I don't think with a well thought out security model companies should have to
make such a choice between functionality vs. having a specific privacy policy,
those things should be completely independent. If the user actually wants to
use third-party integration on a page supplied by a company with a not very
restrictive privacy policy, why should the browser prohibit it? This is
commonly needed, and currently the only way in MSIE to fix it other then
sending an adequate P3P is AFAIR to lower the security settings, which most
common users don't know how to do, and of course as a company you wouldn't
like to recommend your users to lower their security level anyway. The browser
should make sure the user knows what is going to happen, but then give him a
choice and stay out of the way if that's the user wish.

~~~
Drbble
Google could display a message in page, like they do when first party cookies
are disabled or when firebug is running. Instead, they chose to "jailbreak"
themselves and not even tell the user what they are doing. Google makes a
tickertape parade of yellow see sticky notes every time they change the shade
of grey in a form button, it is quite telling that they are ashamed of
admitting "

~~~
stiff
They in fact cannot even display a message, there is no way AFAIK to
distinguish between this situation and someone simply not being logged-in.
Even if they could, they would still leave IE users without some
functionality. Again, I do not want to be Google's advocate and I do not know
their specific use cases, I am just saying they are legitimate use cases for
both not having the privacy policy that restrictive (eg. when processing and
passing over the users data is actually part of the buisness model) and for
doing third party integration, which the security model as implemented by MSIE
makes impossible to handle.

------
wccrawford
Microsoft is in a bind, now. If they fix their security hole, the Like and +1
buttons will stop working on IE9, and only IE9. The solution to fixing them
will be 'use another browser'. The only solution.

So faced with losing market share, they instead chose to turn it around and
say that other companies are doing unethical things. When those companies stop
doing them, IE9 will stop working, but now it looks like those websites are at
fault, and not IE9.

The obvious solution is simply to explain why (and G and FB have already done
so) and let MS hang themselves with their own rope. MS's gambit won't pay off,
and they'll lose worse for having tried it.

~~~
jxi
Let's hope the true villains get rightfully punished.

------
tripzilch
So Facebook uses the exact same trick. They could have just omitted the P3P
header completely, but no they _must_ and _shall_ have 3rd party cookies so
they respond with an _invalid_ P3P header, just like Google.

The fact that the invalid P3P header contains the string "We don't support P3P
and here's why" is a red herring:

The _only_ reason why they would place a statement regarding their non-support
in the very header that they claim not to support, is to circumvent IE-users'
privacy policy. It's very disingenuous.

If you don't support it, leave out the header, if you want to make a statement
that says "We don't support the P3P header", don't put it in a place that
_really_ says

    
    
        "We disagree with the P3P header and believe in circumventing it. 
        Read why here: http://xyz"
    

If FB or Google's headers had said that, at least it wouldn't have been as
disingenious. Saying you don't support P3P--oops! and by saying that we broke
it! whoops!

It's a bit like placing a sticker "WE DONT SUPPORT READING THE LEFT HALF OF A
SIGNPOST" over the left half of a "NO ENTRY" sign. Childish.

It would be interesting if we could see that list of other 500 companies.
Because "there's 498 others that do it too" has a very different implication
depending on what sort of company Google and Facebook find themselves in by
acting in such a childish manner.

~~~
freehunter
If it's broken to begin with, it's not really "breaking the users security
settings". Specifically if it can be broken just by saying "break it", then
it's broken from the start.

~~~
tripzilch
In that sense NO ENTRY signs are also broken. And so is the robots.txt
protocol.

~~~
stanleydrew
But "No Entry" signs and robots.txt are broken for the same reason. We all
know that, so how is it a counterargument?

------
zerostar07
So it appears the problem has more to do P3P rather than anyone else. I wonder
how many other websites out there just send out the "required for cookies to
work" P3P headers regardless of what they do with the data they collect (i 've
blindly copy-pasted such headers in the past, but then again i don't abuse or
pass along any private information to third parties). Of course, relying on
websites' good faith to report what they plan to do with your data was a false
assumption to begin with.

~~~
antonyh
So you feel that it's kind of like asking a used-car salesman if it's a good
car?

Most people trust Google and Facebook. They don't really care about cookies so
long as it works. The trust has already been established by the brand.

------
meow
Follow the link that facebook provides in its header:
<http://www.facebook.com/help/?page=219494461411349>

It's very interesting. They straight out say P3P is a dead protocol. And from
the explanation of how it works, it does seem to be a joke - trusting third
party websites to honor user privacy ? seriously ? I think Microsoft is simply
trying to raise a shit storm over nothing... at least Safari one is a real
screw-up on Google's part...

~~~
rbarooah
Is it a joke to expect Google to honor user privacy?

~~~
freehunter
It's a joke for people to expect that P3P is a good privacy model.

~~~
rbarooah
From the parent: "trusting third party websites to honor user privacy ?
seriously"

That's what I was responding to. They seem to be suggesting that the idea of
trusting Google is absurd on the face of it.

------
gabea
I do not see anything wrong with Facebook or Google for setting false P3P
policies. As a developer of Facebook applications, and user of Google
Analytics the reality is that without this P3P headers hack in place, you will
A.) eliminate a gigantic portion of your IE users from using your site, and
B.) eliminate a gigantic portion of metrics data for those users.

In the case of A, I utilize the Facebook SDK which relies on the Third-Party
Facebook cookie passed into my application when it is loaded in a Facebook.com
iframe. Could I build my application a little different to not need this? Yes,
but this way is a little more reliable and secure. B.) Google Analytics breaks
for IE users when your application lives within any iframe. It relies on
Third-Party cookies to correctly track the users actions, and browser
information.

I am a big user advocate when it comes to protection of personal information,
but I really believe that unless users stop using IE (which is not going to
happen any time soon), or P3P is depreciated by Microsoft then for now it is a
useful hack to get around yet another IE pitfall.

------
arscan
Does anybody here know when Firefox (and other major browsers besides IE)
dropped the P3P standard? I certainly recall having to deal with this on most
(all?) popular browsers ~6 years ago. I'm curious if they silently dropped it
(because it does make the internet more useful, but more dangerous), or if
they actually gave rationale for discontinuing its use.

~~~
arscan
...and by "more useful", I mean "more profitable"...

------
socratic
What is the preferred way to handle P3P for a young startup or a small
(possibly academic) project?

As I see it, there are seven relevant facts:

1\. The intent of P3P is to make it so that you are personally, legally bound
to enforce particular privacy guarantees.

2\. The attempt to make a P3P standard has been abandoned for half a decade,
and only one browser maker supports it, largely for historical reasons.
Documentation and tooling for P3P is by-and-large about a decade old, and
advocacy seems to have dwindled down to a few people at CMU.

3\. Unless you send a P3P header with the right string of (potentially legally
binding) guarantees, it is not possible to use third party cookies with
Internet Explorer.

4\. P3P was intended for exactly the case of tracking cookies.

5\. Using a third party tracking cookie is often the best design decision for
a particular problem, even though other mechanisms could completely avoid the
need to handle P3P.

6\. Almost no one has actually changed their P3P settings from the default set
by their browser vendor.

7\. Users only care if functionality they want exists, whether or not there is
some esoteric "standards" reason why it does not exist.

So let's say you've got a new compelling piece of functionality you want to
offer. You're a startup or small project. You want to make it as easy as
possible for people to include your functionality with a single javascript
include. (Maybe you're Disqus? Maybe you're a new advertising platform? Maybe
you're a +1 button?)

Do you ask all of your users to include a piece of PHP code on their site so
that you can send data while having it appear to be first-party? Do you put up
a P3P policy that matches your intentions for the data? What are your
intentions for the data? If your intentions change, do you change your data
model to include what P3P policy the data was captured under? What is
personally identifiable information? Isn't pretty much everything personally
identifiable once you have enough experience with the user? If you even have
lawyers, do they have any experience with P3P, or do they just want you to
point to their extremely precisely written English document instead?

So I guess the six options are:

A. Implement your functionality in a way that is inconvenient for your users,
but completely avoids P3P. For example, ask them to install a PHP script where
you set first-party cookies for them.

B. Use third-party cookies and set a bogus P3P policy in your headers. Maybe
you copy it from the Internet.

C. Use third-party cookies and set an intentionally, obviously broken P3P
policy (just a link, as Google and Facebook do) pretending that you don't
understand P3P or linking to your real, English language policy.

D. Do the same as C, but actually include privacy controls on your site for
users who are willing to state them and log in.

E. Have an engineer spend a day guessing what P3P policy is most similar to
what you want to do at the moment and in the future, and then write the P3P
policy header files and XML and forget about it.

F. Get a lawyer and engineer to team up to implement P3P throughout your site.
Determine what each of the P3P options legally means in your context, figure
out which ones apply, and then ensure that every part of your infrastructure
handles the policy correctly.

~~~
barista
If I read correctly, the article says that of the top 10000 sites 95% do have
a valid P3P header. Does that make a decision any simpler for an aspiring
startup?

~~~
socratic
This is actually a good answer, in that it suggests that norms might be
important in answering the question. However, this [1] paper by some of the
authorities on P3P suggests that the answer might be less clear than you are
suggesting.

Specifically, these are the headline stats:

1\. 34% of websites have errors in their P3P compact header in that they
contain invalid, missing, or conflicting tokens.

2\. 79% of websites with P3P compact headers are missing full policy files,
which is required to be compliant.

3\. Among the top 100 websites, only 48 have P3P compact policies, and of
those, 41 have no full policy file, and 21 have errors making the header
invalid.

4\. 97% of invalid compact policies bypass Internet Explorer's default
filters.

5\. Vast numbers (thousands) of the valid compact policies are duplicates. In
fact, a little under 5000 of the approximately 20,000 compact policies that
are valid are the same policy (NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM)
which coincidentally is listed all over the web as a bug fix for IE's cookie
handling.

Reading between the lines, the norm here seems to be to either (a) not include
P3P (52% of top websites) or (b) include it as a bug fix in an invalid, non-
compliant way (21--41% of top websites). Is an invalid P3P header likely to be
legally binding if the overwhelming majority of websites of all sizes
implement it incorrectly, both intentionally and unintentionally? Is it worth
the time, expense, and potential legal risk for a small startup to try to use
it correctly?

[1] <http://repository.cmu.edu/cylab/73/>

------
markokocic
Sorry but this is insane.

The real question is why is IE allowing Facebook, Google and others to bypass
its privacy controls? Maybe beacause IE is not that secure. If your software
have security problems, please fix those problems instead of complaining that
others are exploiting them.

~~~
uid
P3P is based on trust. If Facebook and Google don't want to support it then
they should ignore it rather than subvert it.

~~~
tripzilch
True, but apparent "not including the header" gives you strict privacy
controls, while "including an invalid header" will set them wide open.

That _is_ a bit strange behaviour on IE's side as well.

------
niksuckspg
I wonder why it is necessary for you riff of every high ranking HN article.
Are we to be exposed to your "HN is just another Social Network" article? Or
will it be "How my high HN karma bootstrapped my socio-locale-mobile start-up
to 28k in the first weekend?"

As if ANYONE (over the age of 16) EVER was impressed by the ability to earn a
few thousand dollars in a weekend.

~~~
stanleydrew
Wow. I wish I could down vote this a thousand times. Here we have someone
actually contributing useful information in an unbiased way and you create a
throwaway account to complain? Shame on you.

