action-317, discussion of the service-provider flag and the same-party resource

This discussion started in <>.  This is the reference I was searching for on the call today.

I want to remind people we're not talking about 'all' kinds of service provision here.  We're specifically not talking about ISPs, hosting, content authoring, or anything EXCEPT services which are distinct end-points of HTTP transactions.

The basic problem we're trying to avoid is having a sensitive user and/or user-agent flag a site as suspiciously claiming rights it doesn't seem to have -- either first-party status when it's not the first party, or consent when it doesn't appear to have 3rd-party-with-consent status.

Let's take a simple hypothetical example. offers a 'basic' and a 'pro' service. They provide 3 levels of service; free, basic, and pro.  Free service gives you an widget iFrame you can embed, that visibly counts visitors.  Contract for basic, and they will provide you a report on your visitors -- silo'd, and so on -- but the domain is  still theirs.  Pro, and they'll register under visits.<yourdomain>, and also provide cookie analysis, and so on.

For the basic service, they look like a different site, different party.  And they appear under that name on multiple sites, say and and could add them into their same-party array, but if they add both examplebank and examplenews into their same-party array, that appears to be a claim that those two are 'the same party', which is not true.  If they don't add them, we have no indication or back-pointer.  Even if they add dynamically, somehow detecting where they are embedded, the risk remains, I think, that someone will join these later.

Adding the 'I am a service provider' flag to their response, however, can help make it clear that they stand in a *service provider* relationship with some or all of the sites in the same-party array.

Big sites can afford to pay for 'pro', so the argument that the flag discriminates in favor of the large doesn't hold.

What am I missing?

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 29 November 2012 00:07:50 UTC