Tracking, privacy and platform competition
Can a platform offer zero-price services that simultaneously preserve user privacy and business relationships across websites/applications? This is a puzzle the major platforms are trying to solve. There are legitimate concerns on all sides with users wanting subsidized services without creepy tracking, and businesses wanting to serve targeted ads and/or a coherent user experience. Given widespread movement toward eliminating cross-site tracking in browsers, Google proposed the idea of First-Party Sets, which would allow related domain names owned and operated by the same entity to declare themselves as belonging to the same first party. Websites at those domains would constitute a “privacy boundary” that could be used to prevent or allow cross-site tracking consistent with terms, laws or other rules. An example might be the numerous services in the Google universe, but one can think of others (e.g. government agencies).
Google circulated the proposal with the W3C Privacy Community Group (PCG) almost 2 years ago, and later made commitments to involve the UK Competition and Markets Authority in its W3C efforts. In late May this year, competing platform Apple filed comments against FPS, stating they don’t believe “a trustworthy and equitable version of FPS can be created“. A more cynical take was published by browser upstart Brave. Some have noted that the Apple platform uses the IDentifierForVendor to similarly link apps that come from the same vendor running on the same device. Nonetheless, this month the PCG chairs decided to drop the work item, citing a lack of interest. Undeterred, Google pivoted the work to the Web Incubator Community Group, saying the proposal has support from multiple vendors and web developers.
The episode highlights the continuing tension and tradeoffs between privacy and competition in the platform economy. A related example would be Apple’s 2021 App Tracking Transparency framework, which implemented the pro-privacy move requiring user opt-in to cross-app tracking in iOS14.5, and its growing advertising business in the App Store. Platforms have an incentive to use the privacy and security of their users’ data as a product differentiator. As intermediaries between users and businesses, controlling data about interactions (and hindering the ability of other platforms to act similarly) can also maintain or increase their competitive advantage. We’ll be exploring this topic more closely in a paper to be presented next week at the Workshop on the Economics of Information Security.
ICANN 74: SSAD slimmed down and renamed
ICANN is meeting in person for the first time in two and a half years in The Hague, Netherlands. This normally gloomy city has been blessed with an entire week of sunny weather, which we hope is an oracle of the meeting’s outcomes.
One highlight of the meeting so far is that ICANN took an important step forward in its attempt to find a legal way to disclose personally identifiable domain name registration data to legitimate requestors. GDPR, you will recall, forced ICANN to redact the email address, phone number and other sensitive PII from open access Whois. The ICANN regime grudgingly and slowly accepted that, but demanded a “Standardized System of Access/Disclosure” (SSAD) that would allow legitimate requestors (law enforcement, IPR owners, etc.) to get the redacted data legally.
Initially, ICANN’s policy process produced a very complicated SSAD proposal. When the SSAD’s expense and complications ran into resistance from ICANN, the search for a lightweight version was initiated. At ICANN 74, an SSAD-lite proposal, now renamed “Whois Disclosure System,” was revealed.
The new system would implement the most sensible approach to disclosure requests: centralized requests, decentralized, registrar-controlled disclosure decisions. Requestors would establish an account with ICANN (if they don’t have one already) and use a standardized form supplied by ICANN to provide a complete and legally justifiable request for the domain for which they want registrant information. ICANN routes that request to the registrar responsible for that domain, and the registrar – who is the data controller and legally liable for the decision – decides whether to disclose the information or not. This “lite” approach relies on existing ICANN information systems, with a few modifications. It doesn’t require developing an entirely new information system. It doesn’t require accreditation, just an ICANN account. Implementing this simplified system will give us a more realistic idea of how much demand for Whois disclosure there really is and how advantageous a centralized request system is.
The proposal is not perfect or complete. It ignores the question of billing for requests, and doesn’t provide a way to keep track of who is making the requests. The original GNSO policy recommendations required users of the system (requestors) to pay for the ongoing costs of the system, and had various ways of logging requests and requestors for accountability purposes. Putting in place a Whois Disclosure System that makes disclosure requests available for free encourages overuse of the system and puts the support burden on the industry and its customers instead of where it belongs: on the parties who benefit from disclosure. The discussions at ICANN 74 also raised the issue of keeping track of who was making requests. Some data retention of who is making the requests is necessary to determine where the volume of requests is coming from and whether some parties are abusing the system. If these two problems – fees and accountability – can be fixed, the SSAD lite proposal should be implemented.
