Subject: [Ppm] PRIV BOF thoughts

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Nov 2021 23:33:34 +0200

Members of the IAB are expected to write reports about BOFs they follow. These are for the ADs (one input only), but I find it useful to post them to the list as well. Here’s my report. It is obviously, just my personal opinion.

This is a proposal to build mechanisms report statistics or measurements in a privacy sensitive fashion. The proponents had a web-focused use cases in mind, but the applicability is probably larger. 

Eric Rescorla noted that while there are cases where exact individual data is needed, in many cases what’s useful and necessary is aggregate data. What are most popular web sites, what sites don’t render properly in a given browser, what websites are trying to fingerprint browsers (detectably), what issues are people experience with a particular software, etc. There’s a subtle difference to oblivious techniques that have also been discussed at the IETF recently. The latter are good, but not good for all situations. For instance, if many variables need to be reported at the same time for statistical purposes, oblivious techniques do not provide much practical anonymity. So what was suggested in PRIV is complementary, not an alternative to things like OHAI. But both require the assumption that parties performing the service do not collude.

The basic crypto, math, and protocol pieces are relatively well understood. A number of use cases were discussed, and for instance I could see other ones as well (e.g., data produced by network nodes). In my opinion this work should clearly go ahead as a general mechanism. Getting the charter details sorted out should be possible soon. I think it is important that the charter directs the working group to understand potential abuse cases — so that we are aware of them. It would also be useful to note that a method for opting out from data collection be provided.

But I do have one concern, and that is more on the use case side rather than the core technology proposed for the working group. The IETF generally is keen on ensuring that user data does not fall in the wrong hands. We have a hard stance against surveillance. We are doing our best to ensure that no information leaks to on path attackers. However, we seem awfully soft about advertisers and commercial surveillance. A part of the BOF was focused on advertising use case. Of course it is beneficial to go from giving a stable user identity and data to the advertisers (e.g., third party cookies) to something where individual users are not identified but data collection is still enabled at least in a statistical sense. This is what techniques proposed in PRIV could do, and that’s great. However, just speaking for myself, I’d go further. For instance, some past mechanisms from the IETF have employed techniques like automatically disabling reporting for some fraction of users, such that no one can demand “every user report us this data or will not be served”. I don’t know if this is possible in the case of PRIV, but I would recommend looking at that as well as other opt out aspects.

Jari

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 16 Nov 2021 17:46:02 +1100

On Tue, Nov 16, 2021, at 08:33, Jari Arkko wrote:
>  However, just speaking for myself, I’d go 
> further. For instance, some past mechanisms from the IETF have employed 
> techniques like automatically disabling reporting for some fraction of 
> users, such that no one can demand “every user report us this data or 
> will not be served”. I don’t know if this is possible in the case of 
> PRIV, but I would recommend looking at that as well as other opt out 
> aspects.

Hi Jari,

Thanks for the input.  I think that this came up during the session and it wasn't clear that the response to this was understood, so perhaps I should give it again in writing.

Opt-out in many of these systems is better than in some of the systems you are probably thinking of.  An observer can generally tell if you have opted out of the QUIC spin bit. Not from an individual flow as each flow you originate will randomly opt out, but if they are able to see many flows, the odds stack up pretty heavily.

Here, it's different.  If you are contributing toward an aggregate, then - and this depends on the exact system, but for many of them this can be true - you can provide inputs that contribute nothing toward that aggregate.  Those inputs are indistinguishable from inputs that do contribute toward the aggregate.

For example, in Ekr's [r, x-r] secret sharing example, the value of x can be zero.  If your goal for aggregation is a count, you can contribute a value of 0 toward that count.  The anti-spoiling parts of the system that prevents count inputs of -10,000 or a billion have to allow for 0 and 1 as being equally valid.  After all, without 0 values, the 1 values either don't mean anything or they aren't protected (because the presence of an input would leak its value).

Put differently, you can show that there is no privacy loss from participation in such a system if your contributions are not dependent on things you want to keep private.

Of course, the details of the situation and the specifics of the design matter quite a bit.  I just wanted to highlight that this sort of opt-out can be made to be easy and almost completely undetectable.

I only say "almost completely undetectable" here because the privacy regime that I personally think is necessary (something we'll need to discuss), which is (epsilon, delta)-differential privacy does result in some privacy loss, particularly over time.  In that setting, multiple null contributions from the same client might be detectable given enough samples. How easily detectable and what sanctions might be possible as a result will depend on a lot of things.

I would then suggest that if this is your ask, perhaps you need to set your sights higher :)  What else might we be inspired to do to further counteract this sort of surveillance?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Nov 2021 08:38:42 -0500

Jari Arkko <[email-masked]> wrote:
    > Members of the IAB are expected to write reports about BOFs they
    > follow. These are for the ADs (one input only), but I find it useful to
    > post them to the list as well. Here’s my report. It is obviously, just
    > my personal opinion.

Thank you.

    > I think it is important that the charter directs the working group to
    > understand potential abuse cases — so that we are aware of them. It
    > would also be useful to note that a method for opting out from data
    > collection be provided.

I agree.

    > But I do have one concern, and that is more on the use case side rather
    > than the core technology proposed for the working group. The IETF
    > generally is keen on ensuring that user data does not fall in the wrong
    > hands. We have a hard stance against surveillance. We are doing our
    > best to ensure that no information leaks to on path attackers. However,
    > we seem awfully soft about advertisers and commercial surveillance.

After reading your write up I made a connection in my caffeine deprived brain
to reputations for IoT devices.

To date, IoT devices do not widely practice RCM (Randomized/Changing MAC
addresses, see MADINAS).  Right now, they are relatively easily tracked (and
indexed) by their MAC address.   There is a serious tuscle between needing to
keep track of who is who, in order to pin down where attacks are coming from.

Is there a significant (moral?) difference between a malware infested device doing RCM
to evade detection, and a web browser user who is trying to keep from being tracked?

What does this have to do with PPM and the other content of this BOF?
I'm not exactly sure yet,  but it seems related to me.  In effect, the
smartphone is a people-infested IoT device doing RCM to evade tracking.

    > A
    > part of the BOF was focused on advertising use case. Of course it is
    > beneficial to go from giving a stable user identity and data to the
    > advertisers (e.g., third party cookies) to something where individual
    > users are not identified but data collection is still enabled at least
    > in a statistical sense.

On a personal note: it would be so nice if I could publish a statement to
advertisers saying, "Go away, I just bought one" :-)

    > This is what techniques proposed in PRIV could
    > do, and that’s great. However, just speaking for myself, I’d go

It seems like a good idea to me.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Nov 2021 17:09:04 +0200

Martin,

Thanks for this! As I too said during the BOF, it is really good news that these techniques appear to be quite friendly for this kind of operation.

I sent my email to underline the importance of this from a requirement perspective.I don’t have a strong opinion about how that’s achieved, but it is important for the end users in my opinion, and that there’s ability on either the end users or their client software to choose suitable behaviours for their purposes. I’d prefer something about the requirement be stated in the charter.

If you think we could set our sights even higher, that’s even better news. Lets discuss!

Jari 

> On 16. Nov 2021, at 8.46, Martin Thomson <[email-masked]> wrote:
> 
> -- 
> Ppm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppm

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 18 Nov 2021 08:44:09 -0800

On Thu, Nov 18, 2021, at 7:09 AM, Jari Arkko wrote:
> Martin,
>
> Thanks for this! As I too said during the BOF, it is really good news 
> that these techniques appear to be quite friendly for this kind of 
> operation.
>
> I sent my email to underline the importance of this from a requirement 
> perspective.I don’t have a strong opinion about how that’s achieved, 
> but it is important for the end users in my opinion, and that there’s 
> ability on either the end users or their client software to choose 
> suitable behaviours for their purposes. I’d prefer something about the 
> requirement be stated in the charter.

If I'm understanding correctly, this seems to be a deployment and use case specific consideration, and not a relevant protocol detail. As such, I don't think we should include this in the charter. 

Best,
Chris

---

From: Ted Hardie <[email-masked]>
Date: Thu, 18 Nov 2021 16:55:14 +0000

Hi Christopher,

On Thu, Nov 18, 2021 at 4:44 PM Christopher Wood <[email-masked]>
wrote:

> If I'm understanding correctly, this seems to be a deployment and use case
> specific consideration, and not a relevant protocol detail. As such, I
> don't think we should include this in the charter.
>
> I think Martin's point was that the protocol requirement was that a client
MUST be able to contribute no or null data to the aggregate.  If I
understand Jari correctly, his point is that the system level requirement
is that the client must have control surfaces that either permit this or
make it the default.  That's an API requirement rather than a wire protocol
requirement, but I don't think it is deployment and use case specific.

Am I misunderstanding your point here?

regards,

Ted Hardie

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Nov 2021 08:59:34 -0800

On Thu, Nov 18, 2021 at 8:55 AM Ted Hardie <[email-masked]> wrote:

>> If I'm understanding correctly, this seems to be a deployment and use
>> case specific consideration, and not a relevant protocol detail. As such, I
>> I think Martin's point was that the protocol requirement was that a
> client MUST be able to contribute no or null data to the aggregate.  If I

Well, I don't think it's an API requirement so much as an end product
requirement. In any case, such a requirement seems like a WG question, not
a charter question.

-Ekr

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 18 Nov 2021 09:04:31 -0800

On Thu, Nov 18, 2021, at 8:55 AM, Ted Hardie wrote:
> Hi Christopher,
>
>
> On Thu, Nov 18, 2021 at 4:44 PM Christopher Wood <[email-masked]> wrote:
> client MUST be able to contribute no or null data to the aggregate.  If 
> I understand Jari correctly, his point is that the system level 
> requirement is that the client must have control surfaces that either 
> permit this or make it the default.  That's an API requirement rather 
> than a wire protocol requirement, but I don't think it is deployment 
> and use case specific.
>

Yes, I think so. Whether clients participate in the protocol is entirely up to them and their implementation, right? 

In any case, I don't think it's useful to focus on requirements that don't affect the core protocol, but I understand if others wish to do so.

Best,
Chris