Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Why do you need a .well-known? #3

Open
mnot opened this issue Oct 20, 2023 · 1 comment
Open

Why do you need a .well-known? #3

mnot opened this issue Oct 20, 2023 · 1 comment

Comments

@mnot
Copy link

mnot commented Oct 20, 2023

If discovery is via link@rel, why do you need a fixed URL for the resources?
@mikewest
Copy link
Owner

Hey Mark! Great question. There's some conversation on the topic in a separate thread (CC @othermaciej, @bvandersloot-mozilla, @annevk). I'll paste in my last comment here, but skimming that thread would be helpful for context (privacycg/proposals#39 (comment) in particular).

While I think that sites generally have a single policy document they point to for their behavior on a given platform, I agree that the concern you and @bvandersloot-mozilla raise is reasonable. If we end up deciding that the link type is the only thing we need, great. :)

Broadly, I have three kinds of answers for you:

  1. .well-known files can be discovered on hosts that don't otherwise serve HTML (analytics services, for example).

  2. The cases of conflict you're worried about will occur even if we only have link annotations. A page might have a <link> in its <head> that points to one policy while an <a> in the footer points to another, another pages might have multiple <a> elements, etc. .well-known has the advantage in this case of being singular by design, but even in that case servers could send one Location to crawlers and another to users.

  3. The specificity and scoping of a .well-known file and <a rel="..."> differ meaningfully in ways that I think are helpful. Because .well-known is scoped to an origin as opposed to any particular resource on it, it seems reasonable to me to establish the expectation that it can meaningfully be interpreted as demarcating an outer boundary of data collection and usage behavior for all the origin's resources. Individual pages might tighten that policy (e.g. "Data collected via this specific application on site.example will not be used by other applications on site.example."), but I think it would be strange to broaden policies on a resource-by-resource basis.

So, I agree that the conflicts you're pointing to can and will happen. This seems to me like a policy problem whose risk we can mitigate at that layer by defining expectations around this mechanism more clearly, and relying on non-technical actors in the ecosystem to help us create incentives for correct usage.
@mikewest mikewest mentioned this issue Oct 25, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants
@mikewest @mnot