这是indexloc提供的服务，不要输入任何密码
Skip to content

Proposal for retrieving and observing topics via headers #81

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

Merged
merged 6 commits into from
Sep 27, 2022
Merged

Proposal for retrieving and observing topics via headers #81

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
20346a3
Proposal for retrieving and observing topics via headers
jkarlin Jul 15, 2022
0d38922
Some nits
jkarlin Jul 15, 2022
10655ca
Got carried away with adding sec-
jkarlin Jul 15, 2022
d6e8945
Nit: missing 'to'
samdutton Jul 18, 2022
dda12aa
Define redirect behavior
jkarlin Jul 19, 2022
695a213
Address comments
jkarlin Sep 27, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 13 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,19 @@ The topics will be inferred by the browser. The browser will leverage a classifi
* is secure
* has a non-opaque origin
* is the primary main frame or is its child iframe (i.e. not a fenced frame , not a pre-rendering page)

* Topics can also be retrieved via request headers, and marked as observed and eligible for topics calculation via response headers.
* This is likely to be considerably more performant than using the JavaScript API.
* The request header can be sent along with fetch requests via specifying an option: `fetch(<url>, {browsingTopics: true})`.
* The request header will be sent on document requests when the list of topics is non-empty and the request is allowable (e.g., permission policy allows it, the context is secure, etc.).
* Redirects will be followed, and the topics sent in the redirect request will be specific to the redirect url.
* The request header will not modify state for the caller unless there is a corresponding response header. That is, the topic of the page won't be considered observed, nor will it affect the user's topic calculation for the next epoch.
* The response header will only be honored if the corresponding request included the topics header (or would have included the header if it wasn't empty).
* The registrable domain used for topic observation is that of the url of the request.
* Example request header: `Sec-Browsing-Topics: 123;model=1;taxonomy=1;version=2, 2;model=1;taxonomy=1;version=2`
* This example has two topics, 123 and 2, along with their version information.
* Example response header: `Observe-Browsing-Topics: ?1`

* For each week, the user’s top 5 topics are calculated using browsing information local to the browser.
* When `document.browsingTopics()` is called, the topic for each week is chosen as follows:
* There is a 5% chance that a per-user, per-site, per-epoch random topic is returned (chosen uniformly at random).
Expand Down Expand Up @@ -244,9 +257,6 @@ This proposal benefited greatly from feedback from the community, and there are
1. For sites that users frequently visit there is no difference in privacy. For infrequently visited sites, this becomes a trade-off between topic dissemination rate and utility.
1. How might one define “first visit”?
1. It could be: does the site have any cookies or other storage for the user? If so, it’s not first visit.
7. [Should there be a way to send topics via Fetch as a request header?](https://github.com/jkarlin/topics/issues/7)
1. This would reduce the need for expensive (and slow) x-origin iframes to be created.

-------

#### This document is an individual draft proposal. It has not been adopted by the Private Advertising Technology Community Group.