https://wiki.prebid.org/api.php?action=feedcontributions&user=Jkoran&feedformat=atomBitnami MediaWiki - User contributions [en]2024-03-29T05:50:44ZUser contributionsMediaWiki 1.35.0https://wiki.prebid.org/index.php?title=Statistical_Identifier&diff=580Statistical Identifier2022-12-08T15:16:43Z<p>Jkoran: </p>
<hr />
<div>A Statistical Identifier is an [[Identifier|identifier]] generated via a [[Probabalistic|probabilistic]] method. The inputs into the process are usually technographic characteristics of the web-enabled device or applications.<br />
<br />
== Benefits ==<br />
Statistical identifiers are often used to detect [[Non-human Traffic|non-human traffic]].<br />
<br />
Critics of statistical identifiers refer to this process as "fingerprinting."<br />
<br />
[[Category:Personal Data|Statistical Identifier]]<br />
<br />
[[Category:Glossary|Statistical Identifier]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Data_Masking&diff=568Data Masking2022-02-20T01:15:35Z<p>Jkoran: </p>
<hr />
<div>Data Masking (also called "obfuscation") is a process that replaces one identifier with a [[Pseudonymous|pseudonymous]] one or redacts portions of an [[Identifier|identifier]] (e.g., IP truncation). <br />
<br />
Another method of Data Masking is "substitution," which replace one identifier with a less precise one (e.g., linking the zip 90210 to "Beverly Hills," given there are other zip codes in that California region). Password entry boxes frequently rely on tokenized data masking to substitute a single character (e.g., "*" or "X") for each actual input character entered by the user. Credit card receipts often truncate the entire account number, displaying only the last four digits of a credit card. <br />
<br />
== Regulator Perspectives ==<br />
Algorithmic functions are preferred as strong protections than substitution or tokenization forms of pseudonymization. The Article 29 Data Protection Working Party wrote:<br />
<br />
<blockquote>If pseudonymisation is based on the substitution of an identity by another unique code, the presumption that this constitutes a robust de-identification is naïf….<ref>https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf, section A2</ref></blockquote><br />
<br />
Thus, when an identifier is "[[De-identified Data|de-identified]]" it is no longer directly linked to an individual’s identity and hence "[[Pseudonymous|pseudonymous]]." When all identifiers have been removed from information, it is "[[Anonymous|anonymous]]."<br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Glossary|Data Masking]]<br />
<br />
[[Category:Privacy Sandbox|Data Masking]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Data_Masking&diff=567Data Masking2022-02-19T17:53:35Z<p>Jkoran: Created page with "Data Masking (also called "obfuscation") is a process that replaces one identifier with a pseudonymous one or redacts portions of an identifier..."</p>
<hr />
<div>Data Masking (also called "obfuscation") is a process that replaces one identifier with a [[Pseudonymous|pseudonymous]] one or redacts portions of an [[Identifier|identifier]] (e.g., IP truncation). <br />
<br />
Another method of data masking is "substitution," which replace one identifier with a less precise one (e.g., linking the zip 90210 to "Beverly Hills," given there are other zip codes in that California region). Password entry boxes frequently rely on data masking to substitute a single character (e.g., "*" or "X") for each actual input character entered by the user. Credit card receipts often truncate the entire account number, displaying only the last four digits of a credit card. <br />
<br />
== Regulator Perspectives ==<br />
Algorithmic functions are preferred as strong protections than substitution or tokenization forms of pseudonymization. The Article 29 Data Protection Working Party wrote:<br />
<br />
<blockquote>If pseudonymisation is based on the substitution of an identity by another unique code, the presumption that this constitutes a robust de-identification is naïf….<ref>https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf, section A2</ref></blockquote><br />
<br />
Thus, when an identifier is "[[De-identified Data|de-identified]]" it is no longer directly linked to an individual’s identity and hence "[[Pseudonymous|pseudonymous]]." When all identifiers have been removed from information, it is "[[Anonymous|anonymous]]."<br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Glossary|Data Masking]]<br />
<br />
[[Category:Privacy Sandbox|Data Masking]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Pseudonymous&diff=566Pseudonymous2022-02-19T17:49:28Z<p>Jkoran: </p>
<hr />
<div>Pseudonymous means there are appropriate technical and operational processes within the organization using the identifier to keep this identifier separate from an individual’s identity. Pseudonymous information is one form of [[Personal Data]].<br />
<br />
“Pseudonymize” or “Pseudonymization” is a process to create an addressable identifier that is kept separate from an individual’s directly-identifiable identity with an appropriate technical or operational process. This means the information is no longer attributable to a specific individual without the use of additional information, provided that the additional information is kept separately and is subject to technical and organizational measures to ensure that this information is not subsequently mapped to an identifiable individual.<br />
<br />
Pseudonymization techniques include algorithmic functions (such as using a one-way process to transform input identifiers into outputted ones) or tokenization process (using a bi-directional mapping process to transform input identifiers into outputted ones). A common example of the former is hashing emails to produce a new pseudonymous identifier. A common example of the latter is relying on [[Data Masking|substitution]] (e.g., linking the zip 90210 to “Beverly Hills,” given there are other zip codes in that California region). Algorithmic functions are preferred as strong protections than substitution or tokenization forms of pseudonymization.<ref>https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf, section A.2</ref><br />
<br />
Often “pseudonymization” is frequently confused with “[[Anonymous|anonymization]]”. Pseudonymous identifiers are not linked, but could be linked, to an individual’s identity that is held separately.<ref>https://ico.org.uk/media/about-the-ico/consultations/4019579/chapter-3-anonymisation-guidance.pdf</ref> Anonymous data cannot be linked to an individual, and as such is often excluded from data protection regulations.<ref>https://ico.org.uk/media/about-the-ico/consultations/4019579/chapter-3-anonymisation-guidance.pdf</ref>,<ref>https://gdpr-info.eu/recitals/no-26</ref> A common example of anonymized data is when it is when the input data is made available only as a summarized, aggregated output metric. <br />
<br />
== Regulator Perspectives ==<br />
GDPR recommends pseudonymization as one method to comply with data organizations’ protection obligations, such as ensuring appropriate security to safeguard personal data.<ref>https://gdpr-info.eu/art-4-gdpr</ref> <br />
* Article 6 (4-e): ”the existence of appropriate safeguards, which may include encryption or pseudonymization.”<ref>https://gdpr-info.eu/art-6-gdpr</ref><br />
* Article 32 (a): “The controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: the pseudonymization and encryption of personal data.”<ref>https://gdpr-info.eu/art-32-gdpr</ref><br />
<br />
Pseudonymization of personal data can reduce risks to data subjects and help controllers meet data-protection obligations.<ref>https://gdpr-info.eu/recitals/no-28</ref> <br />
* Article 25 (1): “Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures, such as pseudonymization, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects”<ref>https://gdpr-info.eu/art-25-gdpr</ref><br />
* Article 40 (2): “Associations and other bodies representing categories of controllers or processors may prepare codes of conduct, or amend or extend such codes, for the purpose of specifying the application of this Regulation, such as with regard to:... (d) the pseudonymization of personal data.<ref>https://gdpr-info.eu/art-40-gdpr</ref><br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Personal Data|Pseudonymous]]<br />
<br />
[[Category:Glossary|Pseudonymous]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=De-identified_Data&diff=565De-identified Data2022-02-19T17:40:13Z<p>Jkoran: Created page with "De-identified data is information which has undergone a pseudonymization process, rendering it no longer linked to an individual’s directly-identifiable identity. == Regul..."</p>
<hr />
<div>De-identified data is information which has undergone a pseudonymization process, rendering it no longer linked to an individual’s directly-identifiable identity. <br />
<br />
== Regulator Perspectives ==<br />
The UK Data Protection Act (2018) defines<br />
<br />
<blockquote>“‘de-identified’ personal data as personal data that has undergone pseudonymisation as defined in the UK GDPR rather than (for example) anonymous information.”<ref>https://ico.org.uk/media/about-the-ico/consultations/2619862/anonymisation-intro-and-first-chapter.pdf</ref></blockquote><br />
<br />
Thus, when an identifier is “de-identified” it is no longer directly linked to an individual’s identity and hence “[[Pseudonymous|pseudonymous]].” When all identifiers have been removed from information, it is “[[Anonymous|anonymous]].”<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|De-identified Data]]<br />
<br />
[[Category:Privacy Sandbox|De-identified Data]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Personal_Data&diff=564Personal Data2022-02-19T17:39:09Z<p>Jkoran: </p>
<hr />
<div>Identifiers can either be directly tied to an individual’s “identity” or be “[[pseudonymous]],” which means there are appropriate technical and operational processes within the organization using the identifier to keep this [[identifier]] separate from an individual’s identity. <br />
<br />
If an identifiable identity (e.g., email) goes through an appropriate [[De-identified Data|de-identification]] process it can become a pseudonymous identifier.<br />
Privacy regulations group both directly identifiable identity and pseudonymous identifiers as “personal data,” but state pseudonymous identifiers pose lower [[privacy]] risks to people<br />
<br />
[[Category:Glossary|Personal Data]]<br />
<br />
[[Category:Personal Data|Personal Data]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Personal_Data&diff=563Personal Data2022-02-19T17:35:24Z<p>Jkoran: </p>
<hr />
<div>Identifiers can either be directly tied to an individual’s “identity” or be “[[pseudonymous]],” which means there are appropriate technical and operational processes within the organization using the identifier to keep this [[identifier]] separate from an individual’s identity. <br />
<br />
If an identifiable identity (e.g., email) goes through an appropriate [[De-identified|de-identification]] process it can become a pseudonymous identifier.<br />
Privacy regulations group both directly identifiable identity and pseudonymous identifiers as “personal data,” but state pseudonymous identifiers pose lower [[privacy]] risks to people<br />
<br />
[[Category:Glossary|Personal Data]]<br />
<br />
[[Category:Personal Data|Personal Data]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Parakeet&diff=562Parakeet2022-02-19T17:24:21Z<p>Jkoran: </p>
<hr />
<div>The goal of Google's [[:Category:Privacy Sandbox|Privacy Sandbox]] is prevent marketers from engaging a particular audience in a particular context. <br />
<br />
Microsoft's PARAKEET (Private and Anonymized Requests for Ads that Keep Efficacy and Enhance Transparency) aims to enable marketers to engage the right audience in the right context by introducing a trusted proxy server. Parakeet is analogous to Criteo's [[Sparrow]] by relying on trusted server-side "gatekeeper" service rather than just Google. <br />
<br />
Google acknowledged that Criteo's proposed Sparrow is an improvement on Google's [[Turtledove]] by acknowledging the need for server-side processing. Unlike Sparrow, where this trusted server hosts bidding models and executes auction logic, Parakeet uses the trusted server merely as a proxy system routing [[Anonymous|anonymized]] requests to the competitive ecosystem. This enables marketer buying systems to update their bids, budgets and tactics without the latency involved with sending asynchronous updates required by Turtledove, Sparrow and others.<br />
<br />
"The ad network [or DSP] will perform ad matching, ranking and auction with contextual and user interest information provided in privacy anonymized ad request."<ref>https://onedrive.live.com/?authkey=%21ADXFCm%2DPD5apqD8&cid=CB5C6D995D103282&id=CB5C6D995D103282%21274&parId=root&o=OneUp</ref><br />
<br />
The "privacy" meaning within the Parakeet refers to adding noise or aggregations to the information it proxies, meaningfully impairing its accuracy. Among the anonymizations are:<br />
<br />
* Anonymizing the publisher requesting an ad <br />
* Anonymizing the geography from which the user is requesting content <br />
* Anonymizing the IP from which the user is requesting content <br />
* Anonymizing the User Agent String that is used to match content to the capabilities of their web-enabled device <br />
* Add noise or other random information into different requests from the same web-enabled client <br />
* Reduce granularity of audience interests<br />
* Add an encoded vector of recent browsing activity, they call [[Representations]]<ref>https://github.com/microsoft/privacy-preserving-ads/blob/main/Parakeet.md</ref><br />
<br />
Parakeet relies on [[Fenced Frames|Fenced Frames]] to receive the bid request it will proxy. The ad request routes through Parakeet server, which applies its noise and may enrich audience information the trusted server has previously associated with this browser. While Parakeet allows the auction mechanics to be conducted by the competitive market, it does not describe how those organizations can train their machine learning models.<br />
<br />
Given the bi-directional client-server architecture, Parakeet relies on a unique browser identifier per browser. Parakeet does not describe the creation and user's management process of this identifier. Parakeet does describe that users should have opt-out controls for specific categories of information, such as "ad category, advertiser, and ad network."<ref>https://github.com/microsoft/privacy-preserving-ads/blob/main/Parakeet.md</ref><br />
<br />
For the winning ad that renders on the publisher page, Parakeet also will proxy the user's click events through its service. This proxy redirect allows Parakeet to control what information the recipient marketer or publisher domain receives when users navigate the web. This proxy service also would allow the Parakeet gatekeeper service to provide aggregate reporting. If marketers send their conversion data to the proxy service, this service could also provide attribution reporting.<br />
<br />
Given the immense amount of web activity proxied through these new servers, Parakeet expect that there will be an additional fee that publishers and marketers must bear. "The cost of running PARAKEET is an important aspect to discuss. Enabling a monetization service whose costs to run are shared by publishers and/or advertisers is not unique and is similar to existing mechanisms that use ad exchange fees and SSP and DSP fees. We believe this proposal can be funded in a similar manner."<ref>https://onedrive.live.com/?authkey=%21ADXFCm%2DPD5apqD8&cid=CB5C6D995D103282&id=CB5C6D995D103282%21274&parId=root&o=OneUp</ref><br />
<br />
Parakeet criticizes Google's Turtledove assumption that separating audience segments from context is actually useful in improving people's privacy. "Separating contextual ad requests and interest-based ad requests is a weak form of privacy protection, if any."<ref>https://github.com/microsoft/privacy-preserving-ads/blob/main/Parakeet.md</ref><br />
<br />
Parakeet does highlight that an important point not discussed in detail by Google's Privacy Sandbox proposals. "Performance impacts on users' devices is also an important consideration. In particular, if some aspect of user ad interest aggregation and/or anonymization is performed on the users' devices, the CPU, memory, disk, and resulting power impacts could be significant."<ref>https://github.com/microsoft/privacy-preserving-ads/blob/main/Parakeet.md</ref> By shifting most of the processing to a competitive ecosystem, Parakeet would not have as great a cost on user experience relative to Google's Privacy Sandbox proposals. <br />
<br />
While Parakeet is to be commended for designing a service that can support a competitive marketplace, its design rests on the principle that marketers can rely upon a pseudonymous browser ID to engage, measure and optimize their media across the different publishers based on activities that later occur on the marketers web property. Thus, if users can trust such a system, this suggests that the same language provided to users to earn this trust can also be used by a non-proxy based system. Microsoft does not discuss this point.<br />
<br />
== Impact ==<br />
By forcing publishers and marketers to route traffic through a new pay-to-access service, this disintermediates publishers from their customers and adds latency to existing system as well as people's navigation as well as more cost that will be subtracted from marketer budgets in their payments to publishers. <br />
<br />
Given not all publisher (or marketer) content is served within Fenced Frames, the same browser identifier passed to Parakeet for advertising across publishers must be available when receiving data from marketer web properties. Microsoft does not describe this process. <br />
<br />
Given the potential conflict of interest, Criteo suggests with Sparrow that gatekeepers cannot compete with their any of their clients. Microsoft does not discuss this point.<br />
<br />
== Open Questions ==<br />
* If different publishers route traffic through different gatekeepers, how many gatekeepers must one marketer query to retrieve aggregate reporting? <br />
* What are the estimated incremental costs that must be charged by the Parakeet service on a "per thousand requests" basis? <br />
* What is the process for determining which organizations' servers are trusted?<br />
* What is the time-delay in providing the data necessary for publishers to optimize their revenue? <br />
* What is the time-delay in providing the data necessary for marketers to optimize their media spend?<br />
* How many organizations can access the information collected by the proxy service to perform custom attribution and analytics?<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Parakeet]]<br />
[[Category:Privacy Sandbox|Parakeet]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Anonymous&diff=561Anonymous2022-02-19T17:18:43Z<p>Jkoran: Created page with "Anonymous data is information no longer linked to Personal Data. The anonymization process removes all identifiers from data. A common example of anonymized data is when i..."</p>
<hr />
<div>Anonymous data is information no longer linked to [[Personal Data]]. The anonymization process removes all identifiers from data. A common example of anonymized data is when it is when the input data is made available only as a summarized, aggregated output metric. <br />
<br />
== Regulator Perspectives ==<br />
Anonymous data cannot be linked to an individual, and as such is often excluded from data protection regulations.<ref>https://ico.org.uk/media/about-the-ico/consultations/4019579/chapter-3-anonymisation-guidance.pdf</ref>,<ref>https://gdpr-info.eu/recitals/no-26</ref> <br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Personal Data|Anonymous]]<br />
<br />
[[Category:Glossary|Anonymous]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Pseudonymous&diff=560Pseudonymous2022-02-19T17:16:16Z<p>Jkoran: </p>
<hr />
<div>Pseudonymous means there are appropriate technical and operational processes within the organization using the identifier to keep this identifier separate from an individual’s identity. Pseudonymous information is one form of [[Personal Data]].<br />
<br />
“Pseudonymize” or “Pseudonymization” is a process to create an addressable identifier that is kept separate from an individual’s directly-identifiable identity with an appropriate technical or operational process. This means the information is no longer attributable to a specific individual without the use of additional information, provided that the additional information is kept separately and is subject to technical and organizational measures to ensure that this information is not subsequently mapped to an identifiable individual.<br />
<br />
Pseudonymization techniques include algorithmic functions (such as using a one-way process to transform input identifiers into outputted ones) or tokenization process (using a bi-directional mapping process to transform input identifiers into outputted ones). A common example of the former is hashing emails to produce a new pseudonymous identifier. A common example of the latter is relying on substitution (e.g., linking the zip 90210 to “Beverly Hills,” given there are other zip codes in that California region). Algorithmic functions are preferred as strong protections than substitution or tokenization forms of pseudonymization.<ref>https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf, section A.2</ref><br />
<br />
Often “pseudonymization” is frequently confused with “[[Anonymous|anonymization]]”. Pseudonymous identifiers are not linked, but could be linked, to an individual’s identity that is held separately.<ref>https://ico.org.uk/media/about-the-ico/consultations/4019579/chapter-3-anonymisation-guidance.pdf</ref> Anonymous data cannot be linked to an individual, and as such is often excluded from data protection regulations.<ref>https://ico.org.uk/media/about-the-ico/consultations/4019579/chapter-3-anonymisation-guidance.pdf</ref>,<ref>https://gdpr-info.eu/recitals/no-26</ref> A common example of anonymized data is when it is when the input data is made available only as a summarized, aggregated output metric. <br />
<br />
== Regulator Perspectives ==<br />
GDPR recommends pseudonymization as one method to comply with data organizations’ protection obligations, such as ensuring appropriate security to safeguard personal data.<ref>https://gdpr-info.eu/art-4-gdpr</ref> <br />
* Article 6 (4-e): ”the existence of appropriate safeguards, which may include encryption or pseudonymization.”<ref>https://gdpr-info.eu/art-6-gdpr</ref><br />
* Article 32 (a): “The controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: the pseudonymization and encryption of personal data.”<ref>https://gdpr-info.eu/art-32-gdpr</ref><br />
<br />
Pseudonymization of personal data can reduce risks to data subjects and help controllers meet data-protection obligations.<ref>https://gdpr-info.eu/recitals/no-28</ref> <br />
* Article 25 (1): “Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures, such as pseudonymization, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects”<ref>https://gdpr-info.eu/art-25-gdpr</ref><br />
* Article 40 (2): “Associations and other bodies representing categories of controllers or processors may prepare codes of conduct, or amend or extend such codes, for the purpose of specifying the application of this Regulation, such as with regard to:... (d) the pseudonymization of personal data.<ref>https://gdpr-info.eu/art-40-gdpr</ref><br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Personal Data|Pseudonymous]]<br />
<br />
[[Category:Glossary|Pseudonymous]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Data_Minimization&diff=559Data Minimization2022-02-19T14:56:19Z<p>Jkoran: Created page with "Data Minimization is a process to reduce the amount of data linked to personal identifiers when providing a service. == Regulator Perspectives == GDPR recommends Data Minimi..."</p>
<hr />
<div>Data Minimization is a process to reduce the amount of data linked to personal identifiers when providing a service. <br />
<br />
== Regulator Perspectives ==<br />
GDPR recommends Data Minimization as one method to comply with data organizations’ protection obligations, such as ensuring appropriate security to safeguard personal data.<ref>https://gdpr-info.eu/art-5-gdpr</ref><br />
* Article 25 (1): “Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures, such as pseudonymization, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.”<ref>https://gdpr-info.eu/art-25-gdpr</ref><br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
== See Also ==<br />
[[Pseudonymous|Pseudonymization]]<br />
<br />
[[Category:Glossary|Data Minimization]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Pseudonymous&diff=558Pseudonymous2022-02-19T14:22:37Z<p>Jkoran: </p>
<hr />
<div>Pseudonymous means there are appropriate technical and operational processes within the organization using the identifier to keep this identifier separate from an individual’s identity. Pseudonymous information is one form of [[Personal Data]].<br />
<br />
“Pseudonymize” or “Pseudonymization” is a process to create an addressable identifier that is kept separate from an individual’s directly-identifiable identity with an appropriate technical or operational process. This means the information is no longer attributable to a specific individual without the use of additional information, provided that the additional information is kept separately and is subject to technical and organizational measures to ensure that this information is not subsequently mapped to an identifiable individual.<br />
<br />
Pseudonymization techniques include algorithmic functions (such as using a one-way process to transform input identifiers into outputted ones) or tokenization process (using a bi-directional mapping process to transform input identifiers into outputted ones). A common example of the former is hashing emails to produce a new pseudonymous identifier. A common example of the latter is relying on substitution (e.g., linking the zip 90210 to “Beverly Hills,” given there are other zip codes in that California region). Algorithmic functions are preferred as strong protections than substitution or tokenization forms of pseudonymization.<ref>https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf, section A.2</ref><br />
<br />
Often “pseudonymization” is frequently confused with “anonymization”. Pseudonymous identifiers are not linked, but could be linked, to an individual’s identity that is held separately.<ref>https://ico.org.uk/media/about-the-ico/consultations/4019579/chapter-3-anonymisation-guidance.pdf</ref> Anonymous data cannot be linked to an individual, and as such is often excluded from data protection regulations.<ref>https://ico.org.uk/media/about-the-ico/consultations/4019579/chapter-3-anonymisation-guidance.pdf</ref>,<ref>https://gdpr-info.eu/recitals/no-26</ref> A common example of anonymized data is when it is when the input data is made available only as a summarized, aggregated output metric. <br />
<br />
== Regulator Perspectives ==<br />
GDPR recommends pseudonymization as one method to comply with data organizations’ protection obligations, such as ensuring appropriate security to safeguard personal data.<ref>https://gdpr-info.eu/art-4-gdpr</ref> <br />
* Article 6 (4-e): ”the existence of appropriate safeguards, which may include encryption or pseudonymization.”<ref>https://gdpr-info.eu/art-6-gdpr</ref><br />
* Article 32 (a): “The controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: the pseudonymization and encryption of personal data.”<ref>https://gdpr-info.eu/art-32-gdpr</ref><br />
<br />
Pseudonymization of personal data can reduce risks to data subjects and help controllers meet data-protection obligations.<ref>https://gdpr-info.eu/recitals/no-28</ref> <br />
* Article 25 (1): “Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures, such as pseudonymization, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects”<ref>https://gdpr-info.eu/art-25-gdpr</ref><br />
* Article 40 (2): “Associations and other bodies representing categories of controllers or processors may prepare codes of conduct, or amend or extend such codes, for the purpose of specifying the application of this Regulation, such as with regard to:... (d) the pseudonymization of personal data.<ref>https://gdpr-info.eu/art-40-gdpr</ref><br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Personal Data|Pseudonymous]]<br />
<br />
[[Category:Glossary|Pseudonymous]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Privacy_Budget&diff=557Privacy Budget2022-02-19T14:01:02Z<p>Jkoran: </p>
<hr />
<div>"Privacy budget" (also called a "privacy loss parameter" or denoted as epsilon (ε)) controls how much noise (or fake data) is added to the original dataset.<br />
<br />
The goal of Google's “privacy budget” is to reduce organizations' ability to create a [[Statistical Identifier|statistical identifier]] from web client technographics often used to detect fraud. <br />
<br />
Privacy budget suggests that a limit on this information will be provided to an organization for each user session. Once the Google-specific limit on access to this information has been used up, Google will "stop sending correct information, substituting it with imprecise or noisy results or a generic result."<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf, paragraph 5.23</ref> <br />
<br />
Particular technographics Google wants to prevent other organizations from accessing include: <br />
* Detailed user agent strings including operating system and browser minor version;<br />
* Screen resolution, installed system fonts, and similar data;<br />
* Easily available client IP address information.<br />
<br />
The exact information that will be counting the use of this budget remains unknown.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> <br />
<br />
== Impact ==<br />
By restricting this information from other software providers, this has the risk of preventing organizations from detecting [[Non-human Traffic|non-human traffic]]. <br />
<br />
Another potential impact of removing this information is a degraded end user experience. <br />
<br />
Perhaps the largest impact of this proposal is the discrimination against smaller publishers who rely on supply-chain partners to operate and grow their business. Given the information asymmetries they face competing against larger, more established rivals, they benefit by pooling information across other small publishers to provide comparable user experiences. By reducing their ability to work with supply chain partners, given the impairment on scaled access to interoperable, pseudonymous information, many of these smaller publishers will likely need to migrate their own websites to instead "host" their content on larger publishers, thus further centralizing access to publisher content.<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Privacy Budget]]<br />
[[Category:Privacy Sandbox|Privacy Budget]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Non-personal_Data&diff=556Non-personal Data2022-02-19T13:57:39Z<p>Jkoran: </p>
<hr />
<div>Non Personal Data encompasses different contexts, which on their own do not identify a person, such as: <br />
* Time Context (e.g., time of day, day of week, seasonality) <br />
* Topic Context (e.g., genre of content being interacted with)<br />
* Technographic Context (e.g., connectivity, device, OS, Browser or App used to interact with content)<br />
<br />
[[Category:Glossary|Non Personal Data]]<br />
<br />
[[Category:Personal Data|Non Personal Data]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Privacy_Budget&diff=555Privacy Budget2022-02-13T19:48:31Z<p>Jkoran: </p>
<hr />
<div>"Privacy budget" (also called a "privacy loss parameter" or denoted as epsilon (ε)) controls how much noise (or fake data) is added to the original dataset.<br />
<br />
The goal of Google's “privacy budget” is to reduce organizations' ability to create a [[Statistical Identifier|statistical identifier]] from web client technographics often used to detect fraud. <br />
<br />
Privacy budget suggests that a limit on this information will be provided to an organization for each user session. Once the Google-specific limit on access to this information has been used up, Google will "stop sending correct information, substituting it with imprecise or noisy results or a generic result."<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf, paragraph 5.23</ref> <br />
<br />
Particular technographics Google wants to prevent other organizations from accessing include: <br />
* Detailed user agent strings including operating system and browser minor version;<br />
* Screen resolution, installed system fonts, and similar data;<br />
* Easily available client IP address information.<br />
<br />
The exact information that will be counting the use of this budget remains unknown.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> <br />
<br />
== Impact ==<br />
By removing this ability, this has the risk of preventing organizations from detecting [[Non-human Traffic|non-human traffic]]. <br />
<br />
Another potential impact of removing this information is a degraded end user experience. <br />
<br />
Perhaps the largest impact of this proposal is the discrimination against smaller publishers who rely on supply-chain partners to operate and grow their business. Given the information asymmetries they face competing against larger, more established rivals, they benefit by pooling information across other small publishers to provide comparable user experiences. By reducing their ability to work with supply chain partners, given the impairment on scaled access to interoperable, pseudonymous information, many of these smaller publishers will likely need to migrate their own websites to instead "host" their content on larger publishers, thus further centralizing access to publisher content.<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Privacy Budget]]<br />
[[Category:Privacy Sandbox|Privacy Budget]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Murre&diff=554Murre2022-02-13T19:47:25Z<p>Jkoran: </p>
<hr />
<div>Adroll's Mechanism for User Reports with Regulated [[Privacy Budget|Epsilon]] (Murre) is designed to enable machine learning based on binary inputs with noise added. The Murre proposal keeps the activity trail local to the web client, which thus requires client processing for any processing.<ref>https://github.com/AdRoll/privacy/blob/main/MURRE.md</ref><br />
<br />
Murre makes the following assumptions: <br />
* Machine learning algorithms in ad tech require granular data to function well.<br />
* Ad tech uses models of high dimension, with sparse vectors.<br />
* [[Differential Privacy|Differential Privacy]] is a framework for understanding and protecting user privacy.<br />
* The data required for effective advertising is not particularly sensitive. <br />
* Computation and network usage will be limited on the user agent. <br />
<br />
== Impact ==<br />
By limiting inputs to binary values, continuous values (e.g., price) are not supported unless they are binned into categories, which will impair the modeling process. <br />
<br />
By disclosing audience information, publishers and buyers are leaking their intellectual property associated with that web client (e.g., high value customer) to anyone with access to the web client. <br />
<br />
== Open Questions ==<br />
* What is the time-delay in providing the data necessary for publishers to optimize their revenue? <br />
* What is the time-delay in providing the data necessary for marketers to optimize their media spend?<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Murre]]<br />
[[Category:Privacy Sandbox|Murre]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Trust_Tokens&diff=550Trust Tokens2022-02-04T00:28:45Z<p>Jkoran: </p>
<hr />
<div>== Overview ==<br />
The goal of Google's Trust Tokens is to "show that a user is who they say they are."<ref>https://web.dev/trust-tokens</ref><br />
<br />
Google's Trust Tokens are “issued” by one organization (a trust provider) and “redeemed” across different publishers.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Redemption requires the consent of the issuer. The token state is stored local to a web client.<ref>https://github.com/dvorak42/trust-token-api</ref> <br />
<br />
Each individual browser stores a bank of cryptographic signed tokens that are accessible in third party contexts.<ref>https://web.dev/trust-tokens</ref> The issuer of the token validates the individual is who they say they are, but redeeming organizations are informed only that the individual was previously designated to be a person and not a robot script.<ref>https://web.dev/trust-tokens</ref> Each token can be redeemed only once.<ref>https://web.dev/trust-tokens</ref> <br />
<br />
Each issuer's tokens are unique so that for any given redemption event, "the issuer can't tell the token apart from other tokens it has created."<ref>https://web.dev/trust-tokens</ref> The issuer can use the redemption requests to understand which sites its visitors also visit. <br />
<br />
== Impact ==<br />
By removing the technographics that are often used to detect [[Non-human Traffic|non-human traffic]] via [[Privacy Budget]], marketers would not be able to rely on existing fraud detection and prevention services. Moreover, by not being able to detect which publishers' sites have relatively more non-human traffic more of marketers budgets will be spent on fraud.<br />
<br />
There is also a privacy concern that if publishers and marketers can no longer rely on a competitive market of fraud detection services, but instead the only means of validating whether a user is a human requires the web client to remember this individual has previously authenticated on at least one other web property, individuals may be forced to authenticate on more sites to generate more tokens. This would impact people's ability to navigate the web in an unauthenticated state as freely as they do today. <br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (5.20) that "Websites currently rely on identifiers and cross-site tracking to establish whether a user is trustworthy or engaged in spam or fraud."<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
Centralizing this functionality solely within the browser raises many similar concerns to those the CMA noted with Google's [[FLoC]] proposal, such as reducing competition among ad tech services currently engaged in fraud detection and advantage Google given its better ability to generate authentication events from its extensive owned and operated web properties and services. <br />
<br />
== Open Questions ==<br />
* How can the reliable quality of issuers of Trust Tokens be compared?<br />
* What validation service can redeeming organizations rely upon to ensure that a token is not copied from one web client to multiple others?<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Trust Tokens]]<br />
[[Category:Privacy Sandbox|Trust Tokens]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Trust_Tokens&diff=549Trust Tokens2022-02-04T00:24:59Z<p>Jkoran: Reverted edits by Jkoran (talk) to last revision by AdminUser</p>
<hr />
<div>Google's Trust Tokens are “issued” by one organization (a trust provider) and “redeemed” across different publishers.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Redemption requires the consent of the issuer. The token state is stored local to a web client.<ref>https://github.com/dvorak42/trust-token-api</ref> <br />
<br />
== Impact ==<br />
By removing the technographics that are often used to detect [[Non-human Traffic|non-human traffic]] via [[Privacy Budget]], marketers would not be able to rely on existing fraud detection and prevention services. Moreover, by not being able to detect which publishers' sites have relatively more non-human traffic more of marketers budgets will be spent on fraud.<br />
<br />
== Open Questions ==<br />
* Can organizations other than Google create Trust Tokens? And if so, how can their quality of trust be compared?<br />
* What validation service can redeeming organizations rely upon to ensure that a token is not copied from one web client to multiple others?<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Trust Tokens]]<br />
[[Category:Privacy Sandbox|Trust Tokens]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=PAF_Policy_and_Industry&diff=548PAF Policy and Industry2022-02-03T01:11:49Z<p>Jkoran: </p>
<hr />
<div>Policy Working Group for Policy and Industry<br />
<br />
'''Scope''': User Identifiers and Policy <br />
<br />
'''Description''': Organize communications with, manage feedback from appropriate industry bodies<br />
<br />
'''Chairs''': Joshua Koran (Criteo) <br />
<br />
'''Audience''': Product, Business, and Engineers<br />
<br />
== See Also ==<br />
* [[PAF User Experience]] <br />
<br />
* [[PAF Architecture and APIs]] <br />
<br />
== References ==<br />
* [https://docs.google.com/document/d/1wN5Q46hh30ejQifK78XTgQpz2OgT6MSz9Ysb-lcF4kw/edit Prebid Addressability Framework Foundations]<br />
* [https://docs.google.com/document/d/1YMeW6gqx65dVOpMRQf87sSldVleoG7qK7zjt_wDfdnE/edit PAF Policy and Industry Agenda & Minutes]<br />
<br />
[[Category:Prebid Project Management Committees|SSO Identity and Policy]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=PAF_Policy_and_Industry&diff=547PAF Policy and Industry2022-02-03T01:11:14Z<p>Jkoran: </p>
<hr />
<div>PAF Identity and Policy Working Group for Policy and Industry<br />
<br />
'''Scope''': User Identifiers and Policy <br />
<br />
'''Description''': Organize communications with, manage feedback from appropriate industry bodies<br />
<br />
'''Chairs''': Joshua Koran (Criteo) <br />
<br />
'''Audience''': Product, Business, and Engineers<br />
<br />
== See Also ==<br />
* [[PAF User Experience]] <br />
<br />
* [[PAF Architecture and APIs]] <br />
<br />
== References ==<br />
* [https://docs.google.com/document/d/1wN5Q46hh30ejQifK78XTgQpz2OgT6MSz9Ysb-lcF4kw/edit Prebid Addressability Framework Foundations]<br />
* [https://docs.google.com/document/d/1YMeW6gqx65dVOpMRQf87sSldVleoG7qK7zjt_wDfdnE/edit PAF Policy and Industry Agenda & Minutes]<br />
<br />
[[Category:Prebid Project Management Committees|SSO Identity and Policy]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Interoperable_Private_Attribution&diff=546Interoperable Private Attribution2022-02-03T01:10:18Z<p>Jkoran: Created page with "Meta's Interoperable Private Attribution (IPA) is designed to provide less accurate, incomplete and time-delayed data to marketers about the events associated with their adver..."</p>
<hr />
<div>Meta's Interoperable Private Attribution (IPA) is designed to provide less accurate, incomplete and time-delayed data to marketers about the events associated with their advertising. Meta acknowledges that "Advertisers need accurate reporting about how their ad campaigns are performing."<ref>https://docs.google.com/presentation/d/1NpQz0Wm73eEKw24V7B0yCjq4Tw2qPgeezhMfS0-P-TY/edit#slide=id.gf172a1733b_0_251</ref><br />
<br />
== Process ==<br />
Meta proposes that the a few organizations "with large reach" can use their knowledge of people's login data to generate a "match key." A Match key is a "Global ID" linked to a user's identity.<br />
<br />
"Any app or website can select a list of match key providers they want to use e.g. [“facebook.com”, “google.com”, “twitter.com”]".<ref>https://docs.google.com/presentation/d/1NpQz0Wm73eEKw24V7B0yCjq4Tw2qPgeezhMfS0-P-TY/edit#slide=id.gf172a1733b_0_251</ref> <br />
<br />
IPA proposes a system to attribute conversions ("trigger events") to prior exposures ("source events") using these match keys.<ref>https://docs.google.com/document/d/1KpdSKD8-Rn0bWPTu4UtK54ks0yv2j22pA5SrAD9av4s</ref><br />
<br />
Only the browser or OS would have access to read the match key as an input into its [[Multi-party Computation]] process. The joining of source events to trigger events is done server side, relying on a cryptographically modified version of the individual's match key. This deterministic encryption ("blinding") process dissociates any information to be procesed from from the original match key. As with today's attribution processs, all the exposures and conversions must be sent to the same processing system. <br />
<br />
Prior to returning the result from any query of this data, a [[Privacy Budget]] is applied to reduce risk of any other organization understanding individuals whose data is computed by the IPA system. Meta proposes the privacy budget be applied on a per requestor basis, rather than per individual as it would be "terrible for utility as queries from one site would then consumer budget for other sites."<ref>https://docs.google.com/document/d/1KpdSKD8-Rn0bWPTu4UtK54ks0yv2j22pA5SrAD9av4s</ref><br />
<br />
Note the marketer and media owner must rely on either the same match key provider OR match key providers must make their match keys interoperable. <br />
<br />
== Impact ==<br />
Because transactions are sent in batch they are slower than today's feedback mechanisms. By removing accurate, complete and real-time feedback to marketers, their ability to adjust the pricing and budget associated with advertising will be impaired. As the value marketers receive from advertising declines, so to will publisher revenues.<br />
<br />
Meta recongizes that given marketers often work with multiple partners to engage audiences across multiple media owner properties for effective advertising. This system does not currently support time-series reporting or splitting results across partners, which until addressed "could lead to adverse market effects."<ref>https://docs.google.com/document/d/1KpdSKD8-Rn0bWPTu4UtK54ks0yv2j22pA5SrAD9av4s</ref><br />
<br />
Meta states that the multiple parties processing the data (perhaps operated by separate organizations) must collude to re-identify an individual. Thus, when the data is not linked to an individual's identity it is "private." Meta does not describe why the sending of pseudonymous IDs (derived from the match key) to the IPA system exposes people to a different risk than sending pseudonymous IDs to an existing attribution vendor. For IPA to function, at some point the series of events assocaited with user activity are processed by B2B software and then onward sent to the IPA system. Some might consider this first hop in process an online risk. <br />
<br />
<br />
Meta states each site/app controls the match key providers, but does not explain why more than a single "Global ID" controlled by the user is required to generate the seed ID into this process.<br />
<br />
Meta should be commended for acknowledging the economics exist when designing systems to process the high volume of advertising events that support the open web. "In the IPA proposal, entitis will be running queries by sending batches of events to the MPC consortium for processing. This will cost money."<ref>https://docs.google.com/document/d/1KpdSKD8-Rn0bWPTu4UtK54ks0yv2j22pA5SrAD9av4s</ref> <br />
<br />
== Open Questions ==<br />
* Why should an organization that operates a browser or OS have exclusive control over the B2B advertising processing? <br />
* How will marketers value multi-touch attribution? <br />
* How can the privacy budget be applied in a way that does not advantage larger networks of sites? <br />
<br />
== See Also == <br />
* [[Aggregate Reporting API]]<br />
* [[Murre|MURRE]] is designed to address the time-delayed and aggregate impairments of machine learning Google's Aggregate Reporting API otherwise imposes<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Interoperable Private Attribution]]<br />
[[Category:Privacy Sandbox|Interoperable Private Attribution]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=545Category:Privacy Sandbox2022-02-03T00:06:48Z<p>Jkoran: /* Reporting Projects */</p>
<hr />
<div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Many of these APIs rely on server-side components. <br />
<br />
Google's head of ad products has stated that Google's Chrome plan to stop supporting third-party cookies "won’t proceed if there aren’t solutions that work for everyone while also protecting user privacy in place." <ref>https://www.adexchanger.com/adexchanger-talks/google-ads-gm-jerry-dischler-on-a-cookieless-future-that-happens-when-it-happens</ref><br />
<br />
This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br />
<br />
== Media Planning Projects == <br />
Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, planning functions that analyze the reach, frequency and cost of engaging audiences across publishers will not be directly addressed by this project. <br />
<br />
== Experience Management Projects ==<br />
Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The "right" context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br />
<br />
Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br />
<br />
A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage people using imprecise cohorts defined by Google. <br />
<br />
Privacy Sandbox would also remove information that currently is used to optimize people's web experiences, such as the appropriate size files and video resolution for the device they are interacting with the web content or being able to offer nearby recommendations.<br />
<br />
* '''Audience Management''' <br />
** '''Preference Management''' <br />
*** [[CHIPS]]<br />
*** [[Falcon]]<br />
*** [[Swan]] (Swan.community)<br />
** '''Audience Creation''' <br />
*** [[Ad Topic Hints]]<br />
*** [[First Party Sets]]<br />
*** [[FLoC]]<br />
*** [[Parakeet]] <br />
*** [[Pauraque]] (Nextroll)<br />
*** [[Petrel]] (Facebook)<br />
*** [[Sandpiper]] (CarbonRMP)<br />
*** [[Spectacle]] (Eyeo - AdBlockPlus)<br />
*** [[Swan (1plusX)]] <br />
*** [[Sushi]] (Adobe) <br />
*** [[Topics]]<br />
*** [[Turtledove]]<br />
*** '''Look-alike Modeling''' <br />
**** [[Scaup]]<br />
*** '''Fraud Detection''' <br />
**** [[Gnatcatcher]]<br />
**** [[Privacy Budget]]<br />
**** [[Trust Tokens]]<br />
**** [[User-Agent Client Hints]]<br />
*** '''Authentication''' <br />
**** [[WebID]] recently renamed [[FedCM]]<br />
**** [[Login Status API]]<br />
* '''Auction Management''' <br />
** [[Augury]]<br />
** [[Dovekey]]<br />
** [[Fenced Frames]]<br />
** [[Ibis]]<br />
** [[Macaw]] (Microsoft)<br />
** [[Parrrot]] (Magnite)<br />
** [[Puffin]] (Cafemedia)<br />
** [[Sparrow]] (Criteo)<br />
** [[Tern]] (Adroll)<br />
** [[Turtledove]]<br />
<br />
== Reporting Projects ==<br />
Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br />
<br />
A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br />
<br />
* '''Reporting Management''' <br />
** [[Aggregate Reporting API]]<br />
** [[Conversion Measurement API]]<br />
** [[Interoperable Private Attribution]] (Facebook/Meta)<br />
** [[Private Click Attribution]] (Apple)<br />
** [[Murre]] (Adroll)<br />
** [[Pelican]] (Neustar)<br />
** [[Spurfowl]] (Nextroll)<br />
<br />
== Measuring Effectiveness and Ecosystem Impact ==<br />
Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br />
<br />
Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br />
<br />
* Google's Effects of Disabling Third-party Cookies on Publisher Revenue<ref>https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf</ref><br />
* [[Fledge]]<br />
* [[Teetar]] (Criteo)<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (1.5-1.6) the following concerns with Google's Privacy Sandbox proposals that would distort competition and impose unfair terms on people who use its Chrome browser, or more specifically:<br />
<br />
# "The Privacy Sandbox Proposals have caused uncertainty in the market as to the specific alternative solutions which will be available to publishers and ad tech providers once TPCs are deprecated.... causing harm to Google’s rival publishers and ad tech providers,"<br />
# "[Google's Privacy Sandbox Proposals would] advantage its own businesses and limit competition from its rivals."<br />
# Google has an advantage due to "the asymmetry of information between Google and third parties regarding the development of the Privacy Sandbox Proposals," (e.g., roll out schedule, code-level understanding of how they work)<br />
# Google may use self-preferencing criteria "to assess different design options" (e.g., policies to quantify how much distortion in competition is acceptable if it improves Google's revenues), and <br />
# Google lack of transparency with Privacy Sandbox regarding any "evidence relating to their effectiveness against these criteria."<br />
# In addition, "given the commercial incentives that Google faces in developing Google’s Proposals"<br />
# There is at present a "lack of independent scrutiny of Google’s Proposals" (e.g., if there is disagreement about tradeoff Google would make in weighting one criteria over another)<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Glossary|Privacy Sandbox]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=544Category:Privacy Sandbox2022-02-03T00:05:35Z<p>Jkoran: /* Experience Management Projects */</p>
<hr />
<div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Many of these APIs rely on server-side components. <br />
<br />
Google's head of ad products has stated that Google's Chrome plan to stop supporting third-party cookies "won’t proceed if there aren’t solutions that work for everyone while also protecting user privacy in place." <ref>https://www.adexchanger.com/adexchanger-talks/google-ads-gm-jerry-dischler-on-a-cookieless-future-that-happens-when-it-happens</ref><br />
<br />
This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br />
<br />
== Media Planning Projects == <br />
Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, planning functions that analyze the reach, frequency and cost of engaging audiences across publishers will not be directly addressed by this project. <br />
<br />
== Experience Management Projects ==<br />
Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The "right" context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br />
<br />
Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br />
<br />
A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage people using imprecise cohorts defined by Google. <br />
<br />
Privacy Sandbox would also remove information that currently is used to optimize people's web experiences, such as the appropriate size files and video resolution for the device they are interacting with the web content or being able to offer nearby recommendations.<br />
<br />
* '''Audience Management''' <br />
** '''Preference Management''' <br />
*** [[CHIPS]]<br />
*** [[Falcon]]<br />
*** [[Swan]] (Swan.community)<br />
** '''Audience Creation''' <br />
*** [[Ad Topic Hints]]<br />
*** [[First Party Sets]]<br />
*** [[FLoC]]<br />
*** [[Parakeet]] <br />
*** [[Pauraque]] (Nextroll)<br />
*** [[Petrel]] (Facebook)<br />
*** [[Sandpiper]] (CarbonRMP)<br />
*** [[Spectacle]] (Eyeo - AdBlockPlus)<br />
*** [[Swan (1plusX)]] <br />
*** [[Sushi]] (Adobe) <br />
*** [[Topics]]<br />
*** [[Turtledove]]<br />
*** '''Look-alike Modeling''' <br />
**** [[Scaup]]<br />
*** '''Fraud Detection''' <br />
**** [[Gnatcatcher]]<br />
**** [[Privacy Budget]]<br />
**** [[Trust Tokens]]<br />
**** [[User-Agent Client Hints]]<br />
*** '''Authentication''' <br />
**** [[WebID]] recently renamed [[FedCM]]<br />
**** [[Login Status API]]<br />
* '''Auction Management''' <br />
** [[Augury]]<br />
** [[Dovekey]]<br />
** [[Fenced Frames]]<br />
** [[Ibis]]<br />
** [[Macaw]] (Microsoft)<br />
** [[Parrrot]] (Magnite)<br />
** [[Puffin]] (Cafemedia)<br />
** [[Sparrow]] (Criteo)<br />
** [[Tern]] (Adroll)<br />
** [[Turtledove]]<br />
<br />
== Reporting Projects ==<br />
Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br />
<br />
A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br />
<br />
* '''Reporting Management''' <br />
** [[Aggregate Reporting API]]<br />
** [[Conversion Measurement API]]<br />
** [[Private Click Attribution]] (Apple)<br />
** [[Murre]] (Adroll)<br />
** [[Pelican]] (Neustar)<br />
** [[Spurfowl]] (Nextroll)<br />
<br />
== Measuring Effectiveness and Ecosystem Impact ==<br />
Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br />
<br />
Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br />
<br />
* Google's Effects of Disabling Third-party Cookies on Publisher Revenue<ref>https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf</ref><br />
* [[Fledge]]<br />
* [[Teetar]] (Criteo)<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (1.5-1.6) the following concerns with Google's Privacy Sandbox proposals that would distort competition and impose unfair terms on people who use its Chrome browser, or more specifically:<br />
<br />
# "The Privacy Sandbox Proposals have caused uncertainty in the market as to the specific alternative solutions which will be available to publishers and ad tech providers once TPCs are deprecated.... causing harm to Google’s rival publishers and ad tech providers,"<br />
# "[Google's Privacy Sandbox Proposals would] advantage its own businesses and limit competition from its rivals."<br />
# Google has an advantage due to "the asymmetry of information between Google and third parties regarding the development of the Privacy Sandbox Proposals," (e.g., roll out schedule, code-level understanding of how they work)<br />
# Google may use self-preferencing criteria "to assess different design options" (e.g., policies to quantify how much distortion in competition is acceptable if it improves Google's revenues), and <br />
# Google lack of transparency with Privacy Sandbox regarding any "evidence relating to their effectiveness against these criteria."<br />
# In addition, "given the commercial incentives that Google faces in developing Google’s Proposals"<br />
# There is at present a "lack of independent scrutiny of Google’s Proposals" (e.g., if there is disagreement about tradeoff Google would make in weighting one criteria over another)<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Glossary|Privacy Sandbox]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=FLoC&diff=513FLoC2022-01-09T15:38:05Z<p>Jkoran: /* Regulator Perspectives */</p>
<hr />
<div>== Overview ==<br />
<br />
The goal of Google's Federated Learning of Cohorts (FLoC) is to reduce organizations' ability to access accurate [[Audience|audience]] membership across different publishers.<ref>https://https://github.com/WICG/floc</ref><br />
<br />
Google's FloC proposal collects and processes web client behavior across various web sites to assign each web client to a single [[cohort]] cluster.<ref>https://privacysandbox.com/proposals/floc</ref> A cohort identifier, which Google calls “flock,” is short enough string (e.g., “43A7”) such that it cannot – even with other data – be used to uniquely identify a particular device. During early trials, on each request the web client sent the cohort ID Google has assigned to this web client using the "Sec-CH-Flock" header. During current trials, FLoC membership and the version of the algorithm to assign membership is returned by the FLoC API.<ref>https://web.dev/floc</ref> <br />
<br />
The minimum number of people in a cohort is likely in the thousands.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> The original trial FLoC's used a 8-bit cohort audience ID that meant each browser would be assigned to only one of 256 possible audience segments. Google has since expanded the this to a 50-bit cohort audience ID that means each browser can be assigned to only one of 33,872 audience segments.<ref>https://www.eff.org/deeplinks/2021/03/google-testing-its-controversial-new-ad-targeting-tech-millions-browsers-heres</ref> <br />
<br />
To ensure that a minimum number of web clients is in each cohort, the web client identifier is sent to a Google controlled server to enable distinct counting. <br />
<br />
Google will reassign each browser to a FLoC, potentially the same one, once every seven days.<ref>https://privacysandbox.com/proposals/floc</ref><br />
<br />
Google began its FLoC trial on 0.5% of Chrome users in certain countries in March 2021.<ref>https://www.thedrum.com/news/2021/01/25/what-the-fk-floc-google-opens-up-post-cookie-roadmap</ref><br />
<br />
Google published a research paper that compared the accuracy of assigning browser identifiers to cohorts.<ref>https://github.com/google/ads-privacy/blob/master/proposals/FLoC/FLOC-Whitepaper-Google.pdf</ref> Google's findings were that it was able to achieve 70% accuracy in building cohort clusters relative to random assignment, which is still well below the segmentation accuracy of the current industry standard of using cookies for audience creation. <br />
<br />
The widely publicized statement that "marketers should expect to see 95% [effectiveness] when compared to cookie-based advertising,"<ref>https://blog.google/products/ads-commerce/2021-01-privacy-sandbox/</ref> was later to disclosed to the W3C that people "interpreted" the statement incorrectly given Google's experiment relied on its standard DSP that continued to rely on cookies, frequency capping and real-time optimization to achieve these results.<ref>https://www.w3.org/2021/02/02-web-adv-minutes.html</ref> The experiment also did not exclude retargeting given other Privacy Sandbox proposals are supposed to enable this audience data to improve marketers' outcomes.<ref>https://www.w3.org/2021/02/02-web-adv-minutes.html</ref> <br />
<br />
== Impact ==<br />
By removing audience segmentation, marketers would be unable to perform retargeting and frequency capping. <br />
<br />
Marketers may be able to measure which cohorts interact with their content, but would not know distinct reach or frequency. Marketers would also presumably be prohibited from associating particular outcomes on their web property with the cohort associated with the user's web client. <br />
<br />
Given FLoC membership is reassigned once every seven days, this further inhibits marketers' ability to learn which FLoCs they expose later visit their web properties, as many products and services with purchase cycles greater than seven days may influence the FLoCs that correlate the greatest with the marekter's own web property. <br />
<br />
Another potential impact of removing accurate audience segment information is a degraded end user experience. <br />
<br />
Another impact of cohorts is that they do not support smaller organizations (advertisers or publishers) as their audiences may be too small to meet the minimum threshold set by the cohort.<br />
<br />
The philosophy behind FLoC's unsupervised clustering has also been criticized as revealing sensitive information, such as people who frequent protected health conditions, or other protected classes of information. "The web currently has more than 1.2 billion sites (including parked domains). It is impractical for even a large browser developer to test for which patterns of usage of which sites are inadvertently revealing sensitive information about a user." <ref>https://github.com/WICG/floc/issues/33</ref><br />
<br />
The lack of any incentive for publishers to transfer audience building solely to Google has also been criticized. <ref>https://github.com/WICG/floc/issues/45</ref><br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (5.39-5.41) that should Google impair the accuracy of audience segments with its FLoC proposal, this would likely impair the "attractiveness of the open display market," for three reasons. Google's proposal would:<br />
<br />
# reduce competitive differentiation and lead to a "homogenization of ad inventory and ad tech services," <br />
# "reduce the ability of rivals to provide a value proposition" and <br />
# given Google's extensive owned and operated properties would inform its ad buying solutions this would advantage Google over rivals even if its migrated its own ad solutions when monetizing other publishers to rely only on FLoC audiences<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
Note: Google has made no commitment that it will rely only on FLoC audiences to monetize its own web properties.<br />
<br />
== Perspectives of Trade Body and Advocacy Groups ==<br />
Electronic Frontier Foundation (EFF) has criticized FLoC as being a "terrible idea."<ref>https://www.eff.org/deeplinks/2021/03/googles-floc-terrible-idea</ref><br />
<br />
<blockquote>Faced with growing concerns about privacy, the company proposes to solve them by making itself the protector of our privacy, walling us off from third-party tracking except when Google does it.<ref>https://www.eff.org/deeplinks/2021/04/fighting-floc-and-fighting-monopoly-are-fully-compatible</ref></blockquote> <br />
<br />
Given Google relies on unsupervised learning, EFF criticizes Google's design given some FLoCs are likely to consist of sensitive category information, such as members of a protect class whose web behaviors are similar. Google did analyze the synced browsing history of its Chrome users and validated this concern, given many FLoCs did express browsing activity that could be used to ascribe a sensitive category label to that FLoC.<ref>https://docs.google.com/a/google.com/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDo1Mzg4MjYzOWI2MzU2NDgw</ref> Google suggested that by sending such browsing activity to its servers, it could analyze whether individuals who have been assigned to a given FLoC interact more frequently with sensitive category data, so that Google can suppress these FLoCs from being used for advertising.<ref>https://docs.google.com/a/google.com/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDo1Mzg4MjYzOWI2MzU2NDgw</ref> <br />
<br />
EFF also criticizes Google's design given there is little notice or choice provided to people for Google's use of the consumer browser software to generate a business-to-business ads product.<ref>https://www.eff.org/deeplinks/2021/03/google-testing-its-controversial-new-ad-targeting-tech-millions-browsers-heres</ref><br />
<br />
== Open Questions ==<br />
* What is the value impairment associated with shifting from marketer-defined audiences to Google-defined cohorts, even if frequency capping and real-time optimization were still available? <br />
* How frequently would algorithms that assign FLoC audiences changes? <br />
* What oversight would exit to review whether changes to FLoC audience creation algorithm is better for users, publishers, marketers and the supply chain vendors they rely upon to operate their businesses? <br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
<br />
[[Category:Glossary|FLoC]]<br />
[[Category:Privacy Sandbox|FLoC]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=FLoC&diff=512FLoC2022-01-09T15:36:48Z<p>Jkoran: /* Regulator Perspectives */</p>
<hr />
<div>== Overview ==<br />
<br />
The goal of Google's Federated Learning of Cohorts (FLoC) is to reduce organizations' ability to access accurate [[Audience|audience]] membership across different publishers.<ref>https://https://github.com/WICG/floc</ref><br />
<br />
Google's FloC proposal collects and processes web client behavior across various web sites to assign each web client to a single [[cohort]] cluster.<ref>https://privacysandbox.com/proposals/floc</ref> A cohort identifier, which Google calls “flock,” is short enough string (e.g., “43A7”) such that it cannot – even with other data – be used to uniquely identify a particular device. During early trials, on each request the web client sent the cohort ID Google has assigned to this web client using the "Sec-CH-Flock" header. During current trials, FLoC membership and the version of the algorithm to assign membership is returned by the FLoC API.<ref>https://web.dev/floc</ref> <br />
<br />
The minimum number of people in a cohort is likely in the thousands.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> The original trial FLoC's used a 8-bit cohort audience ID that meant each browser would be assigned to only one of 256 possible audience segments. Google has since expanded the this to a 50-bit cohort audience ID that means each browser can be assigned to only one of 33,872 audience segments.<ref>https://www.eff.org/deeplinks/2021/03/google-testing-its-controversial-new-ad-targeting-tech-millions-browsers-heres</ref> <br />
<br />
To ensure that a minimum number of web clients is in each cohort, the web client identifier is sent to a Google controlled server to enable distinct counting. <br />
<br />
Google will reassign each browser to a FLoC, potentially the same one, once every seven days.<ref>https://privacysandbox.com/proposals/floc</ref><br />
<br />
Google began its FLoC trial on 0.5% of Chrome users in certain countries in March 2021.<ref>https://www.thedrum.com/news/2021/01/25/what-the-fk-floc-google-opens-up-post-cookie-roadmap</ref><br />
<br />
Google published a research paper that compared the accuracy of assigning browser identifiers to cohorts.<ref>https://github.com/google/ads-privacy/blob/master/proposals/FLoC/FLOC-Whitepaper-Google.pdf</ref> Google's findings were that it was able to achieve 70% accuracy in building cohort clusters relative to random assignment, which is still well below the segmentation accuracy of the current industry standard of using cookies for audience creation. <br />
<br />
The widely publicized statement that "marketers should expect to see 95% [effectiveness] when compared to cookie-based advertising,"<ref>https://blog.google/products/ads-commerce/2021-01-privacy-sandbox/</ref> was later to disclosed to the W3C that people "interpreted" the statement incorrectly given Google's experiment relied on its standard DSP that continued to rely on cookies, frequency capping and real-time optimization to achieve these results.<ref>https://www.w3.org/2021/02/02-web-adv-minutes.html</ref> The experiment also did not exclude retargeting given other Privacy Sandbox proposals are supposed to enable this audience data to improve marketers' outcomes.<ref>https://www.w3.org/2021/02/02-web-adv-minutes.html</ref> <br />
<br />
== Impact ==<br />
By removing audience segmentation, marketers would be unable to perform retargeting and frequency capping. <br />
<br />
Marketers may be able to measure which cohorts interact with their content, but would not know distinct reach or frequency. Marketers would also presumably be prohibited from associating particular outcomes on their web property with the cohort associated with the user's web client. <br />
<br />
Given FLoC membership is reassigned once every seven days, this further inhibits marketers' ability to learn which FLoCs they expose later visit their web properties, as many products and services with purchase cycles greater than seven days may influence the FLoCs that correlate the greatest with the marekter's own web property. <br />
<br />
Another potential impact of removing accurate audience segment information is a degraded end user experience. <br />
<br />
Another impact of cohorts is that they do not support smaller organizations (advertisers or publishers) as their audiences may be too small to meet the minimum threshold set by the cohort.<br />
<br />
The philosophy behind FLoC's unsupervised clustering has also been criticized as revealing sensitive information, such as people who frequent protected health conditions, or other protected classes of information. "The web currently has more than 1.2 billion sites (including parked domains). It is impractical for even a large browser developer to test for which patterns of usage of which sites are inadvertently revealing sensitive information about a user." <ref>https://github.com/WICG/floc/issues/33</ref><br />
<br />
The lack of any incentive for publishers to transfer audience building solely to Google has also been criticized. <ref>https://github.com/WICG/floc/issues/45</ref><br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (5.39-5.41) that should Google impair the accuracy of audience segments with its FLoC proposal, this would likely impair the "attractiveness of the open display market," for three reasons. Google's proposal would:<br />
<br />
# reduce competitive differentiation and lead to a "homogenization of ad inventory and ad tech services," <br />
# "reduce the ability of rivals to provide a value proposition" and <br />
# given Google's extensive owned and operated properties would inform its ad buying solutions advantage over rivals even if its migrated its own ad solutions to rely only on FLoC audiences<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
Note: Google has made no commitment that it will rely only on FLoC audiences to monetize its own web properties.<br />
<br />
== Perspectives of Trade Body and Advocacy Groups ==<br />
Electronic Frontier Foundation (EFF) has criticized FLoC as being a "terrible idea."<ref>https://www.eff.org/deeplinks/2021/03/googles-floc-terrible-idea</ref><br />
<br />
<blockquote>Faced with growing concerns about privacy, the company proposes to solve them by making itself the protector of our privacy, walling us off from third-party tracking except when Google does it.<ref>https://www.eff.org/deeplinks/2021/04/fighting-floc-and-fighting-monopoly-are-fully-compatible</ref></blockquote> <br />
<br />
Given Google relies on unsupervised learning, EFF criticizes Google's design given some FLoCs are likely to consist of sensitive category information, such as members of a protect class whose web behaviors are similar. Google did analyze the synced browsing history of its Chrome users and validated this concern, given many FLoCs did express browsing activity that could be used to ascribe a sensitive category label to that FLoC.<ref>https://docs.google.com/a/google.com/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDo1Mzg4MjYzOWI2MzU2NDgw</ref> Google suggested that by sending such browsing activity to its servers, it could analyze whether individuals who have been assigned to a given FLoC interact more frequently with sensitive category data, so that Google can suppress these FLoCs from being used for advertising.<ref>https://docs.google.com/a/google.com/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDo1Mzg4MjYzOWI2MzU2NDgw</ref> <br />
<br />
EFF also criticizes Google's design given there is little notice or choice provided to people for Google's use of the consumer browser software to generate a business-to-business ads product.<ref>https://www.eff.org/deeplinks/2021/03/google-testing-its-controversial-new-ad-targeting-tech-millions-browsers-heres</ref><br />
<br />
== Open Questions ==<br />
* What is the value impairment associated with shifting from marketer-defined audiences to Google-defined cohorts, even if frequency capping and real-time optimization were still available? <br />
* How frequently would algorithms that assign FLoC audiences changes? <br />
* What oversight would exit to review whether changes to FLoC audience creation algorithm is better for users, publishers, marketers and the supply chain vendors they rely upon to operate their businesses? <br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
<br />
[[Category:Glossary|FLoC]]<br />
[[Category:Privacy Sandbox|FLoC]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Trust_Tokens&diff=511Trust Tokens2021-12-22T15:54:47Z<p>Jkoran: </p>
<hr />
<div>== Overview ==<br />
The goal of Google's Trust Tokens is to "show that a user is who they say they are."<ref>https://web.dev/trust-tokens</ref><br />
<br />
Google's Trust Tokens are “issued” by one organization (a trust provider) and “redeemed” across different publishers.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Redemption requires the consent of the issuer. The token state is stored local to a web client.<ref>https://github.com/dvorak42/trust-token-api</ref> <br />
<br />
Each individual browser stores a bank of cryptographic signed tokens that are accessible in third party contexts.<ref>https://web.dev/trust-tokens</ref> The issuer of the token validates the individual is who they say they are, but redeeming organizations are informed only that the individual was previously designated to be a person and not a robot script.<ref>https://web.dev/trust-tokens</ref> Each token can be redeemed only once.<ref>https://web.dev/trust-tokens</ref> <br />
<br />
Each issuer's tokens are unique so that for any given redemption event, "the issuer can't tell the token apart from other tokens it has created."<ref>https://web.dev/trust-tokens</ref> The issuer can use the redemption requests to understand which sites its visitors also visit. <br />
<br />
== Impact ==<br />
By removing the technographics that are often used to detect [[Non-human Traffic|non-human traffic]] via [[Privacy Budget]], marketers would not be able to rely on existing fraud detection and prevention services. Moreover, by not being able to detect which publishers' sites have relatively more non-human traffic more of marketers budgets will be spent on fraud.<br />
<br />
There is also a privacy concern that if publishers and marketers can no longer rely on a competitive market of fraud detection services, but instead the only means of validating whether a user is a human requires the web client to remember this individual has previously authenticated on at least one other web property, individuals may be forced to authenticate on more sites to generate more tokens. This would impact people's ability to navigate the web in an unauthenticated state as freely as they do today. <br />
<br />
Additionally, trust tokens do not actually solve for fraud. For example, a valid user who is authenticated by a trust issuer, does not ensure their client is not infected by a malicious script to fire fraudulent traffic (e.g., open multiple tabs after the user steps away from the machine). Without granular tracking over time, most of fraud detection will suffer.<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (5.20) that "Websites currently rely on identifiers and cross-site tracking to establish whether a user is trustworthy or engaged in spam or fraud."<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
Centralizing this functionality solely within the browser raises many similar concerns to those the CMA noted with Google's [[FLoC]] proposal, such as reducing competition among ad tech services currently engaged in fraud detection and advantage Google given its better ability to generate authentication events from its extensive owned and operated web properties and services. <br />
<br />
== Open Questions ==<br />
* How can the reliable quality of issuers of Trust Tokens be compared?<br />
* What validation service can redeeming organizations rely upon to ensure that a token is not copied from one web client to multiple others?<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Trust Tokens]]<br />
[[Category:Privacy Sandbox|Trust Tokens]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Puffin&diff=506Puffin2021-11-17T15:50:44Z<p>Jkoran: /* Impact */</p>
<hr />
<div>Cafemedia’s Personal User Floor For Impression Negotiations (Puffin) aims to improve publisher inventory monetization by setting a per-browser, per-ad type price floor based on historical auction data for each placement by ad category for each publisher.<ref>https://github.com/dmarti/PUFFIN</ref> The proposal aims to increase value for content relative to interest-based advertising, by increasing the price floor solely for interest-based ads. This delta in pricing suggests more context-only ads would win auctions relative to today. The notion is that increasing revenues for high-quality content producing sites encourages greater production of such content "in the interests of the user and of the ad-supported sites whose content they prefer."<ref>https://github.com/dmarti/PUFFIN</ref><br />
<br />
Puffin adopts Google’s Privacy Sandbox goal of disintermediating publishers from the marketers that fund their digital properties.<br />
<br />
== Overview ==<br />
Puffin builds on the trusted-server model of required by [[Turtledove]]/[[Fledge]]. Unlike Fledge, Puffin allows real-time, per publisher per ad unit per browser price floors based purely on prior auctions that relied solely on current context.<br />
<br />
"The interest-based ad wins (and is displayed to the user) if it can outbid the contextual ad. A PUFFIN is a persistent per-browser floor price that the interest-group ad bid must also exceed in order to win the auction. Each PUFFIN is calculated based on an exponentially weighted rolling average of winning contextual ad bids. Losing bids and interest-group bids never affect PUFFIN."<ref>https://github.com/dmarti/PUFFIN</ref><br />
<br />
The price floors are stored in the browser for each ad unit type and placement per publisher. "The browser maintains one PUFFIN for each ad unit type that can be detected automatically. For example, a video ad and large leaderboard ad would each have a different PUFFIN from a small, below-the-fold ad."<ref>https://github.com/dmarti/PUFFIN</ref><br />
<br />
The price floors are also calculated per ad category, such that auto ads may have a different floor than travel ads. "With PUFFIN, in order for the interest-based ad to win the in-browser auction, it must beat not only the highest-bidding contextual ad, but also the PUFFIN for ads of the same category that have previously appeared in the same browser."<ref>https://github.com/dmarti/PUFFIN</ref><br />
<br />
For example, if a given ad slot usually monetizes via context at $1.00, then an interest-base ad must always exceed $1.00 even if all context bids for a given auction were only $0.50. In the case that an interest-based ad were $0.90, Puffin would have the browser choose the lower monetizing contextual-only ad. Note: as this example illustrates this will reduce yield if publisher inventory is forced to monetize for the lower priced ad.<br />
<br />
Unlike other interest-based advertising proposals (e.g., [[Pauraque]]), Puffin does not expose any of information to auction participants. "PUFFIN is confidential and per-browser, and is not available to any script."<ref>https://github.com/dmarti/PUFFIN</ref><br />
<br />
== Impact ==<br />
Unlike other Privacy Sandbox proposals that nominally allude to improving people's privacy, Puffin is designed to ask the browser to steer money towards certain sites based on analyzing people's online activity. People do not control the ad content they see, for the simple reason they do not pay publishers (or content owners) to view that content. The Puffin author acknowledges that people also do not sell their attention when they access ad-funded sites, which instead rely on B2B advertising solutions that negotiate between the publisher (seller) and marketer (buyer) of the ad space: "No one will click through to their morning news and act as own auctioneer for any ad they will be seeing."<ref>https://lists.w3.org/Archives/Public/public-web-adv/2021Nov/0010.html</ref> <br />
<br />
Because of the different price floor for interest-only ads than contextual-only ads, there will be a higher spread in auction prices than today. <br />
<br />
Merely changing the price point for interest ads to win auctions does not reduce the value marketers receive from focusing limited spend on audience-based dimensions (i.e. [[Interest_Based_Advertising|interest-based advertising]]). Puffin assumes that the audience information used by marketers to improve their outcomes is generated solely from high-engagement, high-reputation sites. Interest-based advertising leads to "Leakage of ad revenue from high-engagement, high-reputation sites to lower-engagement sites where the same audience appears to be available."<ref>https://github.com/dmarti/PUFFIN</ref> However, retargeting is one example where the interest-based information comes exclusively from marketers' own data. [[Onboarding]] is another case that illustrates this.<br />
<br />
Thus, it is unlikely that prices for context-only ads would increase due to the lack of any increase in value generated from this proposal. <br />
<br />
One unwritten assumption of Puffin may be that by reducing the availability of interest-based advertising inventory, marketers would shift their budgets to context-only advertising, thus increasing demand and through this iterative game-theory mechanism increase prices for context-only advertising. Such an assumption relies on another unwritten assumption that marketers would no longer have access to Walled Garden advertising solutions that continue to offer interest-based advertising with contextual targeting and real-time optimization, to message the right audience in the right context at the right time at the right price. These assumptions would rely on Privacy Sandbox eliminating its current first-party and corporate-ownership exemptions (e.g., [[First_Party_Sets|First Party Sets]]) to data collection and processing. <br />
<br />
As with other Privacy Sandbox proposals that migrate B2B processing to the client, the incremental storage and processing cost for maintaining per publisher, per ad unit, per placement per ad category auctions must be borne by consumers. This may degrade user experience or drain their mobile batteries.<br />
<br />
== Open Questions ==<br />
* What is the impact on web experiences given many client devices do not have the same processing power of the servers that currently select which content to render?<br />
* How does the local client auction support publisher custom logic, such as factors other than price to select which ad to render?<br />
<br />
== See Also ==<br />
* [[First_Party_Sets|First Party Sets]]<br />
* [[Fledge]]<br />
* [[Interest_Based_Advertising|Interest Based Advertising]]<br />
* [[Turtledove]]<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Puffin]] <br />
[[Category:Privacy Sandbox|Puffin]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Teetar&diff=505Teetar2021-10-21T18:15:19Z<p>Jkoran: </p>
<hr />
<div>Criteo's Testing Environment Enabling Truthful and Actionable Results (TEETAR) is a proposal to measure the effectiveness of Google's [[Turtledove]] auction mechanism as being a viable replacement for the interoperable identifiers that support the decentralized, open web.<ref>https://github.com/criteo/privacy/tree/main/TEETAR</ref> <br />
<br />
TEETAR has three goals: <br />
<br />
* Evaluate the economic impact of using [[Cohort|cohorts]]. <br />
* Evaluate the experience and perception of users exposed to cohort-based advertising.<br />
* Identify how proposals parameters (e.g., cohort sizes) influence the above two.<br />
<br />
TEETER proposes using CPM to measure the economic impact on ecosystem welfare, defined as the value exchanged through advertising, as it directly correlates to both publishers' revenue and advertiser spend.<br />
<br />
TEETER proposes using a Net Promoter Score metric for measuring the users' perception of cohort-based advertising.<br />
<br />
<br />
== Open Questions ==<br />
* How much data must be collected to quantify the impact of cohort-based advertising? <br />
<br />
<br />
== See Also ==<br />
[[Fledge]]<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
<br />
[[Category:Glossary|Teetar]]<br />
[[Category:Privacy Sandbox|Teetar]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=FedCM&diff=484FedCM2021-10-18T00:02:05Z<p>Jkoran: Redirected page to WebID</p>
<hr />
<div>#REDIRECT [[WebID]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=483Category:Privacy Sandbox2021-10-18T00:01:04Z<p>Jkoran: /* Experience Management Projects */</p>
<hr />
<div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Many of these APIs rely on server-side components. <br />
<br />
Google's head of ad products has stated that Google's Chrome plan to stop supporting third-party cookies "won’t proceed if there aren’t solutions that work for everyone while also protecting user privacy in place." <ref>https://www.adexchanger.com/adexchanger-talks/google-ads-gm-jerry-dischler-on-a-cookieless-future-that-happens-when-it-happens</ref><br />
<br />
This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br />
<br />
== Media Planning Projects == <br />
Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, planning functions that analyze the reach, frequency and cost of engaging audiences across publishers will not be directly addressed by this project. <br />
<br />
== Experience Management Projects ==<br />
Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The "right" context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br />
<br />
Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br />
<br />
A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage people using imprecise cohorts defined by Google. <br />
<br />
Privacy Sandbox would also remove information that currently is used to optimize people's web experiences, such as the appropriate size files and video resolution for the device they are interacting with the web content or being able to offer nearby recommendations.<br />
<br />
* '''Audience Management''' <br />
** '''Preference Management''' <br />
*** [[CHIPS]]<br />
*** [[Falcon]]<br />
*** [[Swan]] (Swan.community)<br />
** '''Audience Creation''' <br />
*** [[Ad Topic Hints]]<br />
*** [[First Party Sets]]<br />
*** [[FLoC]]<br />
*** [[Parakeet]] <br />
*** [[Pauraque]] (Nextroll)<br />
*** [[Petrel]] (Facebook)<br />
*** [[Sandpiper]] (CarbonRMP)<br />
*** [[Spectacle]] (Eyeo - AdBlockPlus)<br />
*** [[Swan (1plusX)]] <br />
*** [[Sushi]] (Adobe) <br />
*** [[Turtledove]]<br />
*** '''Look-alike Modeling''' <br />
**** [[Scaup]]<br />
*** '''Fraud Detection''' <br />
**** [[Gnatcatcher]]<br />
**** [[Privacy Budget]]<br />
**** [[Trust Tokens]]<br />
**** [[User-Agent Client Hints]]<br />
*** '''Authentication''' <br />
**** [[WebID]] recently renamed [[FedCM]]<br />
**** [[Login Status API]]<br />
* '''Auction Management''' <br />
** [[Augury]]<br />
** [[Dovekey]]<br />
** [[Fenced Frames]]<br />
** [[Ibis]]<br />
** [[Macaw]] (Microsoft)<br />
** [[Parrrot]] (Magnite)<br />
** [[Puffin]] (Cafemedia)<br />
** [[Sparrow]] (Criteo)<br />
** [[Tern]] (Adroll)<br />
** [[Turtledove]]<br />
<br />
== Reporting Projects ==<br />
Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br />
<br />
A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br />
<br />
* '''Reporting Management''' <br />
** [[Aggregate Reporting API]]<br />
** [[Conversion Measurement API]]<br />
** [[Private Click Attribution]] (Apple)<br />
** [[Murre]] (Adroll)<br />
** [[Pelican]] (Neustar)<br />
** [[Spurfowl]] (Nextroll)<br />
<br />
== Measuring Effectiveness and Ecosystem Impact ==<br />
Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br />
<br />
Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br />
<br />
* Google's Effects of Disabling Third-party Cookies on Publisher Revenue<ref>https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf</ref><br />
* [[Fledge]]<br />
* [[Teetar]] (Criteo)<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (1.5-1.6) the following concerns with Google's Privacy Sandbox proposals that would distort competition and impose unfair terms on people who use its Chrome browser, or more specifically:<br />
<br />
# "The Privacy Sandbox Proposals have caused uncertainty in the market as to the specific alternative solutions which will be available to publishers and ad tech providers once TPCs are deprecated.... causing harm to Google’s rival publishers and ad tech providers,"<br />
# "[Google's Privacy Sandbox Proposals would] advantage its own businesses and limit competition from its rivals."<br />
# Google has an advantage due to "the asymmetry of information between Google and third parties regarding the development of the Privacy Sandbox Proposals," (e.g., roll out schedule, code-level understanding of how they work)<br />
# Google may use self-preferencing criteria "to assess different design options" (e.g., policies to quantify how much distortion in competition is acceptable if it improves Google's revenues), and <br />
# Google lack of transparency with Privacy Sandbox regarding any "evidence relating to their effectiveness against these criteria."<br />
# In addition, "given the commercial incentives that Google faces in developing Google’s Proposals"<br />
# There is at present a "lack of independent scrutiny of Google’s Proposals" (e.g., if there is disagreement about tradeoff Google would make in weighting one criteria over another)<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Glossary|Privacy Sandbox]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=WebID&diff=482WebID2021-10-18T00:00:18Z<p>Jkoran: </p>
<hr />
<div>== Overview ==<br />
Google's WebID is designed to disintermediate publishers from their visitors.<ref>https://github.com/samuelgoto/WebID/blob/master/consumers.md#the-delegation-oriented-variation</ref> Recently Google renamed this initiative to "FedCM," to represent Federated Credential Management.<ref>https://wicg.github.io/FedCM</ref><br />
<br />
WebID moves the sign-in (also called "authentication") process from the competitive market of authentication service providers into the web client browser. Authentication service providers are also called "Identity Providers (IDP)" or "issuers."<br />
<br />
Google suggests that when people authenticate into web properties they primarily want to do so anonymously.<ref>https://docs.google.com/presentation/d/1Sym0k84omyL5Ls1lO6w4aGQ-s4EHrDzo8ZlheyzFOlw/edit#slide=id.ga40b1e6d4f_0_77</ref><br />
<br />
Google has proposed three variants of WebID:<br />
<br />
# Permission prompt. Web client presents warnings associated with organization's request for the user to sign-in.<br />
# Mediation. Consent prompts are bundled with the user's initial action to request to sign-in, such as always declaring their offline identity. Under the WebID mediation model, Google states that its web client will control all defaults.<ref>https://github.com/samuelgoto/WebID/blob/master/mediation_oriented_api.md</ref> <br />
# Delegation. Under this model the authentication service provider is unaware of which service a user is authenticating into.<ref>https://docs.google.com/presentation/d/1Sym0k84omyL5Ls1lO6w4aGQ-s4EHrDzo8ZlheyzFOlw/edit#slide=id.ga40b1e6d4f_0_77</ref><br />
<br />
== Impact ==<br />
Google recognizes that many websites require authentication (e.g., email service providers, subscription, purchase and registration). However, adding popup warnings for actions that clearly require user input and choice adds additional friction to the user experience. <br />
<br />
By disintermediating organizations from the people who choose to authenticate into their service, would likely lead to publishers only accepting authentication credentials known to be useful for proactively communicating with their registered users and validating specific information about them. Organizations might for example rely on a service that ensures the registered users do not engage in fraudulent activity with other organizations. <br />
<br />
This effort seems targeted at hashed-email based solutions, such as [[UID2]].<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (5.26,5.47,5.78) that should Google impair the user experience provided by rivals, "Chrome would have access to all the user’s log in data, which it could choose to share with Google’s advertising services after the introduction of the proposals." This concern is substantiated by Chrome already sending a browser identifier called "X-Client Data" exclusively to Google controlled web properties. <br />
<br />
The UK also noted by moving authentication into the browser, "the browser adds more friction (eg in the form of permission prompts) or takes control of choice architecture around the use of federated log-in."<br />
<br />
The UK CMA noted Google's proposal would:<br />
<br />
# "lead to Google’s rival publishers offering a worse service to both users and advertisers when competing with Google to attract advertiser spend to their ad inventory," <br />
# "add friction to the user experience and lead to user frustration, reducing user visits,"<br />
# "lead to the disintermediation of publishers with harmful consequences for their ability to track users on their properties."<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
Note: Google has made no commitment that it will apply WebID for managing the authentication on its own web properties and services. <br />
<br />
== Open Questions == <br />
* Will Google allow people to opt out of Google's WebID notifications?<br />
* What terms and conditions will Google's WebID offer to people?<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|WebID]]<br />
[[Category:Privacy Sandbox|WebID]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=WebID&diff=481WebID2021-10-18T00:00:06Z<p>Jkoran: </p>
<hr />
<div>== Overview ==<br />
Google's WebID is designed to disintermediate publishers from their visitors.<ref>https://github.com/samuelgoto/WebID/blob/master/consumers.md#the-delegation-oriented-variation</ref> Recently Google renamed this initiative to "FedCM," to represent Federated Credential Management.<ref>https://wicg.github.io/FedCM<ref><br />
<br />
WebID moves the sign-in (also called "authentication") process from the competitive market of authentication service providers into the web client browser. Authentication service providers are also called "Identity Providers (IDP)" or "issuers."<br />
<br />
Google suggests that when people authenticate into web properties they primarily want to do so anonymously.<ref>https://docs.google.com/presentation/d/1Sym0k84omyL5Ls1lO6w4aGQ-s4EHrDzo8ZlheyzFOlw/edit#slide=id.ga40b1e6d4f_0_77</ref><br />
<br />
Google has proposed three variants of WebID:<br />
<br />
# Permission prompt. Web client presents warnings associated with organization's request for the user to sign-in.<br />
# Mediation. Consent prompts are bundled with the user's initial action to request to sign-in, such as always declaring their offline identity. Under the WebID mediation model, Google states that its web client will control all defaults.<ref>https://github.com/samuelgoto/WebID/blob/master/mediation_oriented_api.md</ref> <br />
# Delegation. Under this model the authentication service provider is unaware of which service a user is authenticating into.<ref>https://docs.google.com/presentation/d/1Sym0k84omyL5Ls1lO6w4aGQ-s4EHrDzo8ZlheyzFOlw/edit#slide=id.ga40b1e6d4f_0_77</ref><br />
<br />
== Impact ==<br />
Google recognizes that many websites require authentication (e.g., email service providers, subscription, purchase and registration). However, adding popup warnings for actions that clearly require user input and choice adds additional friction to the user experience. <br />
<br />
By disintermediating organizations from the people who choose to authenticate into their service, would likely lead to publishers only accepting authentication credentials known to be useful for proactively communicating with their registered users and validating specific information about them. Organizations might for example rely on a service that ensures the registered users do not engage in fraudulent activity with other organizations. <br />
<br />
This effort seems targeted at hashed-email based solutions, such as [[UID2]].<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (5.26,5.47,5.78) that should Google impair the user experience provided by rivals, "Chrome would have access to all the user’s log in data, which it could choose to share with Google’s advertising services after the introduction of the proposals." This concern is substantiated by Chrome already sending a browser identifier called "X-Client Data" exclusively to Google controlled web properties. <br />
<br />
The UK also noted by moving authentication into the browser, "the browser adds more friction (eg in the form of permission prompts) or takes control of choice architecture around the use of federated log-in."<br />
<br />
The UK CMA noted Google's proposal would:<br />
<br />
# "lead to Google’s rival publishers offering a worse service to both users and advertisers when competing with Google to attract advertiser spend to their ad inventory," <br />
# "add friction to the user experience and lead to user frustration, reducing user visits,"<br />
# "lead to the disintermediation of publishers with harmful consequences for their ability to track users on their properties."<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
Note: Google has made no commitment that it will apply WebID for managing the authentication on its own web properties and services. <br />
<br />
== Open Questions == <br />
* Will Google allow people to opt out of Google's WebID notifications?<br />
* What terms and conditions will Google's WebID offer to people?<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|WebID]]<br />
[[Category:Privacy Sandbox|WebID]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=480Category:Privacy Sandbox2021-10-17T23:50:06Z<p>Jkoran: /* Experience Management Projects */</p>
<hr />
<div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Many of these APIs rely on server-side components. <br />
<br />
Google's head of ad products has stated that Google's Chrome plan to stop supporting third-party cookies "won’t proceed if there aren’t solutions that work for everyone while also protecting user privacy in place." <ref>https://www.adexchanger.com/adexchanger-talks/google-ads-gm-jerry-dischler-on-a-cookieless-future-that-happens-when-it-happens</ref><br />
<br />
This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br />
<br />
== Media Planning Projects == <br />
Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, planning functions that analyze the reach, frequency and cost of engaging audiences across publishers will not be directly addressed by this project. <br />
<br />
== Experience Management Projects ==<br />
Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The "right" context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br />
<br />
Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br />
<br />
A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage people using imprecise cohorts defined by Google. <br />
<br />
Privacy Sandbox would also remove information that currently is used to optimize people's web experiences, such as the appropriate size files and video resolution for the device they are interacting with the web content or being able to offer nearby recommendations.<br />
<br />
* '''Audience Management''' <br />
** '''Preference Management''' <br />
*** [[CHIPS]]<br />
*** [[Falcon]]<br />
*** [[Swan]] (Swan.community)<br />
** '''Audience Creation''' <br />
*** [[Ad Topic Hints]]<br />
*** [[First Party Sets]]<br />
*** [[FLoC]]<br />
*** [[Parakeet]] <br />
*** [[Pauraque]] (Nextroll)<br />
*** [[Petrel]] (Facebook)<br />
*** [[Sandpiper]] (CarbonRMP)<br />
*** [[Spectacle]] (Eyeo - AdBlockPlus)<br />
*** [[Swan (1plusX)]] <br />
*** [[Sushi]] (Adobe) <br />
*** [[Turtledove]]<br />
*** '''Look-alike Modeling''' <br />
**** [[Scaup]]<br />
*** '''Fraud Detection''' <br />
**** [[Gnatcatcher]]<br />
**** [[Privacy Budget]]<br />
**** [[Trust Tokens]]<br />
**** [[User-Agent Client Hints]]<br />
*** '''Authentication''' <br />
**** [[WebID]]<br />
**** [[Login Status API]]<br />
* '''Auction Management''' <br />
** [[Augury]]<br />
** [[Dovekey]]<br />
** [[Fenced Frames]]<br />
** [[Ibis]]<br />
** [[Macaw]] (Microsoft)<br />
** [[Parrrot]] (Magnite)<br />
** [[Puffin]] (Cafemedia)<br />
** [[Sparrow]] (Criteo)<br />
** [[Tern]] (Adroll)<br />
** [[Turtledove]]<br />
<br />
== Reporting Projects ==<br />
Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br />
<br />
A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br />
<br />
* '''Reporting Management''' <br />
** [[Aggregate Reporting API]]<br />
** [[Conversion Measurement API]]<br />
** [[Private Click Attribution]] (Apple)<br />
** [[Murre]] (Adroll)<br />
** [[Pelican]] (Neustar)<br />
** [[Spurfowl]] (Nextroll)<br />
<br />
== Measuring Effectiveness and Ecosystem Impact ==<br />
Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br />
<br />
Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br />
<br />
* Google's Effects of Disabling Third-party Cookies on Publisher Revenue<ref>https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf</ref><br />
* [[Fledge]]<br />
* [[Teetar]] (Criteo)<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (1.5-1.6) the following concerns with Google's Privacy Sandbox proposals that would distort competition and impose unfair terms on people who use its Chrome browser, or more specifically:<br />
<br />
# "The Privacy Sandbox Proposals have caused uncertainty in the market as to the specific alternative solutions which will be available to publishers and ad tech providers once TPCs are deprecated.... causing harm to Google’s rival publishers and ad tech providers,"<br />
# "[Google's Privacy Sandbox Proposals would] advantage its own businesses and limit competition from its rivals."<br />
# Google has an advantage due to "the asymmetry of information between Google and third parties regarding the development of the Privacy Sandbox Proposals," (e.g., roll out schedule, code-level understanding of how they work)<br />
# Google may use self-preferencing criteria "to assess different design options" (e.g., policies to quantify how much distortion in competition is acceptable if it improves Google's revenues), and <br />
# Google lack of transparency with Privacy Sandbox regarding any "evidence relating to their effectiveness against these criteria."<br />
# In addition, "given the commercial incentives that Google faces in developing Google’s Proposals"<br />
# There is at present a "lack of independent scrutiny of Google’s Proposals" (e.g., if there is disagreement about tradeoff Google would make in weighting one criteria over another)<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Glossary|Privacy Sandbox]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Login_Status_API&diff=479Login Status API2021-10-17T23:49:21Z<p>Jkoran: Created page with "== Overview == Apple's Login Status API (previously IsLoggedIn API) is designed to inform the browser of whether a site is currently authorizing a user to access registration-..."</p>
<hr />
<div>== Overview ==<br />
Apple's Login Status API (previously IsLoggedIn API) is designed to inform the browser of whether a site is currently authorizing a user to access registration-only services, otherwise known as the login "state".<ref>https://github.com/privacycg/is-logged-in</ref> <br />
<br />
Under the current proposal, the browser can become an active party between users and sites, disintermediating the relationship sites otherwise have with their users. "Why Do Browsers Need To Know? The current behavior of the web is “logged in by default,” meaning as soon as the browser loads a webpage, that page can store data such as cookies virtually forever on the device."<ref>https://github.com/privacycg/is-logged-in</ref> <br />
<br />
Apple's proposal would "Require websites to take the user through a login flow according to rules that the browser can check. This would be the escape hatch for websites who can’t or don’t want to use WebAuthn or a password manager but still want to set the IsLoggedIn bit."<br />
<br />
== Impact ==<br />
By making the browser an active party to controlling the login state, the browser will have new power to log users out based on browser-only determined rules. This may cause confusion and frustration on the part of the users, who prefer to remain logged in on sites they take the effort to log into until they choose to log out.<br />
<br />
Moreover, one could foresee the browser trying to monopolize access to user authentication by handing back only state to a site, along the lines of Apple's "Hide My Email" offering. This would disintermediate sites not only from logged out visitors, but registered users and active subscribers.<br />
<br />
Note: Neither Google nor Apple have made any commitment that either will rely only on Login Status API to manage its own relationships with consumers. <br />
<br />
== Regulator Perspectives ==<br />
The UK CMA expressed concerns about Google's Conversion Measurement API that would also apply to this API:<br />
<br />
# Disproportionately impairing only rivals' access to data<br />
# Such impairment would exacerbate Google information advantage over rivals, further entrenching its dominance <br />
# Google's proposed API was neither an adequate replacement to meet marketer and publisher needs nor address conflict of interest concerns, thus further distorting competition by removing choices from the marketplace.<br />
<br />
The CMA noted "extensive reach of Google’s user-facing services and its ability to connect data with greater precision (because of its large base of users logged into their Google account) provide Google with a significant data advantage over others."<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref> <br />
<br />
== Open Questions ==<br />
* Would consumers have the ability to opt-out of browser interference with their relationship with sites? <br />
* What rules would browsers impose between sites and their users? <br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Login Status API]]<br />
[[Category:Privacy Sandbox|Login Status API]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Ibis&diff=478Ibis2021-10-17T17:41:01Z<p>Jkoran: </p>
<hr />
<div>The goal of Google's Interest-group Bid Integrity Support (Ibis) is to prevent malicious actor from manipulating the inputs into the local ad auction that occurs in [[Fledge]]/[[Turtledove]]. Ibis allows a marketer to encode a cap the price for an interest-based ad to limit the financial risk associated with such malicious manipulation. <br />
<br />
Ibis adopts Google’s Privacy Sandbox goal of disintermediating publishers from the marketers that fund their digital properties.<br />
<br />
== Overview ==<br />
Ibis identifies that when either publishers or marketers are disintermediated from the auction they cannot audit the malicious manipulation of the pricing that can occur. "Execution locally introduces the likelihood of manipulating the results of this process, or even simulating a fake TURTLEDOVE-style auction altogether."<ref>https://github.com/google/ads-privacy/tree/master/proposals/ibis</ref> <br />
<br />
Ibis acknowledges that browsers cannot be trusted either by publishers or marketers. "This [malicious manipulation] can occur in real browsers or in simulated browsers."<ref>https://github.com/google/ads-privacy/tree/master/proposals/ibis</ref> Among the manipulations specifically identified by Ibis are:<br />
<br />
# Setting second price auctions to "an arbitrarily high value to financially benefit a publisher, resulting in advertisers and DSPs paying high costs for low-value impressions"<br />
# Manufacturing "impressions that were not shown to real users"<br />
# Biased "auction logic and inputs themselves could potentially be manipulated to change the auction outcome" in violation of the duty to the publisher or marketer that the auction would be fair<br />
# Self-preferencing actions to "prevent a competitor’s ad from being shown or to increase the probability of a preferred ad to be shown instead."<ref>https://github.com/google/ads-privacy/tree/master/proposals/ibis</ref><br />
<br />
Ibis provides a publisher trusted server to compare the winning auction value to the marketers' previously expressed maximum price. "During the impression notification, the encoded maximum bid price as well as the actual winning bid price can be sent back to the SSP or the aggregate reporting service. The winning bid price can then be validated for use in billing and reporting using the DSP-specified range."<ref>https://github.com/google/ads-privacy/tree/master/proposals/ibis</ref><br />
<br />
By comparing the actual winning bid price to the encoded max price of an interest-based ad, the system can detect if bid exceeds the marketer's max price. <br />
<br />
== Impact ==<br />
Ibis acknowledges that even setting max prices does not safeguard publishers or marketers from a browser's malicious activity. "Will bid price constraints fully ensure on-device bid integrity? Unfortunately not. The proposed maximum bid price constraint approach will not be able to completely prevent bid manipulation."<ref>https://github.com/google/ads-privacy/tree/master/proposals/ibis</ref> The focus of Ibis is merely to limit the risk to marketers by having a cap on their bid price. However, marketers already bid their max price in both first and second price auctions. Thus it is unclear how Ibis actually mitigates any risk to buyers at all.<br />
<br />
The key risk to marketers that Ibis highlights is that marketers may be interested in engaging the "right" audience based on interest-based signals but end up delivering their ad in a "low-value" context, which is the wrong place or time to be engaging that audience. By reducing the price marketers would pay to account for this risk, will unfortunately further negatively impact publisher revenues.<br />
<br />
As with other Privacy Sandbox proposals that migrate B2B processing to the client, the incremental storage and processing cost for these auctions must be borne by consumers. This may degrade user experience or drain their mobile batteries.<br />
<br />
== Open Questions ==<br />
* What is the impact on web experiences given many client devices do not have the same processing power of the servers that currently select which content to render?<br />
* How does this solution actually reduce buyer risk? <br />
<br />
== See Also ==<br />
* [[Fledge]]<br />
* [[Puffin]]<br />
* [[Turtledove]]<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Ibis]] <br />
[[Category:Privacy Sandbox|Ibis]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=477Category:Privacy Sandbox2021-10-17T17:32:04Z<p>Jkoran: /* Experience Management Projects */</p>
<hr />
<div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Many of these APIs rely on server-side components. <br />
<br />
Google's head of ad products has stated that Google's Chrome plan to stop supporting third-party cookies "won’t proceed if there aren’t solutions that work for everyone while also protecting user privacy in place." <ref>https://www.adexchanger.com/adexchanger-talks/google-ads-gm-jerry-dischler-on-a-cookieless-future-that-happens-when-it-happens</ref><br />
<br />
This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br />
<br />
== Media Planning Projects == <br />
Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, planning functions that analyze the reach, frequency and cost of engaging audiences across publishers will not be directly addressed by this project. <br />
<br />
== Experience Management Projects ==<br />
Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The "right" context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br />
<br />
Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br />
<br />
A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage people using imprecise cohorts defined by Google. <br />
<br />
Privacy Sandbox would also remove information that currently is used to optimize people's web experiences, such as the appropriate size files and video resolution for the device they are interacting with the web content or being able to offer nearby recommendations.<br />
<br />
* '''Audience Management''' <br />
** '''Preference Management''' <br />
*** [[CHIPS]]<br />
*** [[Falcon]]<br />
*** [[Swan]] (Swan.community)<br />
** '''Audience Creation''' <br />
*** [[Ad Topic Hints]]<br />
*** [[First Party Sets]]<br />
*** [[FLoC]]<br />
*** [[Parakeet]] <br />
*** [[Pauraque]] (Nextroll)<br />
*** [[Petrel]] (Facebook)<br />
*** [[Sandpiper]] (CarbonRMP)<br />
*** [[Spectacle]] (Eyeo - AdBlockPlus)<br />
*** [[Swan (1plusX)]] <br />
*** [[Sushi]] (Adobe) <br />
*** [[Turtledove]]<br />
*** '''Look-alike Modeling''' <br />
**** [[Scaup]]<br />
*** '''Fraud Detection''' <br />
**** [[Gnatcatcher]]<br />
**** [[Privacy Budget]]<br />
**** [[Trust Tokens]]<br />
**** [[User-Agent Client Hints]]<br />
*** '''Authentication''' <br />
**** [[WebID]]<br />
* '''Auction Management''' <br />
** [[Augury]]<br />
** [[Dovekey]]<br />
** [[Fenced Frames]]<br />
** [[Ibis]]<br />
** [[Macaw]] (Microsoft)<br />
** [[Parrrot]] (Magnite)<br />
** [[Puffin]] (Cafemedia)<br />
** [[Sparrow]] (Criteo)<br />
** [[Tern]] (Adroll)<br />
** [[Turtledove]]<br />
<br />
== Reporting Projects ==<br />
Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br />
<br />
A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br />
<br />
* '''Reporting Management''' <br />
** [[Aggregate Reporting API]]<br />
** [[Conversion Measurement API]]<br />
** [[Private Click Attribution]] (Apple)<br />
** [[Murre]] (Adroll)<br />
** [[Pelican]] (Neustar)<br />
** [[Spurfowl]] (Nextroll)<br />
<br />
== Measuring Effectiveness and Ecosystem Impact ==<br />
Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br />
<br />
Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br />
<br />
* Google's Effects of Disabling Third-party Cookies on Publisher Revenue<ref>https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf</ref><br />
* [[Fledge]]<br />
* [[Teetar]] (Criteo)<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (1.5-1.6) the following concerns with Google's Privacy Sandbox proposals that would distort competition and impose unfair terms on people who use its Chrome browser, or more specifically:<br />
<br />
# "The Privacy Sandbox Proposals have caused uncertainty in the market as to the specific alternative solutions which will be available to publishers and ad tech providers once TPCs are deprecated.... causing harm to Google’s rival publishers and ad tech providers,"<br />
# "[Google's Privacy Sandbox Proposals would] advantage its own businesses and limit competition from its rivals."<br />
# Google has an advantage due to "the asymmetry of information between Google and third parties regarding the development of the Privacy Sandbox Proposals," (e.g., roll out schedule, code-level understanding of how they work)<br />
# Google may use self-preferencing criteria "to assess different design options" (e.g., policies to quantify how much distortion in competition is acceptable if it improves Google's revenues), and <br />
# Google lack of transparency with Privacy Sandbox regarding any "evidence relating to their effectiveness against these criteria."<br />
# In addition, "given the commercial incentives that Google faces in developing Google’s Proposals"<br />
# There is at present a "lack of independent scrutiny of Google’s Proposals" (e.g., if there is disagreement about tradeoff Google would make in weighting one criteria over another)<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Glossary|Privacy Sandbox]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Ibis&diff=476Ibis2021-10-17T17:26:42Z<p>Jkoran: Created page with "The goal of Google's Interest-group Bid Integrity Support (Ibis) is to prevent malicious actor from manipulating the inputs into the local ad auction that occurs in Fledge..."</p>
<hr />
<div>The goal of Google's Interest-group Bid Integrity Support (Ibis) is to prevent malicious actor from manipulating the inputs into the local ad auction that occurs in [[Fledge]]/[[Turtledove]]. Ibis allows a marketer to cap the price for an interest-based ad to limit the financial risk associated with such malicious manipulation. <br />
<br />
Ibis adopts Google’s Privacy Sandbox goal of disintermediating publishers from the marketers that fund their digital properties.<br />
<br />
== Overview ==<br />
Ibis identifies that when either publishers or marketers are disintermediated from the auction they cannot audit the malicious manipulation of the pricing that can occur. "Execution locally introduces the likelihood of manipulating the results of this process, or even simulating a fake TURTLEDOVE-style auction altogether."<ref>https://github.com/google/ads-privacy/tree/master/proposals/ibis</ref> <br />
<br />
Ibis acknowledges that browsers cannot be trusted either by publishers or marketers. "This [malicious manipulation] can occur in real browsers or in simulated browsers."<ref>https://github.com/google/ads-privacy/tree/master/proposals/ibis</ref> Among the manipulations specifically identified by Ibis are:<br />
<br />
# Setting second price auctions to "an arbitrarily high value to financially benefit a publisher, resulting in advertisers and DSPs paying high costs for low-value impressions"<br />
# Manufacturing "impressions that were not shown to real users"<br />
# Biased "auction logic and inputs themselves could potentially be manipulated to change the auction outcome" in violation of the duty to the publisher or marketer that the auction would be fair<br />
# Self-preferencing actions to "prevent a competitor’s ad from being shown or to increase the probability of a preferred ad to be shown instead."<ref>https://github.com/google/ads-privacy/tree/master/proposals/ibis</ref><br />
<br />
Ibis provides a publisher trusted server to compare the winning auction value to the marketers' previously expressed maximum price. "During the impression notification, the encoded maximum bid price as well as the actual winning bid price can be sent back to the SSP or the aggregate reporting service. The winning bid price can then be validated for use in billing and reporting using the DSP-specified range."<ref>https://github.com/google/ads-privacy/tree/master/proposals/ibis</ref><br />
<br />
== Impact ==<br />
Ibis acknowledges that even setting max prices does not safeguard publishers or marketers from a browser's malicious activity. "Will bid price constraints fully ensure on-device bid integrity? Unfortunately not. The proposed maximum bid price constraint approach will not be able to completely prevent bid manipulation."<ref>https://github.com/google/ads-privacy/tree/master/proposals/ibis</ref> The focus of Ibis is merely to limit the risk to marketers by having a cap on their bid price. However, marketers already bid their max price in both first and second price auctions. Thus it is unclear how Ibis actually mitigates any risk to buyers at all.<br />
<br />
The key risk to marketers that Ibis highlights is that marketers may be interested in engaging the "right" audience based on interest-based signals but end up delivering their ad in a "low-value" context, which is the wrong place or time to be engaging that audience. By reducing the price marketers would pay to account for this risk, will unfortunately further negatively impact publisher revenues.<br />
<br />
As with other Privacy Sandbox proposals that migrate B2B processing to the client, the incremental storage and processing cost for maintaining per publisher, per ad unit, per placement per ad category auctions must be borne by consumers. This may degrade user experience or drain their mobile batteries.<br />
<br />
== Open Questions ==<br />
* What is the impact on web experiences given many client devices do not have the same processing power of the servers that currently select which content to render?<br />
* How does this solution actually reduce buyer risk? <br />
<br />
== See Also ==<br />
* [[Fledge]]<br />
* [[Puffin]]<br />
* [[Turtledove]]<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Ibis]] <br />
[[Category:Privacy Sandbox|Ibis]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=475Category:Privacy Sandbox2021-10-17T17:02:22Z<p>Jkoran: </p>
<hr />
<div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Many of these APIs rely on server-side components. <br />
<br />
Google's head of ad products has stated that Google's Chrome plan to stop supporting third-party cookies "won’t proceed if there aren’t solutions that work for everyone while also protecting user privacy in place." <ref>https://www.adexchanger.com/adexchanger-talks/google-ads-gm-jerry-dischler-on-a-cookieless-future-that-happens-when-it-happens</ref><br />
<br />
This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br />
<br />
== Media Planning Projects == <br />
Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, planning functions that analyze the reach, frequency and cost of engaging audiences across publishers will not be directly addressed by this project. <br />
<br />
== Experience Management Projects ==<br />
Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The "right" context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br />
<br />
Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br />
<br />
A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage people using imprecise cohorts defined by Google. <br />
<br />
Privacy Sandbox would also remove information that currently is used to optimize people's web experiences, such as the appropriate size files and video resolution for the device they are interacting with the web content or being able to offer nearby recommendations.<br />
<br />
* '''Audience Management''' <br />
** '''Preference Management''' <br />
*** [[CHIPS]]<br />
*** [[Falcon]]<br />
*** [[Swan]] (Swan.community)<br />
** '''Audience Creation''' <br />
*** [[Ad Topic Hints]]<br />
*** [[First Party Sets]]<br />
*** [[FLoC]]<br />
*** [[Parakeet]] <br />
*** [[Pauraque]] (Nextroll)<br />
*** [[Petrel]] (Facebook)<br />
*** [[Robin]] <br />
*** [[Sandpiper]] (CarbonRMP)<br />
*** [[Spectacle]] (Eyeo - AdBlockPlus)<br />
*** [[Swan (1plusX)]] <br />
*** [[Sushi]] (Adobe) <br />
*** [[Turtledove]]<br />
*** '''Look-alike Modeling''' <br />
**** [[Scaup]]<br />
*** '''Fraud Detection''' <br />
**** [[Gnatcatcher]]<br />
**** [[Privacy Budget]]<br />
**** [[Trust Tokens]]<br />
**** [[User-Agent Client Hints]]<br />
*** '''Authentication''' <br />
**** [[WebID]]<br />
* '''Auction Management''' <br />
** [[Augury]]<br />
** [[Dovekey]]<br />
** [[Fenced Frames]]<br />
** [[Ibis]]<br />
** [[Macaw]] (Microsoft)<br />
** [[Parrrot]] (Magnite)<br />
** [[Puffin]] (Cafemedia)<br />
** [[Sparrow]] (Criteo)<br />
** [[Tern]] (Adroll)<br />
** [[Turtledove]]<br />
<br />
== Reporting Projects ==<br />
Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br />
<br />
A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br />
<br />
* '''Reporting Management''' <br />
** [[Aggregate Reporting API]]<br />
** [[Conversion Measurement API]]<br />
** [[Private Click Attribution]] (Apple)<br />
** [[Murre]] (Adroll)<br />
** [[Pelican]] (Neustar)<br />
** [[Spurfowl]] (Nextroll)<br />
<br />
== Measuring Effectiveness and Ecosystem Impact ==<br />
Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br />
<br />
Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br />
<br />
* Google's Effects of Disabling Third-party Cookies on Publisher Revenue<ref>https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf</ref><br />
* [[Fledge]]<br />
* [[Teetar]] (Criteo)<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (1.5-1.6) the following concerns with Google's Privacy Sandbox proposals that would distort competition and impose unfair terms on people who use its Chrome browser, or more specifically:<br />
<br />
# "The Privacy Sandbox Proposals have caused uncertainty in the market as to the specific alternative solutions which will be available to publishers and ad tech providers once TPCs are deprecated.... causing harm to Google’s rival publishers and ad tech providers,"<br />
# "[Google's Privacy Sandbox Proposals would] advantage its own businesses and limit competition from its rivals."<br />
# Google has an advantage due to "the asymmetry of information between Google and third parties regarding the development of the Privacy Sandbox Proposals," (e.g., roll out schedule, code-level understanding of how they work)<br />
# Google may use self-preferencing criteria "to assess different design options" (e.g., policies to quantify how much distortion in competition is acceptable if it improves Google's revenues), and <br />
# Google lack of transparency with Privacy Sandbox regarding any "evidence relating to their effectiveness against these criteria."<br />
# In addition, "given the commercial incentives that Google faces in developing Google’s Proposals"<br />
# There is at present a "lack of independent scrutiny of Google’s Proposals" (e.g., if there is disagreement about tradeoff Google would make in weighting one criteria over another)<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Glossary|Privacy Sandbox]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Onboarding&diff=474Onboarding2021-10-17T16:59:37Z<p>Jkoran: Created page with "Onboard refers to the process of linking offline attributes to online online identifiers. Examples of this offline attribute data can include in-s..."</p>
<hr />
<div>Onboard refers to the process of linking offline [[attribute|attributes]] to online online [[identifier|identifiers]]. Examples of this offline attribute data can include in-store shopping events or call center activity. The linking process involves matching the directly-identifiable identifier (e.g., name, email, phone number, residential address) to a digital identifier (e.g., MAID or cookie-based identifier).<br />
<br />
Typically marketers often rely on [[Data Management Platform|DMPs]] or [[Customer Data Platform|CDPs]] to onboard their first-party information to pseudonymous digital identifiers, but they can also avail themselves of specialized onboarding service organizations that do not centralize and manage the marketers' customer data. <br />
<br />
Large platforms also often provide this onboarding service themselves (e.g., [https://support.google.com/displayvideo/answer/9539301?hl=en#zippy=%2Cformatting-guidelines-for-uploading-unhashed-data "Customer Match"] and [https://www.facebook.com/business/help/170456843145568?id=2469097953376494 "Custom Audiences"]).<br />
<br />
[[Category:Glossary|Onboarding]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Opt-out&diff=473Opt-out2021-10-17T16:37:46Z<p>Jkoran: </p>
<hr />
<div>Opt-out has a different meaning for email and for digital advertising. With email, opt-out refers to an individual's request to unsubscribe from a organization's contact list. With digital advertising, opt-out refers to the individual's request to no longer receive [[Interest Based Advertising|interest-based advertising]].<br />
<br />
[[Category:Glossary|Opt-out]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Puffin&diff=472Puffin2021-10-17T16:26:33Z<p>Jkoran: Created page with "Cafemedia’s Personal User Floor For Impression Negotiations (Puffin) aims to improve publisher inventory monetization by setting a per-browser, per-ad type price floor based..."</p>
<hr />
<div>Cafemedia’s Personal User Floor For Impression Negotiations (Puffin) aims to improve publisher inventory monetization by setting a per-browser, per-ad type price floor based on historical auction data for each placement by ad category for each publisher.<ref>https://github.com/dmarti/PUFFIN</ref> The proposal aims to increase value for content relative to interest-based advertising, by increasing the price floor solely for interest-based ads. This delta in pricing suggests more context-only ads would win auctions relative to today. The notion is that increasing revenues for high-quality content producing sites encourages greater production of such content "in the interests of the user and of the ad-supported sites whose content they prefer."<ref>https://github.com/dmarti/PUFFIN</ref><br />
<br />
Puffin adopts Google’s Privacy Sandbox goal of disintermediating publishers from the marketers that fund their digital properties.<br />
<br />
== Overview ==<br />
Puffin builds on the trusted-server model of required by [[Turtledove]]/[[Fledge]]. Unlike Fledge, Puffin allows real-time, per publisher per ad unit per browser price floors based purely on prior auctions that relied solely on current context.<br />
<br />
"The interest-based ad wins (and is displayed to the user) if it can outbid the contextual ad. A PUFFIN is a persistent per-browser floor price that the interest-group ad bid must also exceed in order to win the auction. Each PUFFIN is calculated based on an exponentially weighted rolling average of winning contextual ad bids. Losing bids and interest-group bids never affect PUFFIN."<ref>https://github.com/dmarti/PUFFIN</ref><br />
<br />
The price floors are stored in the browser for each ad unit type and placement per publisher. "The browser maintains one PUFFIN for each ad unit type that can be detected automatically. For example, a video ad and large leaderboard ad would each have a different PUFFIN from a small, below-the-fold ad."<ref>https://github.com/dmarti/PUFFIN</ref><br />
<br />
The price floors are also calculated per ad category, such that auto ads may have a different floor than travel ads. "With PUFFIN, in order for the interest-based ad to win the in-browser auction, it must beat not only the highest-bidding contextual ad, but also the PUFFIN for ads of the same category that have previously appeared in the same browser."<ref>https://github.com/dmarti/PUFFIN</ref><br />
<br />
For example, if a given ad slot usually monetizes via context at $1.00, then an interest-base ad must always exceed $1.00 even if all context bids for a given auction were only $0.50. In the case that an interest-based ad were $0.90, Puffin would have the browser choose the lower monetizing contextual-only ad. Note: as this example illustrates this will reduce yield if publisher inventory is forced to monetize for the lower priced ad.<br />
<br />
Unlike other interest-based advertising proposals (e.g., [[Pauraque]]), Puffin does not expose any of information to auction participants. "PUFFIN is confidential and per-browser, and is not available to any script."<ref>https://github.com/dmarti/PUFFIN</ref><br />
<br />
== Impact ==<br />
Because of the different price floor for interest-only ads than contextual-only ads, there will be a higher spread in auction prices than today. <br />
<br />
Merely changing the price point for interest ads to win auctions does not reduce the value marketers receive from focusing limited spend on audience-based dimensions (i.e. [[Interest_Based_Advertising|interest-based advertising]]). Puffin assumes that the audience information used by marketers to improve their outcomes is generated solely from high-engagement, high-reputation sites. Interest-based advertising leads to "Leakage of ad revenue from high-engagement, high-reputation sites to lower-engagement sites where the same audience appears to be available."<ref>https://github.com/dmarti/PUFFIN</ref> However, retargeting is one example where the interest-based information comes exclusively from marketers' own data. [[Onboarding]] is another case that illustrates this.<br />
<br />
Thus, it is unlikely that prices for context-only ads would increase due to the lack of any increase in value generated from this proposal. <br />
<br />
One unwritten assumption of Puffin may be that by reducing the availability of interest-based advertising inventory, marketers would shift their budgets to context-only advertising, thus increasing demand and through this iterative game-theory mechanism increase prices for context-only advertising. Such an assumption relies on another unwritten assumption that marketers would no longer have access to Walled Garden advertising solutions that continue to offer interest-based advertising with contextual targeting and real-time optimization, to message the right audience in the right context at the right time at the right price. These assumptions would rely on Privacy Sandbox eliminating its current first-party and corporate-ownership exemptions (e.g., [[First_Party_Sets|First Party Sets]]) to data collection and processing. <br />
<br />
As with other Privacy Sandbox proposals that migrate B2B processing to the client, the incremental storage and processing cost for maintaining per publisher, per ad unit, per placement per ad category auctions must be borne by consumers. This may degrade user experience or drain their mobile batteries.<br />
<br />
== Open Questions ==<br />
* What is the impact on web experiences given many client devices do not have the same processing power of the servers that currently select which content to render?<br />
* How does the local client auction support publisher custom logic, such as factors other than price to select which ad to render?<br />
<br />
== See Also ==<br />
* [[First_Party_Sets|First Party Sets]]<br />
* [[Fledge]]<br />
* [[Interest_Based_Advertising|Interest Based Advertising]]<br />
* [[Turtledove]]<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Puffin]] <br />
[[Category:Privacy Sandbox|Puffin]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Sushi&diff=471Sushi2021-10-17T16:18:20Z<p>Jkoran: /* Overview */</p>
<hr />
<div>Adobe’s Suggested and User-Specified Hierarchical Interests (Sushi) is centered around organizations assigning a set of hierarchical topics of interest that can later be used in selecting relevant ads.<ref>https://github.com/privacycg/proposals/issues/27</ref> The restriction on using a fixed hierarchy of topics is meant to provide enhanced transparency to users as to the audience interest used to match content. Sushi relies on pre-defined rules to rank which attributes would be made available for decisioning logic.<br />
<br />
Adobe’s proposal adopts the goal of Google's [[Category:Privacy_Sandbox|Privacy Sandbox]] in preventing marketers from engaging a particular audience in a particular context.<br />
<br />
== Overview ==<br />
The Sushi proposal separates the assignment of topics from the later inference logic to guess what a user might be interested in. For example, a user may visit multiple sites and be assigned to four separate interest topics from the taxonomy: <br />
sports→baseball→pros→Giants<br />
sports→football→pros→49ers<br />
sports→football→college→Stanford<br />
sports→football→college→Berkeley<br />
<br />
“In this case sports has been suggested four times, football three times and college football twice ("pros" isn't counted as occurring twice, because its two occurrences are in different subtrees of the hierarchy).”<ref>https://github.com/privacycg/proposals/issues/27</ref> The Sushi proposal suggests the web client should control the logic that relies on the recency and frequency of these topics to determine which nodes of the taxonomy are eligible for content matching.<br />
<br />
Sushi suggests the look-back window of prior activity ought to be “at least 30 days (unless cleared by the user)”.<ref>https://github.com/privacycg/proposals/issues/27</ref> Sushi suggests that for seasonal topics, such as sports leagues or holidays, the interest should persist until the next season, rather than having a cold start to relearn such an interest each season. <br />
<br />
To limit use of the user’s limited local storage for this B2B use case, Sushi suggests each organization will be limited to contribute a limited number of suggestions by a budgeting method. Thus, if one organization submits “five topics, while another only suggests one, the single topic might get five times as much weight as any of the five.” The Sushi proposal suggests that this weighting ought to also act as a hint into how strong the organization believes the user interest to be, such as “assigning a weight of 50% to the primary topic, 20% to a secondary topic and 10% to each of the remaining topics.”<ref>https://github.com/privacycg/proposals/issues/27</ref> Note: this proposal does not specify how an organization contributing only one suggested topic may limit the weighting if it is not as confident in the strength of the predicted interest (e.g., assuming a 20% vs 80% affinity).<br />
<br />
To handle the disclosure of sensitive proprietary information for each organization, Sushi states “suggested interests should remain exclusive to the advertiser until the same topic is suggested by a sufficient number of different advertisers and/or publishers.”<ref>https://github.com/privacycg/proposals/issues/27</ref><br />
<br />
Sushi suggests that in addition to generating audience interests a new icon should be displayed when this information is used to match content in the URL/bookmarks area of the web client. When clicked, this icon should show:<br />
# If Sushi was used in matching content on the page<br />
# The top-most topics inferred to be of interest to the user, regardless of current page<br />
# The current contextual topic of the page, regardless if used to match the content on the page<br />
# Any topics sent to the content decisioning system to match content on the page<br />
<br />
Moreover, Sushi suggests that the user should be able to see which URLs assigned which interest topics. Thus, if the user was assigned the topic “sports→football,” the user should see the history of all sites that were used as inputs into the behavioral classification process. If the user disagrees with the inference, then the user should be able to object, which would then block further assignment in the future.<br />
<br />
Sushi suggests that the user should be able to manually self-assign interest topics from the same taxonomy. Such self-assigned topics should be given higher weighting by the web client behavioral classification logic. The assignment of or objection to an interest at a parent node should be inherited by all children nodes in the taxonomy. SUSHI suggests that users could optionally specify a different expiration of interest topics on a per node basis.<br />
<br />
When signaling the interest topics to content matching systems, Sushi suggests that the random subset of all interest topics be sent, as well as which were self-assigned or assigned by current page. A trusted server would keep track of which combinations are so rare that this array might be used as a unique identifier by the content decisioning system. Sushi suggests that weightings of interest be used to help determine which interest topics are sent, such that higher interests are sent more frequently than lower interests.<br />
<br />
Sushi states that IAB taxonomy<ref> https://www.iab.com/guidelines/content-taxonomy/</ref> is not detailed enough to support the interest classification required for this proposal. As one approach, each organization might submit custom nodes that are more granular than the standard taxonomy.<br />
<br />
== Impact ==<br />
Similar to [[Fenced Frames]] and [[Turtledove]]/[[Fledge]], Sushi states that content matching systems should not be able to learn which ads were correlated to which conversion events. This will impair marketer effectiveness and negatively impact publisher revenues. <br />
<br />
Not all interest attributes are equally valuable to all marketers. By restricting the list of available attributes, or ranking them on criteria independent from publisher monetization, will further impair publisher revenues.<br />
<br />
Sushi's proposed weighting mechanism confuses marketers' estimated probability of accuracy with value. As mentioned above, if a marketer can guess only a single attribute (interest "topic") at 20% vs 80% accuracy this 4x weighting has no direct relationship to another marketer submitting four times as many topics.<br />
<br />
The Sushi proposal requires storage of all domains linked to the generation of each attribute, which will use greater client storage than needed at present. This forces people to absorb the cost of B2B storage and processing, that may require them to update older devices to continue to access ad-funded sites. <br />
<br />
== Open Questions ==<br />
# How will any interests scale if each organization wants its topic information to remain proprietary? <br />
# As there are millions of organizations, if each is assigning custom nodes what is the impact on local storage or classification process of interests?<br />
# How do different organizations that would prefer different rule sets to assign interest classification provide feedback to centralized behavioral interest classification system (e.g., minimum of 4 events not 3 to be eligible or 7 rather than 30 days look-back window for recency)?<br />
# How will machine learning inside the web client improve its classification of interest inferences across different browsers signed into a single domain by the same individual to ensure they are improving publisher monetization and marketer ROAS? <br />
# How will machine learning of organizations assigning interest topics learn how to improve the hints they assign to each topic (e.g., first topic should receive 50% not 20%)? <br />
# How will organizations learn which interests a user has blocked, so they stop wasting their limited budget on trying to assign those interests to those users?<br />
# Should self-assigned interests expire at the same rate as system-assigned topics by default?<br />
<br />
== See Also ==<br />
* [[Ad Topic Hints]]<br />
* [[Fledge]]<br />
* [[Parakeet]]<br />
* [[Pauraque]]<br />
* [[Turtledove]]<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Sushi]]<br />
[[Category:Privacy Sandbox|Sushi]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=470Category:Privacy Sandbox2021-10-17T13:57:06Z<p>Jkoran: /* Experience Management Projects */</p>
<hr />
<div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Many of these APIs rely on server-side components. <br />
<br />
Google's head of ad products has stated that Google's Chrome plan to stop supporting third-party cookies "won’t proceed if there aren’t solutions that work for everyone while also protecting user privacy in place." <ref>https://www.adexchanger.com/adexchanger-talks/google-ads-gm-jerry-dischler-on-a-cookieless-future-that-happens-when-it-happens</ref><br />
<br />
This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br />
<br />
== Media Planning Projects == <br />
Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, planning functions that analyze the reach, frequency and cost of engaging audiences across publishers will not be directly addressed by this project. <br />
<br />
== Experience Management Projects ==<br />
Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The "right" context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br />
<br />
Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br />
<br />
A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage people using imprecise cohorts defined by Google. <br />
<br />
Privacy Sandbox would also remove information that currently is used to optimize people's web experiences, such as the appropriate size files and video resolution for the device they are interacting with the web content or being able to offer nearby recommendations.<br />
<br />
* '''Audience Management''' <br />
** '''Preference Management''' <br />
*** [[CHIPS]]<br />
*** [[Falcon]]<br />
*** [[Swan]] (Swan.community)<br />
** '''Audience Creation''' <br />
*** [[First Party Sets]]<br />
*** [[FLoC]]<br />
*** [[Parakeet]] <br />
*** [[Pauraque]] (Nextroll)<br />
*** [[Petrel]] (Facebook)<br />
*** [[Robin]] <br />
*** [[Sandpiper]] (CarbonRMP)<br />
*** [[Spectacle]] (Eyeo - AdBlockPlus)<br />
*** [[Swan (1plusX)]] <br />
*** [[Sushi]] (Adobe) <br />
*** [[Turtledove]]<br />
*** '''Look-alike Modeling''' <br />
**** [[Scaup]]<br />
*** '''Fraud Detection''' <br />
**** [[Gnatcatcher]]<br />
**** [[Privacy Budget]]<br />
**** [[Trust Tokens]]<br />
**** [[User-Agent Client Hints]]<br />
*** '''Authentication''' <br />
**** [[WebID]]<br />
* '''Auction Management''' <br />
** [[Augury]]<br />
** [[Dovekey]]<br />
** [[Fenced Frames]]<br />
** [[Ibis]]<br />
** [[Macaw]] (Microsoft)<br />
** [[Parrrot]] (Magnite)<br />
** [[Puffin]] (Cafemedia)<br />
** [[Sparrow]] (Criteo)<br />
** [[Tern]] (Adroll)<br />
** [[Turtledove]]<br />
<br />
== Reporting Projects ==<br />
Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br />
<br />
A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br />
<br />
* '''Reporting Management''' <br />
** [[Aggregate Reporting API]]<br />
** [[Conversion Measurement API]]<br />
** [[Private Click Attribution]] (Apple)<br />
** [[Murre]] (Adroll)<br />
** [[Pelican]] (Neustar)<br />
** [[Spurfowl]] (Nextroll)<br />
<br />
== Measuring Effectiveness and Ecosystem Impact ==<br />
Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br />
<br />
Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br />
<br />
* Google's Effects of Disabling Third-party Cookies on Publisher Revenue<ref>https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf</ref><br />
* [[Fledge]]<br />
* [[Teetar]] (Criteo)<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (1.5-1.6) the following concerns with Google's Privacy Sandbox proposals that would distort competition and impose unfair terms on people who use its Chrome browser, or more specifically:<br />
<br />
# "The Privacy Sandbox Proposals have caused uncertainty in the market as to the specific alternative solutions which will be available to publishers and ad tech providers once TPCs are deprecated.... causing harm to Google’s rival publishers and ad tech providers,"<br />
# "[Google's Privacy Sandbox Proposals would] advantage its own businesses and limit competition from its rivals."<br />
# Google has an advantage due to "the asymmetry of information between Google and third parties regarding the development of the Privacy Sandbox Proposals," (e.g., roll out schedule, code-level understanding of how they work)<br />
# Google may use self-preferencing criteria "to assess different design options" (e.g., policies to quantify how much distortion in competition is acceptable if it improves Google's revenues), and <br />
# Google lack of transparency with Privacy Sandbox regarding any "evidence relating to their effectiveness against these criteria."<br />
# In addition, "given the commercial incentives that Google faces in developing Google’s Proposals"<br />
# There is at present a "lack of independent scrutiny of Google’s Proposals" (e.g., if there is disagreement about tradeoff Google would make in weighting one criteria over another)<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Glossary|Privacy Sandbox]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Ad_Topic_Hints&diff=469Ad Topic Hints2021-10-17T13:54:58Z<p>Jkoran: Created page with "Facebook’s Ad Topic Hints enables marketers to engage people with interest attributes that people self-declare, which the authors call “person-driven advertising.”<ref>h..."</p>
<hr />
<div>Facebook’s Ad Topic Hints enables marketers to engage people with interest attributes that people self-declare, which the authors call “person-driven advertising.”<ref>https://github.com/privacycg/ad-topic-hints</ref> <br />
<br />
== Overview ==<br />
Ad Topic Hints proposal relies on a local client user profile containing attributes that can be used to improve the matching of content. The attributes are updated based on user interaction. The proposal suggests the interaction should be simple binary input (e.g., relevant / not relevant) rather than selection from a menu with too many choices.<ref>https://github.com/privacycg/ad-topic-hints</ref> The proposal suggests that the given the declared signal marketers would be more inclined to match more content associated with the user-provided hint.<br />
<br />
The attributes are encoded into a “binary embedding vector” of a particular number of bytes. The proposal suggests the total bytes may be between 64 to 1024 bytes. The embedding is meant to classify rated ads into “topics,” belonging to an unspecified taxonomy. The authors acknowledge the common classification challenges and suggest that data sets to train the model should include “speakers of many languages and cultures, on ads for a wide variety of topics.“<ref>https://github.com/privacycg/ad-topic-hints</ref> Both the taxonomy and the embedding (classification) would need to be updated periodically.<br />
<br />
The proposal suggests people could see all ads previously rated and modify their ratings. The proposals states that one reason to maintain the original ad and its prior classification is to enable reclassification into the new taxonomy or via the new embedding approach. <br />
<br />
This proposal explicitly excludes from scope how sites match content to these attributes.<ref>https://github.com/privacycg/ad-topic-hints</ref> Yet Ad Topic Hints later suggests that people could indicate a preference to “explore [ads] outside their current choices.”<ref>https://github.com/privacycg/ad-topic-hints</ref> However, this “choice” violates the proposal scope not to define logic of the content matching systems. The proposal does raise the question whether preferences should be “always respected” or whether there should be a time decay or merely used as a weighting factor by content matching systems. <br />
<br />
Ad Topic Hints notes the potential for bad actors to game the system with “click jacking,” or automating the feedback rather than ensuring it is user provided. To mitigate this risk, the authors propose visual feedback when interaction is provided, “You indicated the topic of this ad was relevant to you,” and then requires a second confirmation of this input: “Yes, correct” or “No, Cancel.”<ref>https://github.com/privacycg/ad-topic-hints</ref><br />
<br />
To diminish the likelihood of the array of Ad Topic Hints itself being used as a unique identifier, the proposal suggests combining user-generated hints with pre-populated hints as well as providing only a subset of the interest profile array during any given browsing session. <br />
<br />
Ad Topic Hints suggests the scope of the storage should be at device level, rather user-agent, domain-level or identifiable user-level. This proposal does suggest people should also be able to download their array of topic preferences to port them from one platform to another. The mechanism to for interest portability remains undefined, especially if the storage systems do not allow for the authenticated match of the individual linked to this digital activity. Persistently storing digital activity linked to directly-identifiable identity would likely raise additional privacy concerns.<br />
<br />
== Impact ==<br />
As with other user-controlled attribute proposals, Ad Topic Hints confuses the concern people have regarding receiving output content with the attribute data input that may or may not have been used to match the content. If someone would prefer not seeing running shoes, removing “sports” or “shoes” from their profile does not prevent matching on current context, geography or even registration data. To more directly address such user concerns, these proposals could be improved by storing sets of “paused” ads or brands, rather than unspecific list of topics as potential inputs that might lead to the unwanted content.<br />
<br />
This proposal further confuses B2C content recommendations (optimized for user preference) vs B2B content optimization (optimized for marketer goals).<br />
<br />
The authors may be optimistic about the utility people may derive advertising content matched to user-generated attributes, when they focus on portability of the user-generated topic hints. Given the browser is introducing noise and limiting the topic hints to subset of the interest profile array per session this will further diminish the likelihood that people will perceive the change in advertising content they receive, especially as all content matching logic is intentionally excluded from the scope. <br />
<br />
Not all interest attributes are equally valuable to all marketers. By restricting the list of available attributes, or ranking them on criteria independent from publisher monetization, will further impair publisher revenues.<br />
<br />
The proposal moves per-ad or organization attribute storage to the client, which will use greater client storage than needed at present. This forces people to absorb the cost of B2B storage and processing, that may require them to update older devices to continue to access ad-funded sites. <br />
<br />
== Open Questions ==<br />
* What taxonomy will be used and is it granular enough for marketers to derive sufficient value per the goal of proposal? <br />
* Is the topic taxonomy at a controller (e.g., marketer) level or product category (e.g., “consumer electronics”) level?<br />
* If at the product category level, how does it enable people to express preference (e.g., “I prefer Sony” and “I dislike Skyworth“)?<br />
* As there are millions of organizations, if each ad is stored locally what is the impact on local storage or classification process of interests?<br />
<br />
== See Also ==<br />
* [[Fledge]]<br />
* [[Parakeet]]<br />
* [[Pauraque]]<br />
* [[Petrel]]<br />
* [[Sushi]]<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Ad Topic Hints]]<br />
[[Category:Privacy Sandbox|Ad Topic Hints]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Pauraque&diff=468Pauraque2021-10-17T13:49:11Z<p>Jkoran: Created page with "NextRoll’s Profile-based API for User Attribute Queries (Pauraque) enables marketers to engage people with interest attributes, with additional user-level controls over whic..."</p>
<hr />
<div>NextRoll’s Profile-based API for User Attribute Queries (Pauraque) enables marketers to engage people with interest attributes, with additional user-level controls over which attributes will be available to marketers.<ref>https://github.com/AdRoll/privacy/blob/main/PAURAQUE.md</ref> <br />
<br />
Pauraque adopts Google’s Privacy Sandbox goal of disintermediating publishers from the marketers that fund their digital properties.<br />
<br />
== Overview ==<br />
Pauraque proposal relies on a local client user profile containing attributes that can be used to improve the matching of content. These attributes are visible to the user, who can enable which organizations may have access to their profile and to particular attributes. Pauraque leaves open whether the attributes could be expanded to interests. “Should there be a standard set of interest, e.g. modeled after IAB categories, or should they remain freely settable and purely rely on the market to establish this on its own?”<ref>https://github.com/AdRoll/privacy/blob/main/PAURAQUE.md</ref> <br />
<br />
Pauraque focuses on B2B marketing use cases, where interest-based activity is often far less important than “firmographic data such as industry, company size, and location.”<ref> https://github.com/AdRoll/privacy/blob/main/PAURAQUE.md</ref> The two use cases the Pauraque proposal aims to address are:<br />
# Match content to people based on the job function or working at companies on a Target Accounts List (TAL). <br />
# Report on spend, clicks, impressions, page views, view-through conversions, and click-through conversions with company-level granularity.<br />
<br />
The proposal offers three mechanisms for people to add attributes to their local profile:<br />
<br />
# User explicitly declares an attribute to be added to their profile<br />
# A site the user is interacting with requests adding the attribute to the user profile<br />
# The web client can recommend an attribute to be added to the user profile<br />
<br />
Pauraque relies on a sufficient k-anonymity for any attribute to be available to be added to the profile. <br />
Users can choose to remove any added interest at any time. <br />
<br />
Pauraque raises the important concern regarding the trustworthiness of the attribute data. “A user could put false values for company or job title. Or, the user could change jobs without updating their profile.”<ref>https://github.com/AdRoll/privacy/blob/main/PAURAQUE.md</ref> While Pauraque suggest that some third-party service could verify the attribute linkage to the device, but does not describe how such could be done, especially without reidentifying the untrusted individual, for example if the attribute (a job title) were unique to a given organization. “A third-party service could be used to provide this verification and issue a certification or Trust Token which could be attached to the attribute.” <ref>https://github.com/AdRoll/privacy/blob/main/PAURAQUE.md</ref> <br />
<br />
The proposal assumes that the auction logic will be analogous to [[Turtledove]]/[[Fledge]], where the publisher will not receive any information about what products the organization wishes to suppress users from. <br />
<br />
== Impact ==<br />
Similar to [[Fenced Frames]] and [[Turtledove]]/[[Fledge]], Pauraque states that content matching systems should not be able to learn which ads were correlated to which conversion events. This will impair marketer effectiveness and negatively impact publisher revenues. <br />
<br />
Pauraque describes how people could manage the attributes in their local profile, but not which attributes would be made available to the various advertising solutions that marketers rely on to engage audiences. If a given user were in the market for a delivery service, let us assume they have added such an attribute to their profile and want to share it with interested parties that can help them with their need. How would the user know which organizations can help them with their need before seeing prior advertising to know which organizations to allow? This may inadvertently bias established players and artificially raise barriers to entry for new competitors and startups.<br />
<br />
Pauraque does not describe what taxonomy ought to be used for people to describe attributes or for marketers to make them aware or engage them with their solutions. For example, in our shipping example above, should the attribute be “shipping,” “mailing” or “delivery services”? What level of granularity helps best match marketers’ solutions to the individual’s needs?<br />
<br />
Pauraque suggests that a k-anonymity threshold will be applied per attribute, but does not describe how the array of attributes itself can be a unique identifier. For example, there may be only one organization in a given city at a given time that is interested in shipping and Kosher food delivery services. If the individual sourcing these services has declared such an interest to one vendor, then this unique combination could be re-identified if both attributes were made available via their web client on any given site. Of course, the mere possibility of re-identification should not be a deciding factor alone, especially if the recipients of the information have made obligations on their privacy policy about inappropriate re-identification of pseudonymous personal information.<br />
<br />
Pauraque does not address the decision process whereby content is often matched based on correlations to information that itself does not directly describe the service being advertised. For example, a shipping service may have found a correlation for business users that have the “Kosher food delivery service” attribute, such that the user would not know that by removing the “Kosher food delivery service” will impact receiving shipping ads from this shipping service. Even if such attributes were made known (e.g., the user sees a “shipping“ ad that was matched due to “Kosher food delivery service”), the user may wish to continue to receive “Kosher food delivery service” but not shipping ads. Thus, removing attributes is an imprecise method of signaling a desire to stop seeing shipping ads or shipping ads from a particular brand.<br />
<br />
The proposal moves per-organization attribute storage to the client, which will use greater client storage than needed at present. This forces people to absorb the cost of B2B storage and processing, that may require them to update older devices to continue to access ad-funded sites. <br />
<br />
As with other user-controlled attribute proposals, Pauraque confuses the concern people have regarding receiving output content with the attribute data input that may or may not have been used to match the content. If someone would prefer not seeing running shoes, removing “sports” or “shoes” from their profile does not prevent matching on current context, geography or even registration data. To more directly address such user concerns, these proposals could be improved by storing sets of “paused” ads or brands, rather than unlimited number of potential inputs that might lead to the unwanted content.<br />
<br />
== Open Questions ==<br />
* How will any interests scale if each organization wants its topic information to remain proprietary? <br />
* As there are millions of organizations, if each is assigning custom nodes what is the impact on local storage or classification process of interests?<br />
* How many organizations can be allowed from a given sandboxed element without impacting user experience?<br />
* Is the allow setting at a controller (e.g., marketer) level or at a vendor (e.g., verification vendor) level?<br />
<br />
== See Also ==<br />
* [[Ad Topic Hints]]<br />
* [[Fledge]]<br />
* [[Parakeet]]<br />
* [[Sushi]]<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Pauraque]]<br />
[[Category:Privacy Sandbox|Pauraque]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Petrel&diff=467Petrel2021-10-17T13:43:17Z<p>Jkoran: Created page with "Facebook’s Private Exclusion Targeting Rendered Exclusively Locally (Petrel) is aimed to allow marketers to stop sending ads to users based on specific prior activity, such..."</p>
<hr />
<div>Facebook’s Private Exclusion Targeting Rendered Exclusively Locally (Petrel) is aimed to allow marketers to stop sending ads to users based on specific prior activity, such as recently having purchased their product. In addition to the marketer benefit of no longer wasting budget, exclusion targeting also addresses consumer complaints about seeing ads for the products they just purchased.<ref>https://github.com/w3c/web-advertising/blob/main/PETREL.md</ref> <br />
<br />
Facebook’s proposal adopts the goal of Google's Privacy Sandbox to prevent marketers from engaging a particular audience in a particular context. <br />
<br />
== Overview ==<br />
Petrel suggests that just as other proposals add interest topics to web clients, so too should a proposal be in place to remove such assignments. <br />
<br />
The Petrel proposal suggests that the web client stored "exclusion group" that are analogous to the Turtledove "interest group".<ref>https://github.com/w3c/web-advertising/blob/main/PETREL.md</ref> Each exclusion group could contain a number of product_IDs that are proprietary to a given organization.<ref>https://github.com/w3c/web-advertising/blob/main/PETREL.md</ref><br />
<br />
Petrel suggests that an ad response ought to contain an ordered list of potential ads which each individually include a product_id, such that the web client can display the first ad that does not contain a product_id belonging to an exclusion group it has previously stored.<ref>https://github.com/w3c/web-advertising/blob/main/PETREL.md</ref> <br />
<br />
The exclusion rule for a given product_ID can be time bound, such as for the next 90 days.<ref>https://github.com/w3c/web-advertising/blob/main/PETREL.md</ref><br />
<br />
The proposal assumes that the auction logic will be analogous to Turtledove/Fledge, where the publisher will not receive any information about what products the organization wishes to suppress users from. <br />
<br />
== Impact ==<br />
The proposal is limited only to advertising use cases, and hence does not address content management needs of publishers that are wishing to personalize content that is ad-funded. An information site might see interest in a given set of research and reviews in the previous seven days. When the user returns, unbeknownst to the publisher the user has already purchased the product associated with prior activity. While Petrel would suppress the ads to fund the recommended articles related to that product, the site would now be showing less relevant content to the user that would negatively impact their experience. Larger sites that both sell and provide reviews would thus be at a competitive advantage under such a system to smaller sites that only provide information. <br />
<br />
As with other user-controlled attribute proposals, Petrel confuses the concern people have regarding receiving output content with the attribute data input that may or may not have been used to match the content. If someone would prefer not seeing running shoes, removing “sports” or “shoes” from their profile does not prevent matching on current context, geography or even registration data. To more directly address such user concerns, these proposals could be improved by storing sets of “paused” ads or brands, rather than unlimited number of potential inputs that might lead to the unwanted content.<br />
<br />
Not all interest attributes are equally valuable to all marketers. By restricting the list of available attributes, or ranking them on criteria independent from publisher monetization, will further impair publisher revenues.<br />
<br />
== Open Questions ==<br />
* How will any interests scale if each organization wants its topic information to remain proprietary? <br />
* As there are millions of organizations, if each is assigning custom nodes what is the impact on local storage or classification process of interests?<br />
* How many organizations can be allowed from a given sandboxed element without impacting user experience?<br />
* Is the allow setting at a controller (e.g., marketer) level or at a vendor (e.g., verification vendor) level?<br />
* Why match ads on interest attributes but exclude at product_ID, rather than more directly pause based on ad or brand? <br />
* How can smaller publishers compete on a level playing field with larger rivals under this model?<br />
<br />
== See Also ==<br />
* [[Ad Topic Hints]]<br />
* [[Fledge]]<br />
* [[Turtledove]]<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Petrel]]<br />
[[Category:Privacy Sandbox|Petrel]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Category:Privacy_Sandbox&diff=466Category:Privacy Sandbox2021-10-17T13:41:16Z<p>Jkoran: /* Experience Management Projects */</p>
<hr />
<div>Privacy Sandbox is a set of proprietary Chrome browser APIs that provide information to buyers and sellers of digital media.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Many of these APIs rely on server-side components. <br />
<br />
Google's head of ad products has stated that Google's Chrome plan to stop supporting third-party cookies "won’t proceed if there aren’t solutions that work for everyone while also protecting user privacy in place." <ref>https://www.adexchanger.com/adexchanger-talks/google-ads-gm-jerry-dischler-on-a-cookieless-future-that-happens-when-it-happens</ref><br />
<br />
This page lists Google Privacy Sandbox projects as well as proposed modifications to these projects to better meet the needs of publishers and marketers. When an organization other than Google is proposing a project in the list below there name appears in parentheses. <br />
<br />
== Media Planning Projects == <br />
Given a goal of the Privacy Sandbox is to prevent marketers from understanding which audiences are interacting across different publishers, planning functions that analyze the reach, frequency and cost of engaging audiences across publishers will not be directly addressed by this project. <br />
<br />
== Experience Management Projects ==<br />
Marketers engagement requirements are to show their content to their desired audience in the right context, while limiting the frequency capping across these different publishers. The "right" context is determined by the relative cost for a subsequent value generated from the exposure, such as brand awareness, click or conversion. Part of determining a desired audience is also filtering [[Non-human_Traffic|Non-human traffic]].<br />
<br />
Publisher engagement requirements are to show their content to their desired audience, while controlling for publisher business rules, such as controlling which types of advertising content can appear or appear together on the same page to a particular audience. Privacy Sandbox's time-delayed feedback may not meet publisher requirements for A/B testing nor quality assurance of their advertising.<br />
<br />
A goal of the Privacy Sandbox is to limit the precision of audience segments in context, as well as to limit the real-time feedback marketers receive to update their measurement and budget allocations. Thus the Privacy Sandbox engagement proposals either force marketers to choose to control audience OR context, but not combine the two, or alternately force marketers to engage people using imprecise cohorts defined by Google. <br />
<br />
Privacy Sandbox would also remove information that currently is used to optimize people's web experiences, such as the appropriate size files and video resolution for the device they are interacting with the web content or being able to offer nearby recommendations.<br />
<br />
* '''Audience Management''' <br />
** '''Preference Management''' <br />
*** [[CHIPS]]<br />
*** [[Falcon]]<br />
*** [[Swan]] (Swan.community)<br />
** '''Audience Creation''' <br />
*** [[First Party Sets]]<br />
*** [[FLoC]]<br />
*** [[Parakeet]] <br />
*** [[Pauraque]] (Nextroll)<br />
*** [[Petrel]] (Facebook)<br />
*** [[Robin]] <br />
*** [[Sandpiper]] (CarbonRMP)<br />
*** [[Spectacle]] (Eyeo - AdBlockPlus)<br />
*** [[Swan (1plusX)]] <br />
*** [[Sushi]] (Adobe) <br />
*** [[Turtledove]]<br />
*** '''Look-alike Modeling''' <br />
**** [[Scaup]]<br />
*** '''Fraud Detection''' <br />
**** [[Gnatcatcher]]<br />
**** [[Privacy Budget]]<br />
**** [[Trust Tokens]]<br />
**** [[User-Agent Client Hints]]<br />
*** '''Authentication''' <br />
**** [[WebID]]<br />
* '''Auction Management''' <br />
** [[Augury]]<br />
** [[Dovekey]]<br />
** [[Fenced Frames]]<br />
** [[Ibis]]<br />
** [[Macaw]] (Microsoft)<br />
** [[Parrrot]] (Magnite)<br />
** [[Sparrow]] (Criteo)<br />
** [[Tern]] (Adroll)<br />
** [[Turtledove]]<br />
<br />
== Reporting Projects ==<br />
Marketers reporting requirements are to understand which content generating relatively better outcomes when shown to particular audiences in particular contexts. The attribution of outcomes, which often occur on marketer properties, is part of the process that enables marketers to value the publisher inventory they buy. <br />
<br />
A goal of Privacy Sandbox is to prevent the link of positive outcomes on marketer properties back to particular publisher contexts. <br />
<br />
* '''Reporting Management''' <br />
** [[Aggregate Reporting API]]<br />
** [[Conversion Measurement API]]<br />
** [[Private Click Attribution]] (Apple)<br />
** [[Murre]] (Adroll)<br />
** [[Pelican]] (Neustar)<br />
** [[Spurfowl]] (Nextroll)<br />
<br />
== Measuring Effectiveness and Ecosystem Impact ==<br />
Many marketers are concerned that the effectiveness of their media would be impaired by having reduced access to accurate, complete and real-time feedback across the various publishers they advertise on. Many ad-funded publishers are concerned that their revenues would decline as a result of this reduced effectiveness. <br />
<br />
Below are a few studies and approaches to quantify the impact on the ecosystem, expected by the roll out of Privacy Sandbox:<br />
<br />
* Google's Effects of Disabling Third-party Cookies on Publisher Revenue<ref>https://services.google.com/fh/files/misc/disabling_third-party_cookies_publisher_revenue.pdf</ref><br />
* [[Fledge]]<br />
* [[Teetar]] (Criteo)<br />
<br />
== Regulator Perspectives ==<br />
The UK CMA noted (1.5-1.6) the following concerns with Google's Privacy Sandbox proposals that would distort competition and impose unfair terms on people who use its Chrome browser, or more specifically:<br />
<br />
# "The Privacy Sandbox Proposals have caused uncertainty in the market as to the specific alternative solutions which will be available to publishers and ad tech providers once TPCs are deprecated.... causing harm to Google’s rival publishers and ad tech providers,"<br />
# "[Google's Privacy Sandbox Proposals would] advantage its own businesses and limit competition from its rivals."<br />
# Google has an advantage due to "the asymmetry of information between Google and third parties regarding the development of the Privacy Sandbox Proposals," (e.g., roll out schedule, code-level understanding of how they work)<br />
# Google may use self-preferencing criteria "to assess different design options" (e.g., policies to quantify how much distortion in competition is acceptable if it improves Google's revenues), and <br />
# Google lack of transparency with Privacy Sandbox regarding any "evidence relating to their effectiveness against these criteria."<br />
# In addition, "given the commercial incentives that Google faces in developing Google’s Proposals"<br />
# There is at present a "lack of independent scrutiny of Google’s Proposals" (e.g., if there is disagreement about tradeoff Google would make in weighting one criteria over another)<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref><br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Glossary|Privacy Sandbox]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Sushi&diff=465Sushi2021-10-17T13:39:49Z<p>Jkoran: Created page with "Adobe’s Suggested and User-Specified Hierarchical Interests (Sushi) is centered around organizations assigning a set of hierarchical topics of interest that can later be use..."</p>
<hr />
<div>Adobe’s Suggested and User-Specified Hierarchical Interests (Sushi) is centered around organizations assigning a set of hierarchical topics of interest that can later be used in selecting relevant ads.<ref>https://github.com/privacycg/proposals/issues/27</ref> The restriction on using a fixed hierarchy of topics is meant to provide enhanced transparency to users as to the audience interest used to match content. Sushi relies on pre-defined rules to rank which attributes would be made available for decisioning logic.<br />
<br />
Adobe’s proposal adopts the goal of Google's [[Category:Privacy_Sandbox|Privacy Sandbox]] in preventing marketers from engaging a particular audience in a particular context.<br />
<br />
== Overview ==<br />
The Sushi proposal separates the assignment of topics from the later inference logic to guess what a user might be interested in. For example, a user may visit multiple sites and be assigned to four separate interest topics from the taxonomy: <br />
sports→baseball→pros→Giants<br />
sports→football→pros→49ers<br />
sports→football→college→Stanford<br />
sports→football→college→Berkeley<br />
<br />
“In this case sports has been suggested four times, football three times and college football twice ("pros" isn't counted as occurring twice, because its two occurrences are in different subtrees of the hierarchy).”<ref>https://github.com/privacycg/proposals/issues/27</ref> The SUSHI proposal suggests the web client should control the logic that relies on the recency and frequency of these topics to determine which nodes of the taxonomy are eligible for content matching.<br />
<br />
Sushi suggests the look-back window of prior activity ought to be “at least 30 days (unless cleared by the user)”.<ref>https://github.com/privacycg/proposals/issues/27</ref> Sushi suggests that for seasonal topics, such as sports leagues or holidays, the interest should persist until the next season, rather than having a cold start to relearn such an interest each season. <br />
<br />
To limit use of the user’s limited local storage for this B2B use case, Sushi suggests each organization will be limited to contribute a limited number of suggestions by a budgeting method. Thus, if one organization submits “five topics, while another only suggests one, the single topic might get five times as much weight as any of the five.” The Sushi proposal suggests that this weighting ought to also act as a hint into how strong the organization believes the user interest to be, such as “assigning a weight of 50% to the primary topic, 20% to a secondary topic and 10% to each of the remaining topics.”<ref>https://github.com/privacycg/proposals/issues/27</ref> Note: this proposal does not specify how an organization contributing only one suggested topic may limit the weighting if it is not as confident in the strength of the predicted interest (e.g., assuming a 20% vs 80% affinity).<br />
<br />
To handle the disclosure of sensitive proprietary information for each organization, Sushi states “suggested interests should remain exclusive to the advertiser until the same topic is suggested by a sufficient number of different advertisers and/or publishers.”<ref>https://github.com/privacycg/proposals/issues/27</ref><br />
<br />
Sushi suggests that in addition to generating audience interests a new icon should be displayed when this information is used to match content in the URL/bookmarks area of the web client. When clicked, this icon should show:<br />
# If Sushi was used in matching content on the page<br />
# The top-most topics inferred to be of interest to the user, regardless of current page<br />
# The current contextual topic of the page, regardless if used to match the content on the page<br />
# Any topics sent to the content decisioning system to match content on the page<br />
<br />
Moreover, Sushi suggests that the user should be able to see which URLs assigned which interest topics. Thus, if the user was assigned the topic “sports→football,” the user should see the history of all sites that were used as inputs into the behavioral classification process. If the user disagrees with the inference, then the user should be able to object, which would then block further assignment in the future.<br />
<br />
Sushi suggests that the user should be able to manually self-assign interest topics from the same taxonomy. Such self-assigned topics should be given higher weighting by the web client behavioral classification logic. The assignment of or objection to an interest at a parent node should be inherited by all children nodes in the taxonomy. SUSHI suggests that users could optionally specify a different expiration of interest topics on a per node basis.<br />
<br />
When signaling the interest topics to content matching systems, Sushi suggests that the random subset of all interest topics be sent, as well as which were self-assigned or assigned by current page. A trusted server would keep track of which combinations are so rare that this array might be used as a unique identifier by the content decisioning system. Sushi suggests that weightings of interest be used to help determine which interest topics are sent, such that higher interests are sent more frequently than lower interests.<br />
<br />
Sushi states that IAB taxonomy<ref> https://www.iab.com/guidelines/content-taxonomy/</ref> is not detailed enough to support the interest classification required for this proposal. As one approach, each organization might submit custom nodes that are more granular than the standard taxonomy.<br />
<br />
== Impact ==<br />
Similar to [[Fenced Frames]] and [[Turtledove]]/[[Fledge]], Sushi states that content matching systems should not be able to learn which ads were correlated to which conversion events. This will impair marketer effectiveness and negatively impact publisher revenues. <br />
<br />
Not all interest attributes are equally valuable to all marketers. By restricting the list of available attributes, or ranking them on criteria independent from publisher monetization, will further impair publisher revenues.<br />
<br />
Sushi's proposed weighting mechanism confuses marketers' estimated probability of accuracy with value. As mentioned above, if a marketer can guess only a single attribute (interest "topic") at 20% vs 80% accuracy this 4x weighting has no direct relationship to another marketer submitting four times as many topics.<br />
<br />
The Sushi proposal requires storage of all domains linked to the generation of each attribute, which will use greater client storage than needed at present. This forces people to absorb the cost of B2B storage and processing, that may require them to update older devices to continue to access ad-funded sites. <br />
<br />
== Open Questions ==<br />
# How will any interests scale if each organization wants its topic information to remain proprietary? <br />
# As there are millions of organizations, if each is assigning custom nodes what is the impact on local storage or classification process of interests?<br />
# How do different organizations that would prefer different rule sets to assign interest classification provide feedback to centralized behavioral interest classification system (e.g., minimum of 4 events not 3 to be eligible or 7 rather than 30 days look-back window for recency)?<br />
# How will machine learning inside the web client improve its classification of interest inferences across different browsers signed into a single domain by the same individual to ensure they are improving publisher monetization and marketer ROAS? <br />
# How will machine learning of organizations assigning interest topics learn how to improve the hints they assign to each topic (e.g., first topic should receive 50% not 20%)? <br />
# How will organizations learn which interests a user has blocked, so they stop wasting their limited budget on trying to assign those interests to those users?<br />
# Should self-assigned interests expire at the same rate as system-assigned topics by default?<br />
<br />
== See Also ==<br />
* [[Ad Topic Hints]]<br />
* [[Fledge]]<br />
* [[Parakeet]]<br />
* [[Pauraque]]<br />
* [[Turtledove]]<br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Sushi]]<br />
[[Category:Privacy Sandbox|Sushi]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Sandpiper&diff=464Sandpiper2021-10-17T13:30:20Z<p>Jkoran: Created page with "CarbonRMP’s Sandpiper proposal enables shared storage among a network of affiliated organizations.<ref>https://github.com/carbondmp/sandpiper</ref> Sandpiper employs additio..."</p>
<hr />
<div>CarbonRMP’s Sandpiper proposal enables shared storage among a network of affiliated organizations.<ref>https://github.com/carbondmp/sandpiper</ref> Sandpiper employs additional headers in the HTTP protocol with security validation through SSL Certificates.<br />
<br />
== Overview ==<br />
<br />
CarbonRMP’s Sandpiper proposal “allows a website operator to declare a sandbox that specifies how data can be accessed and shared.”<ref>https://github.com/carbondmp/sandpiper</ref><br />
<br />
Sandpiper relies on additional headers in the HTTP protocol with security validation through SSL Certificates to verify the relationship between different participants that are accessing and storing data. The nonrepudiable nature of public/private key encryption provides enhanced transparency and accountability associated with data access and processing. <br />
<br />
Sandpiper proposes adding new attributes to Access-Control-Request-Headers that govern which requests can access/update the information linked to an origin by designating the authorized domains:<br />
<br />
* access-control-allow-1p-sandbox<br />
** access-control-allow-1p-sandbox-domains<br />
* access-control-allow-3p-sandbox<br />
** access-control-allow-3p-in-1p-domains<br />
** access-control-allow-3p-in-3p-domains<br />
<br />
The “allow” designates which domains have access or update control over the information stored. These attributes require the browser to send preflight requests from the sandbox element on the site that restricts which domains may interact with the storage linked to this element.<br />
<br />
The benefit of this proposal is that a user’s interaction with a single page may update different information for different organizations that support the operations of that same site (e.g., a site analytics vendor receives all events, ad partner receives subset of events). <br />
<br />
The site controller designates which organizations may access the information by having an allow list. For example, a marketer may be given access to the ad view data to link to subsequent activity on the marketer website (e.g., shoe purchase) by granting permission to this “network.” This use case can be expanded to an organization that operates multiple domains that the same marketer has purchased a “run of network” campaign, such that each sandbox element allows that marketer access to the data stored in the local client.<br />
<br />
Governance of acceptable and unacceptable uses of the data once accessed is governed by [[Partnership for Responsible Addressable Media]] (PRAM) principles. <br />
<br />
== Impact ==<br />
CarbonRMP is to be commended for using established web standards to improve the transparency and auditability of data access and processing, without adding additional cost by relying on organizations’ existing public/private key certificates to validate which entities are involved in given transactions.<br />
<br />
The Sandpiper proposal reduces local client storage of information that would otherwise need to be redundantly stored per origin when used by the same data controller across different origins. However, given the same campaign ad event data must be stored distinctly across all origins in which the user interacts with the ad, this approach will use greater client storage than needed at present. This forces people to absorb the cost of B2B storage and processing, that may require them to update older devices to continue to access ad-funded sites. <br />
<br />
Given a site owner does not know which organization may win any given ad auction on first request to the sandboxed element, this element would need to send all possible allowed domains which would greatly slow down the user experience when interacting with a site. If domains were grouped into networks, this limitation would still put an upper limit on the number of network organizations that could compete in the open web and perhaps be a barrier to entry for new startups.<br />
<br />
== Open Questions ==<br />
* How much local storage is required to store pairwise allow lists for every domain (and origin?) that a user interacts with?<br />
* How many organizations can be allowed from a given sandboxed element without impacting user experience?<br />
* How are new entrants able to participate in digital markets? <br />
* Is the "allow" setting at a controller (e.g., marketer) level or at a supply-chain partner (e.g., attribution vendor) level?<br />
<br />
== See Also ==<br />
* [[Fenced Frames]] <br />
* [[CHIPs]] <br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Sandpiper]]<br />
[[Category:Privacy Sandbox|Sandpiper]]</div>Jkoranhttps://wiki.prebid.org/index.php?title=Falcon&diff=463Falcon2021-10-17T13:25:34Z<p>Jkoran: Created page with "Privacy-coop’s Falcon proposal describes a bitmap store to determine whether a use of personal data is permitted (“Consent DNA”).<ref>https://discourse.wicg.io/t/proposa..."</p>
<hr />
<div>Privacy-coop’s Falcon proposal describes a bitmap store to determine whether a use of personal data is permitted (“Consent DNA”).<ref>https://discourse.wicg.io/t/proposal-project-falcon-global-consent-dna-bitmaps-and-consent-management-service-cms/4634</ref> <br />
<br />
== Overview ==<br />
Falcon stores declarations for the intersection of information across legal data uses (“programs”) by organizations (“business”) by legal jurisdiction (“regulation”) by users (“subjects” by each identifier, such as an email, MAID or cookie ID). The output is binary declaration of yes/no (1 or 0) for a given intersection.<ref>https://discourse.wicg.io/t/proposal-project-falcon-global-consent-dna-bitmaps-and-consent-management-service-cms/4634</ref> Default settings for this intersection can be set by policy or regulations or controllers of the information. <br />
<br />
The Falcon proposal focuses on creation, storage and retrieval of the above information. <br />
<br />
For storage, the data can be visualized as a 3D cube referenced by a user identifier. The user identifier can be (email, phone, UID2, etc.). The “row” stores the organization (e.g., Acme x email, Acme x MAID), which is lazy provisioned. The “column“ stores the legal data use (e.g., consent for personalized marketing). The “layers” stores the jurisdictions the particular user has interfaced with, also lazy provisioned. For example, if a given user has not visited Brazil, then the Brazilian jurisdiction is not (yet) part of the layers. This helps reduce the physical storage of the information linked to each user x organization intersection. Common metadata is required such that each lazy-provisioned element of the dimension maintains the correct sequence in the bit map.<br />
<br />
New organizations, uses or jurisdictions add new rows, columns or layers to the cube respectively. Expired data is not removed, which simplifies the update process, but results in an increasingly sparse data structure over time. Each user can be linked to multiple cubes, such that each when compressed the total bitmap would be less than 100kb. For example, if we have 10 jurisdiction and 50 uses by 1,600 orgs for 1 identifier for a single individual, this would be a bitmap of less than 100kb uncompressed. If we imagine compression to add 4x storage, then we could support 4 identifiers OR 6,400 orgs if we request 4 data cubes (1 for each identifier) of 100kb each.<br />
<br />
Missing information (say jurisdiction) can be handled by Boolean AND logic. If jurisdiction is known, then only that layer of the bitmap would be used to generate the output. If the jurisdiction is unknown, then an AND operation can be used across all intersections in that user’s cube.<br />
<br />
For retrieval, an organization can submit a user identifier to the system to which the result set from Falcon is a JSON object containing the appropriate information signals linked to the identifiers in its store. That is, Falcon returns a JSON array of permitted/non-permitted uses by the three-dimensional array. The information is returned per user identifier rather than logic to do identity resolution that all identifiers link back to the same directly-identifiable individual. This means the system only returns what it has stored and does not attempt to validate the requested update or read of metadata linked to the identifier belongs to the user (“carbon-based life form”). As stated below, this is not a flaw of the design, but merely a separate scope to address authorized access for updates and retrieval.<br />
<br />
Updates can be stored as new cube, such that a timestamped record can be recreated from each cube thus creating a form of audit log of changes. Falcon also supports metering, such that after a given number of requests the answer will be 0 regardless of the true values stored. Such a “metering” feature can be used to support marketer use cases, such as frequency capping. <br />
<br />
The project is currently hosted by Privacy Co-op.<ref>https://docs.google.com/document/d/1aIWR794LtD9wlbxluzGXBQM0sKcaZgRlecSYwIMs66I/edit#heading=h.nugsr8my30g7</ref> Privacy-coop’s Falcon proposal is to be commended for providing a simple means to normalize and standardize the approach for setting, updating, accessing information stored in this bitmap.<ref>https://discourse.wicg.io/t/proposal-project-falcon-global-consent-dna-bitmaps-and-consent-management-service-cms/4634</ref> <br />
<br />
The project is meant to be a sibling to Domain Name System (DNS), hence the storage of this bitmap is called the “Consent Name Service (CNS)”. Just as the DNS system has appropriate methods to assign ownership of a domain name to an IP address, so too this system can use appropriate methods to enable end users to update preferences by organization and by jurisdiction. For example, email confirmation is required to update preferences linked to an email identifier. The authentication process is not part of the system, as the design is focused on storage, update and retrieval of the information stored in the bitmap.<br />
<br />
The same edge-based caching of DNS in envisaged for Falcon’s CNS, with redundant geographic storage for efficiency. Decentralized storage across various operators of the CNS follows the same pub/sub process of DNS updates.<br />
<br />
== Impact ==<br />
Falcon aims to provide a neutral technical mechanism to more easily manage consistent preferences across organizations and jurisdictions. <br />
<br />
Unlike other proposals that embed policy-laden processes into the technology layer, Falcon refreshingly focuses on cost-effective storage, update and retrieval of information. <br />
<br />
== Open Questions ==<br />
* Which organization adds consistent columns or layers or organizations to the storage layer?<br />
* Must the data storage approach be centralized, or can distinctly branded preference management solutions exist and interoperate? <br />
* If centralized, how would the governance of this centralized storage approach be funded? <br />
* If centralized, how would the operational costs of this centralized storage approach be funded? <br />
* How are uses (programs) determined to be the same or different across jurisdictions (e.g., “object” vs “opt out”)?<br />
* If people do not want to link different accounts across different distinctly branded preference management solutions (e.g., Facebook, Google and [[UID2]]/[[OpenPass]]) would logging into the same website using each of authorization solutions appear to that website as a different user? <br />
* How does the update process update “cubes” that contain the same userID (e.g., email) but are not linked (e.g., Facebook, Google and UID2/OpenPass)? <br />
<br />
== References ==<br />
<br />
<references /><br />
<br />
[[Category:Glossary|Falcon]]<br />
[[Category:Privacy Sandbox|Falcon]]</div>Jkoran