Re: [w3ctag/design-reviews] Early design review request: IPA (Issue #823)

Operating a helper node is something Mozilla has considered, but we're not inclined to do so for a few reasons.  Foremost of those is that we're looking to use something like the CA/Browser forum as a reference model for governance.  That is, we want to have a common set of helper party networks that are trusted and overseen by a group formed by multiple browsers.  In other words, having browsers oversee the operators of those networks.  Having the browser involved both in operation and oversight would introduce some fairly gnarly conflicts of interest that seemed best to avoid.

As for the [other points](https://github.com/w3ctag/design-reviews/issues/823#issuecomment-1470681893) you make @ShivanKaul:

Regarding users vs. sites (point 1).  Yes, this is directly acknowledged in the explainer.  It's come up a number of times in PATCG meetings specifically in the context of the priority of constituencies.  This is something that I recognize that each of us weight differently, but we'll note that the priority is necessarily loose, so there are a few ways that I think you can justify doing something like attribution.

The magnitude of the benefit here needs to be considered.  The IPA design deliberately imposes a very low cost on users.  Leaving aside trivial amounts of bandwidth and compute, the primary cost is the privacy loss (in the formal DP sense) that accrues through providing sites with the ability to perform aggregated attribution.  Mozilla's position here is that - provided that we can find an acceptable set of parameters, especially for the $\epsilon$ and $\delta$ in the $(\epsilon, \delta)$-differential privacy - this cost is acceptable for general web browsing cases.  That is, acceptable if the corresponding advantage provided to web sites is significant.  And for that I think that the case has been made by those in the advertising industry: measurement capabilities provide enormous benefit in terms of being able to profitably run an advertising business.

Again, we acknowledge that benefits that users see are likely to be indirect, at best.  Access to ad-supported content is not automatic here.  The advertising industry has some pretty bad incentive structures and it might be that the current trend away from ad-supported content will continue, with the benefits to users not be realized.  But we do believe that advertising has demonstrated an ability to provide support to sites that can be more equitable than other business models as it largely shifts the burden on to those who are more willing or able to support advertisers.  A progressive taxation system, if you will.

Ultimately, there are a lot of things to consider here.  It's understandable that you might distrust the advertising industry.  There are a lot of shady practices that probably won't stop as a result of us building this stuff.  Many actors are unhappy with the share of revenue taken by intermediaries (what's new).  Hell, some of that will probably get worse despite our efforts, but that is a risk for a lot of the stuff we build.  We could, as I think you are implying, refuse to do anything here, but there are those of us that think that leads to undesirable outcomes, like a far less equitable web.  What we are trying to do here is to avoid the worst pitfalls and build safeguards for the rest, technical if possible, procedural and policy-based for the gaps.

You identify a few areas that are particularly challenging for IPA.  Some of its flexibility comes with inherent trade-offs around things like user transparency.  You also identified one area that continues to be challenging for us with the point you make about match key providers.  All I can really say is that these represent some of the harder trade-offs we've made in the design.  Having some more discussion about these choices relative to some of the alternatives might be the best way to proceed, because some of those choices can be hard to rationalize without putting them into the broader context.  I also want to acknowledge explicitly that the context I'm talking about includes not only how sites receive support, but how browsers support themselves.  (You might also add bad behaviour from information brokers and regulatory interventions into what is turning out to be pretty complicated.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/823#issuecomment-1472882067
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/823/1472882067@github.com>