Cover dynamic pricing use case

[dmarti]

Topics may be useful for retail, travel, and other sites to identify more or less price-sensitive users.

Existing sources of data for dynamic or personalized pricing create a risk for the seller that they are inadvertently selecting members of protected groups for higher prices. However, Topics are intended to be non-sensitive (#4) so could be practical to use for dynamic pricing in cases where other data sources are not.

Personalised Pricing: The Demise of the Fixed Price?, by Joost Poort and Frederik Zuiderveen Borgesius, covers some of the incentives for retailers to adopt personalized pricing systems.

Price discrimination can benefit both buyers and sellers, leading to an increase of both consumer and producer welfare. Price discrimination can help the seller to recoup his fixed costs without losing many potential customers and make a good or service accessible to buyers with a smaller purse, even if it will lead to higher prices for other customers.

(Based on a previous issue from a previous proposal: https://github.com/WICG/floc/issues/105 )

Related issues: #25 #42 #77 #82

[npdoty]

This seems like a directly user-hostile use case.

I would recommend we add this to the privacy threats for this proposal (and for this class of proposals) and then consider mitigations. Direct enforcement will be difficult, but we can still document the particular purpose that the data is provided for, prohibit secondary and other hostile uses, and make it possible for self-regulatory, regulatory and client-side blocklisting mitigations.

[michaelkleber]

Don: Does this type of dynamic pricing happen today with much more obvious signals, like the type of the user's device ("Special higher price for iPhone 13 users!") or IP-based geo ("More expensive in NYC!")? It seems like Topics would be both harder to use and easier to detect and subvert.

Nick: A phrase like "prohibit secondary and other hostile uses" seems to come from some sort of underlying belief that the browser gets to tell other parties how they are or are not allowed to use data. Is there any precedent for that? It's not how I think of the web platform as working, but maybe I'm failing to see parallels to existing examples.

[dmarti]

@michaelkleber Dynamic pricing seems to be moving toward a machine learning approach using many parameters. In the examples I have seen, these seem to be mostly conventional database marketing data like state of residence and new or used vehicle. (Personalized Dynamic Pricing with Machine Learning)

There have been interesting news stories in the past where customers see prices vary based on their device type or zip code, but the more complex that the dynamic pricing gets, the harder it is to see what data went into it. (Dynamic pricing is not necessarily personalized pricing. A product's price could be varying over time for all users and not being set per user. It's hard to tell from the user point of view.)

When a retailer is already running a dynamic pricing system, Topics API could provide another set of data that can be fed into it with relatively little incremental work. Adding zip code to a personalized pricing system might present discrimination issues because of demographics of different zip codes, but adding topics would not have the same issues because topics are not correlated with any protected or sensitive qualities of the user.

[dmarti]

@npdoty I don't know if this use case is explicitly user-hostile. A user who has the right understanding of the markets in which they are participating might be able to use Topics API to obtain more desirable prices or terms. (especially if they can set topics using a browser extension: #25)

[npdoty]

@michaelkleber

Nick: A phrase like "prohibit secondary and other hostile uses" seems to come from some sort of underlying belief that the browser gets to tell other parties how they are or are not allowed to use data. Is there any precedent for that? It's not how I think of the web platform as working, but maybe I'm failing to see parallels to existing examples.

This is probably a longer conversation to continue with another issue or elsewhere.

I agree that the Web platform has not generally made distinctions about permissions for how data can be used with general purpose APIs. Part of the work of patcg and other groups has been more recently to design more specific features that work for a particular purpose and have limits on their abuse. We don't want to end up in the recurring situation where some Web technologies are more frequently abused than used for their intended functions.

Browsers don't generally have the capability to tell other parties what they can do. But users frequently do have legal rights about the use of information that they provide for a specific purpose and user agents could communicate the user's explicit intent or share that data only if the requester has agreed to those limits, or block requests that appear to be abusive. Regulators can more directly take out-of-band action if it's clear that some activity is counter to the user's intention.

Regarding precedents,

• several browsers have implemented blocking (of cookies or requests) based on policies of when they think parties are using data to track users' browsing activity across sites.
• the FTC filed a complaint in 2012 when Google code used hidden form submissions "circumventing the Safari browser’s default cookie-blocking setting".
• in a related discussion last year, I mentioned that signed attestations for use restrictions was part of a proposal around IP blindness.
• the idea of explicitly indicating user permissions or attestations of server-side policies has also been considered explicitly in several instances, offhand: geopriv (attaching rulesets), 'sticky policies', DNT, P3P (particularly the implementation of Compact Policies in some browsers) -- but I think these haven't been very widely or successfully adopted for the Web.

[dmarti]

@npdoty One problem with determining whether or not to block for some uses but not others is that it's hard to tell in advance if a particular third party's use of Topics API feeds into ad targeting decisions or dynamic/personalized pricing, even if you know which first-party sites a given third party caller is present on. As pointed out in https://github.com/patcg-individual-drafts/topics/issues/77, a retailer also has targeting-related motivations to rely on topics from a widely used third-party caller.

[dmarti]

Related: https://github.com/patcg-individual-drafts/topics/issues/82#issuecomment-1209735897 -- having more SSP iframes on a retail site could enable better Topics collection for dynamic/personalized pricing.

[dmarti]

Related: #42 Higher-value topics will provide better information for dynamic/personalized pricing, without the risk of price discrimination based on sensitive information.

[jkarlin]

Closing as I think there are much stronger 1p signals than what topics could provide in this case.

[npdoty]

The particular threat here is the ability for a first party to learn signals from activity on other sites for the user-hostile purpose of price discrimination. In many cases, a first party won't have stronger signals -- the airline flight website you visit doesn't already know that you're interested in luxury watches. IP address and User-Agent signals are used, certainly, but we're actively trying to limit disclosures via those mechanisms.

Attestation, as described earlier in this thread and as recently proposed by Google, would provide a potential mitigation, if it were expanded to positive attestation (this signal is only being used to select interest-based ads for this interaction) or if it included additional negative attestations (this signal is not being used to build a profile on the user, this signal is not being used to price discriminate).

[michaelkleber]

Yup, Nick, I'm with you here. I don't think Topics would be a particularly good tool for this. But in a sense, targeted advertising inherently must be able to support some form of price discrimination, in the sense of "show ads for more expensive things to people who are likely to buy more expensive things". The risk here with Topics is vastly better than with 3p cookies, but it's not zero.

We have indeed moved towards the Privacy Sandbox APIs (including Topics) requiring some public attestation about data use, with details available at https://github.com/privacysandbox/attestation. So far we're focused on a single core privacy attestation focused on not using the data to identify you across sites.

We're open to discussions of other more-specific attestations as well, which is where this discussion seems to point. I admit that I'm not sure how it will land, because of the problem in the first paragraph — I have a feeling there may be strong differences of opinion on an airline website that prominently shows business-class seat info to people with signs of luxury goods in their past browsing habits. But if we can find consensus on a clear line for what's abusive, rather than reasonable audience segmentation, we should discuss.

(Of course, per the Poort & Zuiderveeen Borgesius paper that Don referenced, the abusive use cases may already be regulated...)

[npdoty]

There may not be an extremely bright line, but I believe there is a clear and significant difference between: 1) "I'm telling you some topics I'm interested in so that you can show me a relevant ad right now" and 2) "I'm telling you some topics I'm interested in; you can then add that info to a profile about me, charge me a different price based on those interests, personalize content on this page based on those other interests, send me targeted marketing material via email or snail mail at a later date, or sell the fact that I'm interested in that to a data broker".

[michaelkleber]

Certainly there are differences between those. But I don't think there is anything like agreement that all of your (2) should be disallowed. As above, the Privacy Sandbox POV has generally been focused on cross-site stuff, so of course we think of "add that info to a profile about me" very differently if we're talking about a profile of information seen on a single site vs anything attached to a cross-site identifier. And I'm not at all sure that "personalize content on this page based on those other interests" is inherently problematic — why shouldn't the homepage of SomeLargeShoppingSIte.com choose what to show you based on your shopping interests?

Requiring attestations for access to an API is new territory, and I feel like we have a lot of learning to do — let me be clear that I emphatically do not think that I know what the answers should be.

[npdoty]

If a user turns on this feature in their browser, which of the purposes within (2) are they agreeing to and which are they not agreeing to? Is there somewhere they can see the list?

I'm not sure I am claiming to know what the answer should be either. But I believe that there should be an answer, and not an open-ended expectation that detailed, browser-provided personal data can be used for anything except X, or anything that seems non-problematic to the site operator.

(Opened #216 as this conversation had expanded considerably beyond the dynamic pricing use case.)

[dmarti]

The Chromium browser project does have some help text that describes to users what the Topics API information will be used for. Currently this appears to be incomplete but an update here might help clarify it and address https://bugs.chromium.org/p/chromium/issues/detail?id=1423761