Re: Well known URIs and large sites

Hi Matthias,

The truth is that nothing is going to be "Simple" -- it's all relative :)

I think the response headers would be "simpler" than the alternative.

I think what I would envision is perhaps a fixed-set of "simple, well known
default policies" that you could specify in a response header. If you have
something more complex, you can specify your own identifier that points to
a policy hosted under /.well-known/dnt.

As for whether there's something that lives in a "default site policy" at
/.well-known/dnt (with no arguments or anything else, just
/.well-known/dnt) that would apply in the absence of anything else, I think
that's fine as long as it can say "No, you really need to fetch the
specific policy I've included in my response as my site is too complex for
a single policy".

-Ian

On Wed, May 9, 2012 at 9:05 AM, Matthias Schunter <mts-std@schunter.org>wrote:

> Hi Ian,
>
>
> thanks for this feedback. I understand that it may be dificult.
>
> Quick questions:
> - Would response headers be simple/OK for you to handle?
>
> If this is the case, I see two alternatives:
> - one may consider posting a default via a single/fixed well-known URI
> (not the whole space) and the provide the specifics via the header.
> - one may consider to permit headers stand-alone without info at the
> well-known URI.
>
> Opinions/Feedback?
>
>
> matthias
>
>
> On 09/05/2012 17:31, Ian Fette (イアンフェッティ) wrote:
> > This email is intended to satisfy ACTION-193
> >
> > The current proposal requires duplicating the entire website's
> > namespace under /.well-known/dnt/ -- that is to say, if you
> > request
> https://apis.google.com/_/apps-static/_/js/gapi/googleapis_client,plusone/rt=j/ver=OjdQ3MbDCro.en./sv=1/am=!uchpBK-CNFmZrNLZSw/d=1
> > <
> https://apis.google.com/_/apps-static/_/js/gapi/googleapis_client,plusone/rt=j/ver=OjdQ3MbDCro.en./sv=1/am=%21uchpBK-CNFmZrNLZSw/d=1
> >
> > I have to have a policy file
> > under
> https://apis.google.com/.well-known/dnt/_/apps-static/_/js/gapi/googleapis_client,plusone/rt=j/ver=OjdQ3MbDCro.en./sv=1/am=!uchpBK-CNFmZrNLZSw/d=1
> > <
> https://apis.google.com/.well-known/dnt/_/apps-static/_/js/gapi/googleapis_client,plusone/rt=j/ver=OjdQ3MbDCro.en./sv=1/am=%21uchpBK-CNFmZrNLZSw/d=1
> >
> >
> > This is difficult for large sites for a number of reasons.
> >
> > 1. Parts of the URL might be used as transitive data, e.g. not
> > actually representing an actual file but rather arguments to be passed
> > to the server. This essentially means that I need to query whatever
> > frontend service handled the original request, and the parameters
> > specified as part of the URL may or may not still have meaning at that
> > time.
> >
> > 2. The policy might depend on query parameters which in the current
> > draft are not sent, e.g.
> > both
> https://www.google.com/search?source=ig&hl=en&rlz=&q=microsoft&btnG=Google+Search
> > <
> https://www.google.com/search?source=ig&hl=en&rlz=&q=microsoft&btnG=Google+Search
> >
> > and
> https://www.google.com/search?sugexp=chrome,mod=12&sourceid=chrome&ie=UTF-8&q=microsoft
> > <
> https://www.google.com/search?sugexp=chrome,mod=12&sourceid=chrome&ie=UTF-8&q=microsoft
> >
> > represent searches on Google for "microsoft" but come from different
> > sources and therefore may have different logging policies (one came
> > from iGoogle, the other from the Chrome omnibox). We may potentially
> > need query parameters in this case to figure that out.
> >
> > 3. Creating this duplicate namespace now means I've got additional
> > mappings/rules for my load balancers / frontends, depending on how
> > much flexibility you have this may be a small overhead or if may be
> > quite large.
> >
> > 4. A URL that is used in both first and third party contexts certainly
> > has no way of knowing if it was used in a first or third party context
> > under the current proposal. (Whether a site can know at all if it is
> > 1st/3rd party in any reliable manner is still in the current draft an
> > open issue AFAIK though).
> >
> > What I had proposed in earlier discussions, and what I still maintain
> > would be more workable for some large sites, is to instead have the
> > request return (perhaps as an alternative to the current well-known
> > location proposal) a "policy identifier". That is, the response could
> > include something like 'Tk:3,maps' and then if the client cared it
> > could fetch /.well-known/dnt/maps to get the policy identified by the
> > token "maps". This avoids the problems 1-4 listed above as at the time
> > of serving the request, I believe a site has at that point better
> > information about what policy applies to the request than being asked
> > at a random later point in time at a different address.
> >
> > -Ian
>