Tracking status resource /.well-known/dnt instead of /.well-known/dnt/{+status-id} for simple non-tracking static websites.

[rvaneijk]

For static, static-hosted websites (e.g. a S3 static website) it should - IMHO - be possible to express non tracking through the tracking status resource /.well-known/dnt instead of /.well-known/dnt/{+status-id}. The file must contain a tracking status representation of the static non-tracking website containing properties that describe the tracking status applicable.

For example https://natuurlijkehaarkleuring.nl/.well-known/dnt containing:
{
"tracking": "N",
"policy": "https://natuurlijkehaarkleuring.nl/cookies/index.html",
"controller": "https://natuurlijkehaarkleuring.nl/privacystatement/index.html,
"same-party": ["natuurlijkehaarkleuring.nl","www.natuurlijkehaarkleuring.nl",
"natuurlijkehaarkleuring.nl.s3-website.eu-central-1.amazonaws.com",
"d3789f38w6809i.cloudfront.net",
"hello.myfonts.net","api.tiles.mapbox.com"]
}

[michael-oneill]

We should clarify whether the the trailing / is required. I would say it should not, /.well-known/dnt should return the same result as /.well-known/dnt/

A connected issue is the request specific (or dynamic) response {status-id}. I think a better way to signal a different TSR is to embed it in the Tk header.

I suggested in #11 that the TSR is logistically difficult for large multi-site (brand) companies to arrange for a policy resource such as the TSR to be located on all of their domains, and we should have an alternative way to deliver it via a meta tag or within the Tk header. This would only take effect if the well-known resource was absent.

Maybe we could combine these and say that a request specific response should be to deliver the TSR as encoded JSON in the Tk header i.e.

Tk: N{"policy": "/privacy-policy.htm", ... }

i.e. everything after and including a "{" is the TSR. The "tracking" property would be redundant as it is already in the header. If the header was present there would be no need to query the well-known location.

The advantages would be:

1. no additional round-trip to get the TSR
2. the request specific response is simpler to explain and implement
3. the TSR can be delivered efficiently in content by encoding it in the content of an http-equiv="Tk" tag
4. this ties in with ongoing webappsec work on origin-wide manifests (to handle "header bloat" especially with CSP).

[npdoty]

@rvaneijk I think the status ID is already optional, isn't it? If your resource is site-wide, it can be present at .well-known/dnt and you're good to go.

[rvaneijk]

@npdoty But the spec says /.well-known/dnt/ which seems - I think - not the same as /.well-known/dnt
If a static file at /.well-known/dnt is allowed in the spec, I am fine and the issue can be closed. Otherwise, I propose an editorial change to remove the '/' at the end of the well-known resource.

[royfielding]

The identifier is "/.well-known/dnt/". That can be implemented as a static file, configuration directive, module, whatever ... how it is implemented is not relevant to the identifier. The reason the slash is included is because we also want to enable resource-specific TSRs and most servers enclose configuration contexts within directory spaces, which makes it easier to ensure that none of the requests within that space are tracked. In Apache httpd, a static file named index.json would used to create the default response for "dnt/".

[royfielding]

and a request for "/.well-known/dnt" would be redirected to "/.well-known/dnt/" (this is done automatically for filesystem-based implementations). Hence, the specification is correct as is.

[rvaneijk]

Thanks for the clarification. I misunderstood the spec. I changed the test implementation. The static resource on the test site on AWS now returns https://natuurlijkehaarkleuring.nl/.well-known/dnt/ a JSON. Issue closed.

[mschunte2]

Thanks a lot for the discussing and resolving this issue off-line.