Note: We might want to add another property into the API (TCData object) that covers the list of disclosed vendors

I will need to update the TC String example with a disclose vendors segment in the segment section of the spec.

It is currently impossible for a user to register an objection to SP1, and several vendors, including Google Ad Manager (in the __eoi cookie disclosed here https://business.safety.google/adscookies/ but not in the device disclosure url in the tcf registration) and the Ozone Project (disclosed here https://github.com/prebid/prebid.github.io/pull/5967/files ), seem to rely on Special Purpose 1 alone to set cookies. Google Ad Manager documentation says there is nothing in tcdata that can prevent this cookie from being set by its on page library, pubads_impl, (https://support.google.com/admanager/answer/9882911?hl=en#limited-ads-update), as they only rely on special purposes to run Limited Ads 2.0.

Since there is nothing allowing an SP1 objection in TCData, we have no way to communicate to these vendors this is unacceptable for this user.

We'd like for an SP objection to be specifically possible to express in tcdata, as the e-privacy directive does not seeem to allow for device access for services not specifically requested by the user, and some publishers may need to register or express special purpose objections to prevent vendors with unusual legal interpretations from accessing the device.

Deleting the vendor one is trying to compel to not rely on sp1 to set cookies from the disclosed vendor list may have this same effect, but it would seem it would be cleaner to not encourage publishers and cmps to implement this workaround, and just allow for a clear special purpose objection.

This seems to need an alignment in the TCF policy working group - at least with Ozone they argue that (quoting the PR) "Consent: As this cookie is strictly necessary for the functioning and security of the website, it is exempt from consent requirements under applicable data protection laws, including the UK GDPR and ePrivacy Directive.", I'd assume likewise with Google.

In that sense they do not rely on SP1 to place the cookie (which they also cannot based on the policy), but requesting controls for SP1 is a topic that can be (re)discussed.

Ozone's assertion is rather absurd though; an ssp cookie is of course not necessary for the security of the website. I think if TCF policies made it clear that security cookies must not be placed by vendors upon a publisher restriction for a special purpose, as they already make clear for other publisher restrictions, that would solve the issue quite well. Credit to @lamrowena for suggesting SP publisher restrictions as a "way out"

thank you @patmmccann for your feedback. While I understand the need and the requirement, I do not believe they are directly linked with the current PR, which only goals is to remove existing ambiguity. As such, we are moving forward with the current PR.

We had however already explored the ability for publishers to perform publisher restrictions, including on Special Purposes, which is what I believe you are after.
Your concern will be raised again in the Policy Working group and if the group is supportive, the Framework Signal Working Group will work with the tech lab to update the TCF specs accordingly.

Update based on FSWG input. Added support for disclosed vendors in mobile storage, added a Q&A and update sample TC strings in the spec. I also updated the broken links in the guideline document.