jwrosewell: "across multiple devices and browsers"
ekr opened this issue · comments
Note: I am moving gdoc comments into this repo.
@jwrosewell suggests that we should replace text about
"— including non-browser agents, like Operating Systems — to collaborate in" with
"across multiple devices and browsers"
I'm unclear (apologies if this was clearer when in gdoc) whether this is about removing the clarification that this includes non-browser agents or about adding the clarification that it means dealing with user agents across multiple devices. The "and browsers" part seems entirely superfluous since we're already talking about user agents plural, but the cross-device aspect is not currently explicit in the current text.
I'd be -1 to removing the current clarification, because it goes beyond at least my understanding of the definition of user agent in UAAG. (Which is probably the thing someone would find if they were looking for a definition.) However the text as it stands is a bit odd, because it moves from "user agents" to "agents" in order to get there and could perhaps be more explicit to achieve that. I'm in favour of the scope it establishes.
I'd be +0 for being explicit about multiple devices. It comes after the statement in the previous paragraph which puts privacy guarantees in the purpose, so I don't think it opens up a space we definitely don't want to consider. It is implied (at least for me) in the "may consider" statement as it stands.
The intention was to introduce solutions that work across different devices and browsers for the same user. Here is what I intended the changes in this area of the document to be.
Current:
The Working Group will specify new web platform features intended to be implemented in browsers or similar user agents. The purpose of these features is to support web advertising and provide users with privacy guarantees with a strong technical basis.
The Working Group may consider designs that allow user agents for the same user — including non-browser agents, like Operating Systems — to collaborate in providing advertising features.
Revision:
The Working Group will specify new solutions to support web advertising that provide users with privacy guarantees supported by technology.
The Working Group may consider designs that allow multiple parties for the same user to collaborate in providing advertising features across multiple devices and browsers.
I would like to make sure that our scope here includes relevant technical proposals that would be needed for projects that have backend requirements like MPC or PARAKEET. I would also like to make sure that we can include things like interactions with Bluetooth beacons or the behavior of DOOH web-based devices (just as two examples) but I'm not sure that this phrasing is the best way to do that.
I meant at the meeting to refer to the prior comment. I will place this in a PR as suggested.
The point of the change is to address the advertisers requirement that Artie Bulgrin made at the beginning of the 5th April 2022 meeting concerning advertisers desire to measure across device. Clearly solutions that offer such a feature will be more valuable to advertisers like P&G. Therefore ensuring the group can meet all of advertisers requirements seems essential. If the group is constrained to prevent it from advancing such solutions only those platforms that can meet those requirements, perhaps via cross device sign in services, will receive the lions share of the revenue.
Again, this appears to veer off in unexpected tangents, but I wanted to object to the notion that we might address ALL of the requirements an advertiser might deem essential. Some practices might contravene established policies. Other might not be possible within the framework set out by this group.
What is more reasonable is that people bring requirements here and we discuss if and how those might be accommodated, either by existing work that is planned and agreed, with or without changes. Or whether we might want to take on more work to address those use cases. OR... whether we might defer that particular request on the basis we have enough work already. ORRR (and this is the big one) that the request is not something the group wants to take on.
All of these options are possible. Just because you have use cases doesn't mean you have a right.
If this was simply to request that we consider that advertisers of different sizes have different needs and that we might avoid privileging the needs of the large (implied: over the small), that's entirely reasonable, but that is not necessarily a matter for the charter. That might be a principle we agree to (or one that already exists in the W3C literature, I suspect it does already in some form).
This is also a tangent, but I think it will help illustrate why it might be important to support cross-app/cross-device reporting as well as provide insight into why we need better privacy preserving advertising options. I expect most of this is not new for this audience, but I will provide a little background.
Ad supported sites, services and apps need a minimum amount of revenue to support their operations and encourage future improvements. Advertising using third-party cookies with cross-site tracking provides that revenue today (at least where third-party cookies are still available and the tracking is permitted by law or lack thereof).
As third-party cookies go away for many sites, revenue will drop. Sites with audiences that are at least somewhat loyal are either putting up paywalls to cover the lost revenue or are requiring the creation of a free login. With the login information, they are able to track that user not only across sites, but across devices. This makes ads served on these sites more valuable than tracking based simply on third-party cookies. This is especially true for streaming media devices (Roku, Apple TV, etc.), where purchases/conversions never happen on the device. I’m sure there are studies that have estimated the premium that sites requiring a login get, but for the sake of discussion, let’s just assume that revenue per ad increases by an average of 20% (all estimates that follow are simply provided as potentially realistic examples rather than research-supported numbers).
Sites that cannot or will not require a login will see a drop in revenue (perhaps 20%?) as ad spend moves to the sites with better tracking. As third-party cookies disappear, revenue will drop further unless comparable functionality is made available via the solutions we are trying to develop here. Ads based solely on first-party, contextual data will be worth considerably less than ads leveraging knowledge gleaned from other sites/sources, especially for small sites with infrequent repeat visitors. Revenue on these sites might easily drop by 75%. Streaming video ads are rarely clicked (in apps and streaming devices they are often not even clickable). If view-through attribution is not supported, the value of video ads may drop by 80%. If frequency capping is not supported, value drops by another 5-10%. If view/click fraud are not easily detected/prevented revenue drops an additional 90%.
All the revenue lost by these sites will flow instead to the sites that are requiring a login, making the login requirement even more valuable. The net result will be that the revenue per ad on sites requiring a login may be 20X the revenue per ad on sites that don’t. This will force any site that can require a login to do so. Thus, the privacy enhancing features being rolled out by browsers will actually result in less privacy for the average user, because the tracking will be cross-device using an ID that directly identifies the user rather than the pseudonymous, single-browser ID generally used by third-party cookies.
I would like to see advertising solutions that offer privacy-friendly sites the ability to capture at least a good fraction of the revenue of sites that utilize cross-device tracking. The goal of IPA fits well with this desire as it supports private cross-device (but the attribution detail may be too limited). PCM, PARAKEET, FLEDGE, Topics and similar are also steps in the right direction. However, in the discussions we are often so worried that we might expose a tiny bit of fingerprinting surface that we restrict their functionality to the point where they are scarcely more valuable than not providing the feature. The result is that privacy-preserving advertising will not fund most sites and they will go out of business or be forced to require a login.
I would love to explore ways that we can relax the fingerprinting concerns to allow sites with strong, legally enforceable privacy policies and/or sites where cross-site tracking without permission is prohibited by law with stringent enforcement to be able utilize privacy-preserving advertising with better functionality even though it could be misused for fingerprinting. The illicit cross-site tracking must occur on lots of sites or it won’t build a sufficient profile to be valuable. If it occurs on lots of sites, the use of the technology will be discovered and the ad tech companies that perform it will be shut down or kicked off reputable sites (causing them to go out of business).
Considering that we do intend to handle cross device considerations and that participants feel that could be done under the current charter, putting aside the tangents, I'm unclear if there remains a need for a change here. @martinthomson @benjaminsavage @csharrison as the leaders of such proposals that have been actively made, do you feel that the WG charter would prevent you from working on cross-device attribution in your proposals?
do you feel that the WG charter would prevent you from working on cross-device attribution in your proposals?
Nope. I feel good about the current state of the charter. I feel confident that work on cross-device attribution proposals is commensurate with the charter.