On 01/03/2013 13:19, "Claudia Diaz" <[email protected]> wrote:
> >On 01 Mar 2013, at 01:22:12, SM wrote: >> At 15:56 26-02-2013, Eric Burger wrote: >>> So what if we just said Security Considerations must include what some >>>people call privacy considerations? If we cannot agree on a concise >>>definition of security vs. privacy, what is the typical draft author >>>going to do? >> >> Security Considerations can be stuff like "MUST implement TLS". >>Privacy considerations would be about the decision of an individual. > > > >Framing privacy as "decision-making" is useful when dealing with privacy >settings/policies and user interfaces -- this is actually a usual >definition of privacy in HCI (see, eg, the work from Cranor or Acquisti >on feedback and awareness, privacy nudges, etc.). > >I would however think that it is too restrictive (and potentially >misleading) when addressing privacy considerations more generally, and >particularly in protocols that the individual does not necessarily >understand in detail. > >BMC> > >I would offer that the decision making of the consumer is later in the >privacy process especially in the IETF context. Our design process is >orthogonal to the privacy choice of the consumer/user upon service >signup/purchase. > >We must also remember that private data can be processed to deliver the >service. You need to know my address to deliver the parcel, the mobile >phone company must know my ID and my location 0cell tower attachment- to >connect the call etc etc. > >I hallucinate the following process: > >We define the data to be collected for a protocol/service/architecture. > >We then analyse the resulting list of data and determine if it 'may' be >affected by privacy concerns. - This is where we need to make life easier >for ourselves by having access to globals relevant guidance and keeping >it up to date. > >We then determine if the context of its use is appropriate within the >privacy context. > >In the above location example the mobile phone company 'may' not 'need'a >more granular location to deliver the service as sold. Particularly if >that greater accuracy is to be used to offer value added services or >insight into the movement of the subscriber. >They may need a more granular location to offer greater level of original >service such as informed offload etc. > >We can then use the process above to design the architecture to allow the >greater level of location processing but also recognise that the service >may need to be offered without than granularity. > > _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
