> 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.
Note that much of the research in privacy-enhancing technologies is about reducing the information that needs to be known to provide the service. For example, there are proposals for anonymous delivery of physical goods (https://www.cs.columbia.edu/~smb/papers/APOD_PETS09.pdf). Other examples in which the required information is reduced beyond what it would seem intuitive include ZK protocols, PIR, etc. On 01 Mar 2013, at 16:16:5, Bryan McLaughlin (brmclaug) wrote: > > > 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. >> > > >> > -------------------------------------------------------------------------- Prof. Dr. Ir. Claudia Diaz Katholieke Universiteit Leuven Dept. Electrical Engineering-ESAT / COSIC Kasteelpark Arenberg 10, B-3001 Leuven, BELGIUM tel: +32 16 32 18 14 fax: +32 16 32 19 69 email: claudia.diaz (at) esat.kuleuven.be web: http://homes.esat.kuleuven.be/~cdiaz/ -------------------------------------------------------------------------- _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
