The proposal, first published by Microsoft in February 2021 and examined this week by PPC Land, never became an Edge feature, a W3C specification, or a browser-wide standard. Yet its history is useful because it exposes the basic trade-off behind privacy-preserving advertising: protecting a user often means placing considerable trust in a new intermediary, and Microsoft’s design put that intermediary close to the browser vendor itself.
PARAKEET stood for Private and Anonymized Requests for Ads that Keep Efficacy and Enhance Transparency. Its original premise was direct: Google’s then-competing TURTLEDOVE design moved ad auctions into the browser, which Microsoft argued would require publishers, exchanges, and demand-side platforms to rewrite core systems. PARAKEET instead tried to preserve the existing server-side auction model while filtering the data those systems received.
Microsoft’s Chromium Intent to Prototype, filed in August 2021 by Brandon Maslen, confirms that architecture. It described a browser-trusted service that would anonymize advertising requests and send non-identifying site context plus cross-site interest data to an ad network in a unified request. The same filing listed no specification and no requested TAG review, an early indication that this was a design experiment rather than a deployable web platform commitment.
A proxy between Edge and the ad network
The first PARAKEET design had three jobs: keep interest data locally in the browser, transform it before release, and relay the eventual advertising request through a service trusted by the browser.
A website or advertiser could add a browser to an ad-interest group using JavaScript. The browser would retain those memberships locally, subject to an expiry period. Rather than disclose raw browsing-derived interests to an ad network, PARAKEET proposed converting them into a coarser representation using differential privacy—a mathematical approach intended to make any one user’s contribution difficult to infer from the output.
At ad-request time, the browser would send the request to the PARAKEET service, not directly to the buyer. The service would remove or reduce identifying signals such as the page URL, page title, IP address, precise location, and detailed user-agent information before passing permitted signals onward.
The key mechanism was k-anonymity: if a particular signal combination was too rare, it should not be sent. A location value, for example, would be broadened until it was shared by a sufficiently large group of users. An unusual bid floor could also be rounded because a highly specific price could itself become a fingerprint.
This was a more consequential idea than simply “hiding the IP address.” Advertising requests can be identifying when several individually ordinary fields are combined: a rare page context, a narrowly sized ad placement, language, browser characteristics, a location, and a distinctive bid floor may together describe a very small audience. PARAKEET explicitly treated those combinations as a privacy risk.
For publishers and ad-tech operators, the commercial attraction was obvious. The request still reached the existing ad network, and the ad network still conducted the auction on its own infrastructure. Microsoft was proposing a privacy filter at the boundary, rather than a wholesale relocation of bidding logic into every user’s browser.
The privacy promise also created a central point of trust
The technical weakness was built into the proposed remedy. PARAKEET had to know enough to remove, coarsen, combine, and judge the uniqueness of data. That made its proxy service a powerful data-handling point even if it was designed not to reveal raw information to bidders.
The original explainer acknowledged several attack classes, including request timing correlation, repeated requests that could reveal more about a user’s interests, and “contextual stuffing,” where an attacker could manipulate shared context to undermine anonymity thresholds. Those admissions deserve attention: a design that lists its own attack paths is not necessarily defective, but it is also not a finished privacy guarantee.
Microsoft’s structural answer was that the service should be browser-vendor operated rather than federated among many providers. That reduced the number of entities a user needed to trust, but concentrated responsibility in the browser company. For an Edge user, the difference is not academic: the model would have asked Microsoft to operate a gatekeeper for data that publishers, advertisers, and ad networks otherwise receive through a fragmented set of direct requests.
Mozilla had already warned in 2021 that both Google’s FLoC and proposals such as PARAKEET needed to be judged by whether privacy improved for everyone, while flagging the centralization risks inherent in such infrastructure. Later academic research into interest-disclosing advertising mechanisms likewise found that privacy claims around interest signals require scrutiny, especially when adversaries can make repeated observations or coordinate across sites.
PARAKEET’s most important lesson is that privacy engineering does not eliminate trust. It changes who must be trusted, what they can observe, and whether independent parties can verify the claimed limits.
Microsoft later changed the part it said should remain unchanged
By April 2022, Microsoft had revised the plan into “PARAKEET with Noisy Ranking.” The change was substantial.
Instead of acting primarily as an anonymizing relay that passed protected signals to an ad network, the trusted service would take on ranking work itself. It would convert user data into an embedding, add calibrated noise, process requests in batches, and run buyer-provided ranking logic within the service. Microsoft’s own Edge explainer archive now classifies both the original PARAKEET and the Noisy Ranking revision as historical proposals rather than active work.
That shift narrowed the gap between PARAKEET and Criteo’s SPARROW proposal, which also relied on a trusted intermediary for auction-related work. It also weakened PARAKEET’s original political and operational pitch: that privacy could be added while preserving the ad industry’s established server-side bidding infrastructure.
The revised design may have reduced the data directly exposed to an ad buyer, but it moved more responsibility into the trusted service. In practical terms, Microsoft was no longer just proposing a privacy-aware proxy. It was sketching a specialized ranking environment capable of handling sensitive signals and proprietary buyer logic.
That is a much harder system to standardize, operate, audit, and fund. It requires assurances about software isolation, model handling, reporting, abuse prevention, latency, cloud operations, and the circumstances in which participating firms can inspect or influence a result.
The successor borrowed more from Google than PARAKEET did
Microsoft formally unveiled its Ad Selection API in March 2024. The company said the API would support relevant advertising without third-party cookies or other cross-site tracking identifiers, using k-anonymity, differential privacy, and trusted execution environments, or TEEs, to protect data during auctions.
This was not a PARAKEET rebrand. Microsoft’s current privacy-preserving-ads repository labels PARAKEET, PARAKEET with Noisy Ranking, MaCAW, and Masked LARK as archived proposals, while its active documentation centers on the Ad Selection API.
The direction of travel is revealing. The active proposal is structurally similar to the broader family of Protected Audience-style designs, including interest groups and protected auction infrastructure. Microsoft’s own repository explicitly directs readers to Google’s Protected Audience documentation as background material. Where PARAKEET began as a case for keeping familiar ad auctions on existing ad-network servers behind a Microsoft-operated anonymization layer, the successor embraced secure off-device execution and much closer conceptual alignment with the industry’s emerging designs.
Microsoft did make a limited developer preview of Ad Selection available in Edge preview channels during 2024, as reported by outlets including Tweakers and HTML.it. But that was an experiment for developers, not a deployment of PARAKEET for ordinary Edge users, and it should not be confused with a broadly shipped replacement for third-party cookies.
The market moved on before the standards argument was settled
PARAKEET’s decline became clearer as the wider privacy-advertising project lost momentum. In October 2025, Google said it would retire most Privacy Sandbox technologies, including Protected Audience, Topics, Attribution Reporting, and related services, citing ecosystem feedback and low adoption. That decision removed the high-profile counterpart against which Microsoft had originally framed PARAKEET.
Microsoft’s advertising business also changed. Microsoft Advertising announced that it would stop supporting media buying through its Microsoft Invest demand-side platform on February 28, 2026, with Amazon DSP positioned as the preferred transition route. The company retained its sell-side and curation offerings, but its retreat from operating a DSP makes PARAKEET’s original plea to preserve established buyer-side auction infrastructure read differently in hindsight.
For Edge administrators and Windows users, there is no PARAKEET setting to deploy, block, or troubleshoot. No PARAKEET API reached a stable Edge release, and there is no evidence of an active PARAKEET origin trial in Microsoft’s current origin-trial catalog.
What remains is a useful record of a failed approach. PARAKEET tried to preserve server-side advertising auctions by placing a privacy service between the browser and the ad market. Its unresolved problem was that the service needed to become both highly capable and exceptionally trusted. Microsoft’s later move toward TEEs did not erase that problem; it replaced a browser-vendor-operated gatekeeper with a more distributed but technically demanding trust model.