It has been pointed out elsewhere that limiting the length of effective bitstrings used to identify ads, campaigns etc. might be too restrictive.

An alternative option for publishers would be to declare an alphabet consisting of specific ad identifiers on some whole origin manifest, e.g. in the OriginPolicy resource.

The browser would then only report ad impressions using the ordinal number for each ad in the alphabet.

The target metrics server could look up the alphabet when it increments the counts.

Hello,

We all welcomed the fact the minutes of the weekly call are now publicly available. However, due to many factors (poor sound quality, people talking at the same time or really fast, non-American accents - pardon our french :)), the minutes are sadly often incomplete and fail to convey some crucial points that would be needed to continue fruitful discussions either during following calls or on github.

I feel the only way to solve this is to record the sessions and make them publicly available.

Do we want a section of this repo to contain links to other repositories that contain the proposals we are currently considering or previously discussed?

Hi,

The TURTLEDOVE proposal introduces a mechanism to provide interest-based advertising whilst preserving user privacy. While we thank Google for this proposal, we think that several aspects can be enhanced to ensure broad adoption by advertisers and publishers and to safeguard most of the interest-based advertising value. Indeed, TURTLEDOVE in its current form:

• Does not cover legitimate advertising use cases outside of retargeting.
• Does not provide advertisers the ability to pilot their campaigns with low latency.
• Does not provide advertisers and publishers the ability to efficiently detect fraud.
• Does not provide advertisers the ability to ensure their ads are displayed in a context that fits their policy ("Brand safety"), or for publishers the ability to ensure ads displayed on their properties meet their standard ("Ad safety").
• Can be problematic, from an audit point of view, with locally computed bids. Without additional yet undisclosed audit capabilities for advertisers and publishers, only the browser has information about the bids and the clearing price.
• Can be improved in terms of the value it brings to advertisers, part of which translates into value for publishers, without any impact on user privacy.
• Can negatively impact user experience, as user device performance and data plan, especially in mobile environments, can will need to download in advance interest-based ad bundles (including pictures, sound, videos, etc.) and bidding scripts.

We would like to introduce an enhancement to TURTLEDOVE, named SPARROW, aiming at addressing these concerns whilst keeping all the privacy guarantees, user control and transparency improvements from TURTLEDOVE.

https://github.com/BasileLeparmentier/SPARROW

We thank all contributors to the W3C Web Advertising BG and hope that this proposal can help to pave the way for future of web advertising.

It would be a lot easier for other contributors to edit MD documents, and we can take advantage of Github's built-in editing etc.
In the call I offered to convert the UseCasesofOnlineAdvertising.html, file to Markdown. Unless Wendell is already planning to do it?

What is the use case?

An advertiser discovers that their ad is running on a site that is not appropriate for them. They need to stop ads running there within minutes or hours. This is similar to the "pausing advertising" use case, but in this case the ads continue to run on other sites.

Why is it important to preserve this use case?

Advertisers can currently respond quickly to problem ad placements. Check My Ads covers the brand-unsafe ad placement problem.

How is it functionally achieved today?

Buyers can update a blocklist, server-side, to prevent real-time bids from being issued when the site is on the list. (This is an incomplete solution but does allow for rapid corrections.)

Do we want to add questions around:

• Is this use case an App or Webview case?
• How much of a priority is this case to your business?

Hello all,

We are experiencing significant performance degradation when we are uploading attachments via our Web App due to Active Field Trial Groups settings set by Google for certain users in our corporate using Enterprise Chrome

We would like to open the support request and have the support team work with my team and IT staff to address the issue

I am happy to expand more on the issue over the phone or a chat

I can be reached at [email protected]

Thanks for all the support,
Khader

37rnPeK1mFpAVH2wqN5YqwvNvw8opDo18t

This is a bitcoin network address. Do not send BTC over any other network to this address or your funds may be lost. Do not send Bitcoin Cash (BCH) to this address.

What is the use case?

Describe the use case in detail. What does it do?

Why is it important to preserve this use case?

Describe why this feature is critical to effective web advertising - both benefits to businesses as well as benefits to consumers.

How is it functionally achieved today?

Describe how this functionality is achieved today

• First Party Sets
• Authorized Sellers for Apps
• Beacon

Minutes

Hello everyone,

We’d like to raise the topic of personalization, especially one-to-one personalization.

As, to our best knowledge, this issue hasn’t been officially covered within this group yet, we thought it’d be good to start with a short doc containing some initial observations: One-to-One Personalization.

While we believe 1:1 personalization is something that’s proven it’s value to virtually everyone around (users, advertisers, publishers…) and, thus, something worth preserving, we’d love to hear the thoughts of other members as well.

Please, let us know! What do you think?

hello,
Dear Google Lab team.

I have two questions.

1. (Phasing out third-party cookies) So. Third-party cookie phasing out, i'm understand.
but in "Web Storage API", localStorage used third-party data also phasing out?
(cookie and storage same workflow?)

ex - suppose) origin domain - a.com(first).
ex1) use JS(third), save data for b.com(third) iframe of localstorage
=> like, b.com iframe JS, localstorage.setItem("myBData1", "blob");
or
ex2) use JS(first), open popup and save data for b.com(third)
=> like, a.com JS, window.open("b.com/saveData?sData=yyyyMMDD_hhmmss"), "bdomainPop");
and b.com/saveData page JS, localstorage.setItem("myBData2", "yyyyMMDD_hhmmss");

then,
in 2024(third-party cookie phasing out),
(b.com origin domain page) possible see data "blob" or "yyyyMMDD_hhmmss"?
like, localstorage.getItem("myBData1") or "myBData2".

2. (Phasing out third-party cookies) Several documents indicate that "Third-party cookie phasing out", same understand.
Then, is first-patcy cookie right to remain in Web?

Please, ask my questions...

Thx! for your reading.

Please just automatically deny all FB cookies and fingerprinting.
OR
Only allow first-party FB cookies IF FB is open in a tab AND person is actually doing something.
AND
IF FB tab is idle for >15 minutes, delete ALL cookies AND fingerprinting.
In other words, limit FB cookies and fingerprinting as much as possible.
Thank you, Tom

As the description goes in TURTLEDOVE document:

As a concrete example, consider retailer WeReallyLikeShoes.com who sells shoes on the web. When a visitor first shows up at the web site, the visitor will be associated with a "WeReallyLikeShoes-shopper" interest group. As they view different sections of the site, they will be associated with the "WeReallyLikeShoes-athletic-shoes" or "WeReallyLikeShoes-dress-shoes" interest groups. When they view particular shoes, they will be associated with the "WeReallyLikeShoes-item-00123-viewer" interest group. Finally, purchasing the shoe or leaving the website will associate them with either the "WeReallyLikeShoes-buyer" group or "WeReallyLikeShoes-cart-abandoner" group.

However in the mechanics of the auction there's no clear explanation about how the UA would choose which interest group to ask ads for, or how this choice ends up being made, it only reports one query:

GET https://first-ad-network.com/.well-known/fetch-ads?interest_group=www.wereallylikeshoes.com_athletic-shoes

Would be great to have more detail on this.

I think this is a neat idea, running in the auction in the browser. A couple more comments here: It does say that a small amount of groups is sent over, but I see a couple of issues in that the number of sites that one visits, and the groups they become a member of, can quickly go above the 1000s including mostly groups of significant size and some smaller in size (lots of people visit home page and product pages of WeReallyLikeShoes, some abandon cart and fewer are buyers). On top of it, the average UA will not just have data from WeReallyLikeShoes.com but also WeAbsolutelyLovePancakes.com. Should there be a registration mechanism for interest in bidding on a particular area with a hint of a bid price and the browser does a pre-screening on it on its own before doing selection and sending the request?

Let's discuss a virtual F2F meeting: longer sessions with an opportunity to go into more depth.

Scheduling: previous instance was 4 hours on 2 consecutive days. During TPAC (October 25-29) Any dates to prefer / avoid?

Agenda suggestions

• Preparing for the standards track: what's ready to move to a WG, what should be in-scope for charter(s)?
• Documentation sprint: improving use cases and documentation of proposal status
• Reporting on experiments: learning from origin trials and other experimentation
• ...

Ideas and comments welcome!

As PATCG is moving forward I want to keep this group updated on progress and discussions.

There is an interest in understanding how GeoIP is used and why, what are the use cases that are reflected by participants in this group. This would be highly relevant to a discussion around this in an IETF working group - https://datatracker.ietf.org/rg/pearg/meetings/

And potentially here to our antifraud group in the W3C here - https://www.w3.org/community/antifraud/

What follows is our use case questions and we would like to see answers from all participants that can be collected into a use case.

What is the use case?

Describe the use case in detail. What does it do?

Why is it important to preserve this use case?

Describe why this feature is critical to effective web advertising - both benefits to businesses as well as benefits to consumers.

How is it functionally achieved today?

Describe how this functionality is achieved today

Link to IsLoggedIn proposal of Apple in README.md is invalid (404), see https://github.com/w3c/web-advertising/blob/master/README.md

Hello all,

To support ongoing legal requirements around browser/extension level signals for CCPA opt-out we need a technical standard that can be commonly extended by any vendor that wishes to provide consumers with that tool. I have written a proposal to update the standard provided by the IAB to provide that interface.

You can view the text and reasoning of the proposal along with how it would change the existing specification (as I understand it) in this pull request: https://github.com/AramZS/IAB-CCPA-Framework-Implementation-Notes/pull/2/files

On Feb. 8, I will be updating the repository to rename the main branch from "master" to "main"

Thanks.

See https://lists.w3.org/Archives/Public/spec-prod/2021JanMar/0017.html
https://lists.w3.org/Archives/Public/public-web-adv/2021Feb/0000.html

In the Fledge call on 5/12 various adtech interests pointed out more complex business needs for the fledge proposal and auction mechanics not represented in the proposal. Michael Kleber of the Fledge Proposal indicated that they did not have complete understanding of the adtech needs involved and recommended discussion in the web-adv group of adtech to more clearly spec out the flows and relationships needed in an auction model.

As per that call, I wish to start a discussion and possibly call for an adtech focused meeting on the topic with publisher participation as well.

Of particular concern (in the Fledge call, see minutes below) were SSP and Publisher-Agent responsibilities to the publisher to earn them the most revenue, and how the theoretical responsible of these groups to earn publisher revenue are unexhaustive of the practical responsibilities, especially involving ensuring transparency and competition to provide publishers value.

We saw even in the Fledge call different needs and opinions from different companies in the same grouping, so there should be a great diversity of details to discuss. Not all ssps or publishers, for example, have the same needs. Integration type, size, power-imbalance and other factors create a variety of needs and duties that should be recorded. We should not leave anyone out.

We should spec out these needs. This could help inform any auction-based privacy proposal, including and especially flesh out the Fledge api readme which has been established to need more specifics as to the api, the data and the responsibilities of each party as indicated in the 4/28 call

Minutes Referenced:
5/12 https://docs.google.com/document/d/1Kr0hpfQ_Q1LX1aN00D5k_09yV_a7WE9RSn69nS3nZho/edit#heading=h.wrf7s4rh39jg)
4/28
https://github.com/WICG/turtledove/blob/main/meetings/2021-04-28-FLEDGE-call-minutes.md

@benjaminsavage - Thanks for the write up!

Question on feature selection. To make this machinery work besides the open questions you already raised, how would you see the feature selection working? Publisher / Advertisers deploying this would need an aligned set of input/derived variables to feed them into the model and derive the embedding etc.

Assuming one can make it happen in general, I would imagine the notion of aligning on features/embedding details would be an out-of-band process between pubs and advertiser?

There are two uses of the word "impression", one for a publisher and one for an advertiser (emphasis mine):

Since we're discussing the web ads ecosystem, the publisher web pages we care about will generally have ads on them. That means you can think of publishers as creating web pages containing empty rectangles — rectangles which they want to sell to advertisers. Since publishers sell empty rectangles, they are referred to as the sell side or the supply side of the market. The empty rectangles themselves are sometimes referred to as ad slots or impressions, or as inventory when thinking of them as something being sold.
...
Since advertisers buy rectangle-shaped real estate to put their ads in, they are referred to as the buy side or the demand side of the market. When a specific ad creative appears on a user's load of a publisher web page, the event is called an impression.

Is this intentional? I was not aware of an empty ad space being referred to as an impression as well.

As part of wider W3C stakeholder engagement capture more information on the needs of brands and their technical requirements.

This is a mirror of the issue raised under First Party Sets.

Right now we really only discuss (and only vaguely) direct sold vs programmatic among our advertising use cases. We really need to document a few additional things:

• The nature and flow of direct sold deals and the different way they are implemented by publishers
• The other types of deals between programmatic and direct; including Private Marketplaces, Programmatic Direct and other types of sales that fall between the two poles of 100% hands on and 0% hands on by publishers.
• The reasoning why these different models exist and how, why or if they should be preserved in a privacy-focused future.
• How bidding systems work to compare multiple bids from multiple providers, why they do so, and to what scale and end purpose and the impact of that for both buy and sell side.
• We've previously discussed bid shading and auction models, having more detail in our use case document about bid models and auction models would be very useful.

This is a lot about publisher models so their participation is important here, and this also comprises multiple things that likely will have to be spun into multiple issues. Consider this a sort of omnibus issue to talk about this.

Use this issue to gather links to other meetings relevant to proposals/questions raised in the WebAdv BG. Thanks!

This github-notify tool can be configured to send notifications of repo activity to a mailing list, for any set of W3C and external repositories. It requires a webhook in the target repo's settings as well as a configuration on the W3C side. Do we want to use it?

One way to achieve user controlled targeting, or audience restricted ad delivery, is to let the user's browser select the ad according to some information provided by the user.

The declarative attributes to an "ad tag" could include something like:

`
<ad deliveryOption='userDefined' adCategory='male;age50+;'auto'>

If the user was prepared to receive ads aimed at their demographic, then the iframe would be retrieved and rendered (without cookies being sent)

Impression counts would then be registered as before.

The user could perhaps receive content depending on whether they had allowed themselves to be categorised for ad delivery. In this system they would still not be "singled-out" though, unless they had specifically agreed.

If the deliveryOption attribute was 'always' or not present then the iframe would be rendered every time (but still without cookies).

Hi,

What's the best way to discuss use cases that currently require third-party cookies, but are not related to web advertising?

A while ago we added this comment which summarises our problem, and we are happy to provide as much detail as required.

In short, the International Image Interoperability Framework allows of interoperability of cultural heritage content. It is implemented by hundreds of organisations worldwide, including, in the US, the Library of Congress and the Smithsonian; in Europe, the British Library and the Bibliothèque nationale de France, and hundreds of other universities, museums and cultural heritage institutions around the world. This interoperability happens in browser-based viewers and tools. Usually, the content is all open and has no access control requirements, but this is not always the case.

For example, if I am annotating Wikipedia-hosted images in a browser-based annotation tool on mydomain.org, and Wikipedia requires me to authenticate to see those images, then my tool running on mydomain.org needs to:

1. Know that I can't see the Wikipedia content right now
2. Know that I will need to go to "wikipedia.org/login" to do something about that
3. Later, know that I can now see the content hosted by Wikipedia.

Crucially, mydomain.org doesn't need to know anything about me, or about my interactions with wikipedia.org, or how Wikipedia.org enforces access control, or have any knowledge of or access to my credentials for Wikipedia, or have any access to Wikipedia's protected content at all. It just needs to know whether or not a request from my browser for that content would succeed. Once it does know that, it can then render image tags (for example) that point to that content on Wikipedia. As these requests are cross-origin, it also requires that credentials I have acquired for wikipedia.org are included with those requests.

This is, I think, equivalent to:

It may be OK for a site to learn the fact that a user has earned trust on another site

from https://github.com/michaelkleber/privacy-model

Our current specification for these patterns is at https://iiif.io/api/auth/1.0/

This spec is fine with accommodating SameSite and other restrictions to date, but it will not work if credentials acquired in a trust relationship with a third party site are not then sent with content requests to that third party site.

If the privacy sandbox means that there is a way of selectively allowing one domain to learn something about a user's trust relationship with another domain, and that the mechanism of allowing this "leaking" is understood and trusted by the user, then we might be able to produce a new auth pattern that is significantly better and more transparent than the current pattern, which is tricky to implement. But if this use case is not going to be supported on the web in future, then we won't be able to continue with interoperability of access-controlled cultural heritage in the way we have been to date.

Our friends at CafeMedia have documented their experiments with FLoC and results. Presumably, as more trials become active and possible to react to, other entities would like to generate reports and it would be useful to have them incorporated here. Should we place this into its own doc, put reactions under the proposals in the README, or some other approach?

There is some interest in tracking the implementation of web publisher requirements across a variety of proposals. These requirements range from turning off a particular piece of ad creative on a site to more complex issues such as floor rates by ad vertical.

This issue is a placeholder for an agenda item to introduce a discussion of publisher requirements and to collect links to relevant issues in proposals. This covers in-browser auctions and related placement issues, and a future part 2 will cover reporting issues.

dmarti/in-browser-auction-publisher-issues: Summary and links to web publisher considerations for in-browser ad placements

See issue 3 on TURTLEDOVE for full context.

product_id might be overly specific for the granularity of exclusion groups. Exclusion groups could also apply to other conversion events, like an "add to cart" or "sign up for more info". While the advertiser is in full control of when they invite a browser to an exclusion group, and how they identify it, we can improve the naming for this.

A few options:

• conversion_id: this likely implies a single conversion, not a type of conversion
• conversion_group_id: this is a bit better, but the word "conversion" might still carry too much meaning
• exclusion_group_id: seems simple and straightforward

The section "Conveying User Agent Registered User Consent" could perhaps mention Mike West's HTTP State Tokens proposal?

I had proposed these goals in a draft howto document, but was encouraged to move them out for discussion.

Goals:

• Stop individually-identified cross-site / web-wide tracking

  • Restrict third-party cookies
  • Restrict fingerprinting, e.g. IP blindness
  • Permit user choice

• Provide monetization opportunities that support the open web

  • Measurement of impressions, conversions, and attribution
  • Aggregate reporting APIs
  • Enable non-tracking-based targeting, e.g. FLoC, TURTLEDOVE, in-browser auction
  • Fraud-resistance

Do we share this set of high-level goals?

During the Improving Web Advertising Business Group meeting of 23rd February 2021 a representative from Google presented a diagram similar to the one shown above and addressed any confusion over the inclusion of remarketing in the 95% calculation.

However we were not in the time available on 23rd able to understand the working behind the 95% figure. Others via their own experiments are unable to work out how such a high figure could be achieved based on the limited information presented.

Given the importance of this particular figure to the current perception of cohort based marketing across the digital marketing industry, and the unfortunate media attention it drew in January 2021, I would appreciate a clear explanation of the calculation.

This explanation will then enable those that are asked by their customers to explain the approach they will be using to provide a cohort based post 3PC solution that is 95% as effective as the one they provide today to present an answer. Such customers might reasonably ask for a reduction in fees proportional to the reduction in effectiveness, or might seek alternative solutions to spend their money on which are not so impaired.

Greetings,

Some time ago I wrote considerable chunks of the Self-Review Questionnaire: Security and Privacy, so imagine my confusion when I encountered (by quite an accident!) the WAB's Self-Review Questionnaire: Interoperability, Choice, Accessibility and Accountability. Specifically I note that it is quite creatively reusing the Security and Privacy Questionnaire. To better understand the issue, let's start at the introduction of the Self-Review Questionnaire: Interoperability, Choice, Accessibility and Accountability document:

New features make the web a stronger and livelier platform. Throughout the feature development process there are both foreseeable and unexpected impacts to multiple stakeholders. These risks may arise from the nature of the feature, some of its part(s), or unforeseen interactions with other features. Such risks and impacts may be mitigated through careful design and application of the principles and design patterns described below.

Standardizing web features presents unique challenges. Descriptions, protocols and algorithms need to be considered strictly before they are broadly adopted by vendors with large user bases. If features are found to have undesirable impacts on important stakeholder interests after they are standardized, then, it is better to transparently list these ahead of browser vendors implementations, to give opportunity for broader feedback.

Now let's have a look at the Security & Privacy document, also introduction section:

New features make the web a stronger and livelier platform. Throughout the feature development process there are both foreseeable and unexpected security and privacy risks. These risks may arise from the nature of the feature, some of its part(s), or unforeseen interactions with other features. Such risks and may be mitigated through careful design and application of security and privacy design patterns.

Standardizing web features presents unique challenges. Descriptions, protocols and algorithms need to be considered strictly before they are broadly adopted by vendors with large user bases. If features are found to have undesirable privacy properties after they are standardized, then, browser vendors may break compatibility in their implementations to protect users' privacy as the user agent is the user’s agent.

I guess you get the idea. Let's say it's quite creatively reused. While I understand the considerations of the Creative Commons 0 license, it still makes me wonder if this is simply OK from the 'good form' point of view. What do you think?
That said, I'm not sure how to fix such an issue other than citing in verbatim and providing a reference, which, I admit, would look quite awkward, unless anyone else has a better idea?

What is the use case?

Describe the use case in detail. What does it do?

Why is it important to preserve this use case?

Describe why this feature is critical to effective web advertising - both benefits to businesses as well as benefits to consumers.

How is it functionally achieved today?

Describe how this functionality is achieved today

Hi @benjaminsavage, these questions stem from a conversation between @michaelkleber @tomkershaw1, and a few others here (WICG/floc#20).

They come from the perspective of an ad exchange, who seeks to maximize publisher revenue.

First off, thanks for preparing the proposal, the specific use case we are attempting to solve was defined by Michael in issue 20 as such:

1b. "Lookalike segments" where you have some group of people (maybe a retargeting segment from 1a) and you want to construct a larger group of people who are kind of similar to that group. It would be fine to advertise to these folks using a private mechanism like TURTLEDOVE; the problem is finding them in the first place. -MK

We assume that a publisher website is able to collect first-party data about its own users.

1. How much FPD would a publisher need to pass this threshold?
2. If I own swimming.com, and I have FPD about my visitors, my lookalike audiences will attempt to find other people interested in Swimming? Is that the idea?

From this first-party data, we presume the publisher is able to train a neural network which can be used to produce an “embedding vector” for each user

1. As the owner of swimming.com, it sounds like I need to be prepared to produce the embedding vector myself, or hire someone to do it?

[Step 2] When this person later visits the advertiser’s website in this browser, some 3rd party JavaScript provided by the publisher should be invoked to flush this data to a server-side aggregation service.

1. as the owner of swimming.com do I need to convince advertisers like TYR & Roka to deploy my JS for this to work?

[step 4] The publisher could then request this aggregated vector via some kind of API. The server-side aggregation service would add some small amount of noise to the aggregation to ensure a target ε-differential privacy. With the exception of supporting vector primitives, this is exactly what is described in Chrome’s current explainer.

1. after this occurs, as a publisher what specifically do I have? Do I have a vector id, or do I know the user browsing my site is interested in x, y, or z?

Hi,

I think we should have a TPAC breakout session on Privacy.
 
This is a topic of importance, with many active discussions in this group and others.
 
@AramZS, @jwrosewell, TheMaskMaker, people from the Web Privacy Principles Task Force (@wseltzer) , and others; you are involved in Privacy definition discussions. TPAC is a great opportunity to exchange and communicate on that topic.
 
We could have a session where various viewpoints are presented. Would some of you be interested to participate as speakers in that session?

The current definitions of first party and third parties and people’s trust relationship to them are too simplistic. In reality people’s trust choices change based on circumstances and conditions. Competition between difference parties is also a consideration.

This tussle is at the heart of many issues many people have raised in relation to proposals, and debates held within this group. The W3C needs a clear policy in relation to these issues.

This session would invite policy experts to provide their input on these issues to better inform the conversation. Outputs beyond the minutes might include a recommendation concerning how to define and apply clear definitions.

This is a mirror of the issue raised under First Party Sets, a pull request to amend the security and privacy questionnaire, and issues (bias, behaviour, and supply chains) related to the security and privacy questionnaire which have been closed without discussion.

Reading through the privacy considerations section, the requirements there align a lot with the characteristics of the fenced frames proposal. This section in particular talks about how fenced frames could be used for lift studies. To summarize the solution, there are two steps: 1) An isolated JS environment (whose explainer will be published soon) that invokes the lift studies API and returns an opaque output, and 2) The fenced frame (an embedded document that cannot communicate with the publisher page) renders the ad represented by the opaque output from 1).

It would be great to know your thoughts on using fenced frames for this API.

The First Party Sets proposal continues to evolve and at the point has become pretty different from the initial proposal, especially with the idea of some sort of independent entity checking and potentially invalidating self-attested sets.

I'm curious where the participants in this group land in terms of approval of the current state of the proposal as well as if those that have supported it in the past continue to support its current state.

To be clearly upfront with my purposes here: I'm not sure First Party Sets continues to make sense. Chrome team clearly intends it to be a way to have lower security walls for cross-site communication, but all the other browsers have made clear they do not intend to use it that way. Some of their use cases seem to be centered around easier to accomplish URL decoration or login, but I am admittedly vague on this.

As a result, I'm wondering if participants in this group would continue to see a use in FPS that does not reliably drop cross-site security to some degree?

It might be helpful if @martinthomson or @johnwilander were able to speak in more detail to what the other uses they see in FPS are, either here in text, by linking to existing statements, or by sending a rep to talk to this idea in the upcoming meeting.

TCF has been developed over many years to capture people’s consent choices and inform multiple parties. Solutions to many of the hard and deep problems we are wrestling with will benefit from a common understanding of TCF. Perhaps there are non engineering solutions to some of these problems.

This is a mirror of the issue raised under First Party Sets.

What is the use case?

Describe the use case in detail. What does it do?

Why is it important to preserve this use case?

Describe why this feature is critical to effective web advertising - both benefits to businesses as well as benefits to consumers.

How is it functionally achieved today?

Describe how this functionality is achieved today

There was discussion at the 2021-06-29 about the potential usefulness of ads metadata. There is the Ad ID option, which gives ads an identifier using which metadata can be obtained. There is also the option of simply including metadata directly in an ad bundle.

I believe that coming EU regulation may make some types of ad metadata mandatory, so solving this well prior to it coming into effect would also help.

I would find developing a greater understanding of this use case valuable.

The use-cases for following the issue dashboard align well with those of using an RSS feed reader. It would be very useful to be able to subscribe to a single feed that aggregates from issues and proposals to help track the many moving parts.

Please consider adding this feature.