- [Author 1]
- [Author 2]
- [etc.]
We plan to hold regular meetings under the auspices of the WICG to go through the details of this proposal and quickly make any needed changes. Please comment on the timing question in Issue #88 if you want to attend these meetings to be involved in hammering out details.
- FLEDGE Explainer
[The "executive summary" or "abstract". Explain in a few sentences what the goals of the project are, and a brief overview of how the solution works. This should be no more than 1-2 paragraphs.]
FLEDGE is a Privacy Sandbox proposal to serve remarketing and custom audience use cases designed so that it cannot be used by third parties to track user browsing behavior across sites. The API enables on-device auctions by the browser, to choose relevant ads for websites the user has previously visited. FLEDGE uses interest groups to enable sites to display ads that are relevant to their users.
The key idea is that advertisers and publishers will be able to target audiences on the basis of interest groups. Another noteworthy point in this proposal is that the auction-related decisions will take place in the browser as opposed to ad servers, publisher servers, or other third parties.
There are several parties or stakeholders to consider in this context with somewhat competing goals between them:
- Web user - This is the person who is viewing and interacting with web pages.
- In addition to viewing and interacting with the web pages, the goals of the web user may include privacy while seeing ads relevant to their interests, either contextually relevant for the web page or personalized based on prior history.
- Advertisers
- Publishers
- Ad tech agencies
- DSPs
- SSPs
- "buyer" is a potential buyer of "ad space", not ads.
- "seller" is a seller of "ad space", not ads.
- "Ad Inventory" is actually "Ad Space Inventory"
- "interest group"
- Collection of "people" who probably share an interest in the same thing.
- A collection of ads, updated daily, that might e relevant to these people.
- "Stored by the browser" - but maintained by some server.
- "interest group owner"
- "auction"
- "bid"
[If there are "adjacent" goals which may appear to be in scope but aren't, enumerate them here. This section may be fleshed out as your design progresses and you encounter necessary technical and other trade-offs.]
FLEDGE keeps the major principles of TURTLEDOVE while it builds upon features of the following list of previous proposals:
- SPARROW, proposed by Criteo
- Dovekey, proposed by Google Ads
- PARRROT, proposed by Magnite (previously Rubicon Project)
- And, TERN, proposed by NextRoll
SPARROW and Dovekey both proposed that the bidding and auction decisions should be handled by a third party rather than the browser. This was to prevent walled gardens, such as Google, being in control of the bidding process.
Since trusting a third party with the auction didn’t seem to agree with a lot of parties in the ad tech industry, PARRROT suggested that auction-decisions should be made by the publisher server. This proposal, along with TERN, also provided enhanced clarity regarding the roles of DSPs and SSPs.
[For each related element of the proposed solution - be it an additional JS method, a new object, a new element, a new concept etc., create a section which briefly describes it.]
// Provide example code - not IDL - demonstrating the design of the feature.
// If this API can be used on its own to address a user need,
// link it back to one of the scenarios in the goals section.
// If you need to show how to get the feature set up
// (initialized, or using permissions, etc.), include that too.[Where necessary, provide links to longer explanations of the relevant pre-existing concepts and API. If there is no suitable external documentation, you might like to provide supplementary information as an appendix in this document, and provide an internal link where appropriate.]
[If this is already specced, link to the relevant section of the spec.]
[If spec work is in progress, link to the PR or draft of the spec.]
[etc.]
[If there are a suite of interacting APIs, show how they work together to solve the key scenarios described.]
[Description of the end-user scenario]
// Sample code demonstrating how to use these APIs to address that scenario.[etc.]
[Talk through the tradeoffs in coming to the specific design point you want to make.]
// Illustrated with example code.[This may be an open question, in which case you should link to any active discussion threads.]
[etc.]
[This should include as many alternatives as you can, from high level architectural decisions down to alternative naming choices.]
[Describe an alternative which was considered, and why you decided against it.]
[etc.]
[Implementors and other stakeholders may already have publicly stated positions on this work. If you can, list them here with links to evidence as appropriate.]
- [Implementor A] : Positive
- [Stakeholder B] : No signals
- [Implementor C] : Negative
[If appropriate, explain the reasons given by other implementors for their concerns.]
FLEDGE is the first experiment to be implemented in Chromium within the TURTLEDOVE family of proposals. The Privacy Sandbox timeline provides implementation timing information for FLEDGE and other Privacy Sandbox proposals.
[Your design will change and be informed by many people; acknowledge them in an ongoing way! It helps build community and, as we only get by through the contributions of many, is only fair.]
[Unless you have a specific reason not to, these should be in alphabetical order.]
Many thanks for valuable feedback and advice from:
- [Person 1]
- [Person 2]
- [etc.]