Re: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT)

[<[e-mail]>]

Stephen,
Thanks!

 
> I agree, something like:
> 
>   o  Privacy Conserving - the protocols and procedures should respect
> the
>      sensitive information of all those involved in measurements.

I think 'Privacy respecting' is better than 'Privacy conserving'.

> 
> >
> > - 5.4 (and elsewhere) I'm not sure a Group-ID by itself is sufficient
> > to hide identity (timing and soure addressing may expose it anyway).
> > That should be noted, and that lmap protocols should be analysed to
> > see what turns out to be the case. I'm not sure talking about
> > "anonymising" is really correct as anonymity is a very very hard
> thing to achieve.
> 
> That's a fair point, we could add this limitation in section 5.1, the
> second bullet seems to be where Group-ID is first discussed in some
> detail.  (It's never claimed that Group-ID fixes cures all ills.)
> 

Agree with above. The idea of Group-ID was so that you had to do some work to discover the end-user's identity - do it deliberately. With the MA-ID you have to do work not to know the MA's identity. 

In Section 5.4
>>   The Report contains:
>>   o  the MA-ID or a Group-ID (to anonymise results)
I agree this puts it too strongly. How about something like "to obscure the MA's identity"

I'm not sure whether this sentence in S8.4.1 needs to be similarly toned down:
<< Assignment of a Group-ID
   enables anonymisation sets to be formed on the basis of service
   type/grade/rates.  
>>
Perhaps "obfuscation sets" would be better?

Similarly in S8.6.2
<< Another anonymisation technique is for the MA to include its Group-ID
   instead of its MA-ID
>>
"obfuscation technique"?

> 
> >
> > - section 8: I didn't spot considerations related to
> > re-identification, which can be significant.  E.g. if I can see other
> > traffic that identifies a person and the re-identify that person
> based
> > on LMAP trafic later on (or elsewhere). Did the WG consider that?
> 
> The short answer is that if RFC 6973 had considered re-identification,
> we would have.
> The closest topic we covered is Correlation, combining various separate
> pieces of info to obtain identity. The point is that an LMAP system
> could unwittingly complete an information chain if it exposes any
> sensitive info, so don't.
> 
> If a user's access with another system already gave away sensitive
> info, correlation is clearly easier and can result in re-
> identification, even when an LMAP conserves sensitive information to
> great extent.
> We could add this point in 8.5.3.

If I understand your point, it's that the LMAP measurement traffic or control /reporting messages from a particular end-user may contain a 'signature' that enables someone to track the end-user (perhaps they're mobile)
Interesting point, would be worth adding somewhere. 

> 
> >
> > - section 8: I'm not sure that the "user consent"
> > thing is really of that much benefit here (and it's ubiquitously
> > abused on the Internet today).  It would have been welcome had the WG
> > come up with something better, but then since I don't have a solution
> > to hand, I can't insist that you do;-)
> 
> Right now, user consent and temporary/per-instance user consent are
> helpful if the protocols communicate the permission status, or stop
> transactions when they don't get indication of permission. We have
> difficulty limiting what consenting adults do.
> 

User consent and empowerment seem central to Data protection and privacy regulations and discussions. I agree with you that the Internet industry hasn't worked out how to make this meaningful - beyond today's mostly unread T&Cs and (in Europe) irritating messages about cookies.