Difference between revisions of "Parakeet"

From Bitnami MediaWiki
Jump to navigation Jump to search
m
m
Line 15: Line 15:
 
- Add noise or other random information into different requests from the same web-enabled client  
 
- Add noise or other random information into different requests from the same web-enabled client  
 
- Reduce granularity of audience interests
 
- Reduce granularity of audience interests
- Add an encoded vector of recent browsing activity, they call [[Representations]]<ref>https://github.com/microsoft/privacy-preserving-ads/blob/main/Parakeet.md<ref>
+
- Add an encoded vector of recent browsing activity, they call [[Representations]]<ref>https://github.com/microsoft/privacy-preserving-ads/blob/main/Parakeet.md</ref>
  
 
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.
 
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.

Revision as of 23:34, 2 March 2021

The goal of Google's Privacy Sandbox is prevent marketers from engaging a particular audience in a particular context.

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.

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 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.

"The ad network [or DSP] will perform ad matching, ranking and auction with contextual and user interest information provided in privacy anonymized ad request."[1]

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:

- Anonymizing the publisher requesting an ad - Anonymizing the geography from which the user is requesting content - Anonymizing the IP from which the user is requesting content - Anonymizing the User Agent String that is used to match content to the capabilities of their web-enabled device - Add noise or other random information into different requests from the same web-enabled client - Reduce granularity of audience interests - Add an encoded vector of recent browsing activity, they call Representations[2]

Parakeet relies on 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.

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."[3]

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.

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."[4]

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."[5]

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."[6] 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.

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.

Impact

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.

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.

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.

Open Questions

  • If different publishers route traffic through different gatekeepers, how many gatekeepers must one marketer query to retrieve aggregate reporting?
  • What are the estimated incremental costs that must be charged by the Parakeet service on a "per thousand requests" basis?
  • What is the process for determining which organizations' servers are trusted?
  • What is the time-delay in providing the data necessary for publishers to optimize their revenue?
  • What is the time-delay in providing the data necessary for marketers to optimize their media spend?
  • How many organizations can access the information collected by the proxy service to perform custom attribution and analytics?

References