Re: Privacy Guidance Draft - Your Feedback Needed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Robin, 

thanks a lot for your feedback. Highly appreciated. 

A few remarks line: 

On Jul 2, 2013, at 7:05 PM, Robin Wilton wrote:

> Hi Hannes - 
> 
> Sorry for taking a while to respond, and many thanks for doing the work on this draft, which I think will be a very useful resource.
> 
> I just have comments on a couple of the early sections which - as you note - need some clarification. Hopefully my comments will contribute towards that.
> 
> 
> 
> Robin Wilton
> Technical Outreach Director - Identity and Privacy
> Internet Society
> 
> email: wilton@isoc.org
> Phone: +44 705 005 2931
> Twitter: @futureidentity
> 
> 
> 
> 
> On 26 Jun 2013, at 07:29, Hannes Tschofenig wrote:
> 
>> <privacy-questions-markup.pdf>
> Am I able to have actions on this personal record?
> 
> [karl]
> Further clarification is needed here. What type of actions should be applied to the personal data?
> 
> 
Robin wrote: 

>> At one level, there's a technical question here about whether or not there's a user interface to the data in question. For example, supposing a mobile handset periodically records its location and sends that to a third party: at one level, we might just be interested in whether there's any way for the user to access the data in question. 
>> 
>> At another level, there's a regulatory/compliance question here. If we assume that, in this use-case, data about the end user is collected by a third party who, in doing so, fulfils the role of data controller, then the third party may have obligations to allow the user access to the data, correction of errors and (if the EU has its way) enforcement of the data retention period.
> 


[hannes] So, you interpret the question about "actions" regarding the personal data as a question about user participation in general. That makes sense for me. 



> 
> 
> May I fake it? (think about fuzzy geolocation or voluntary fake location)
> 
> [karl]
> 
> Further clarification is needed here. In general, information from end devices can be faked in a variety of ways. For information that is provided by a third party this might be more difficult. Which case are you referring to? 
> 
> 
Robin wrote: 

>> I think there's a general point here about data that is generated or collected with no explicit action on the part of the user. The degree to which the user can preserve their privacy under those circumstances varies depending on the data and how it is collected. A couple of examples might help the discussion along. For instance, passively collected facial biometrics via CCTV would be quite hard to fake. At the other end of the spectrum, user self-asserted attributes can often be faked (the technical term sometimes used is "lying" ;^)  ). In between, there are (as Karl suggests) attributes that could be "disclosed to a certain level of accuracy" - such as location, age, creditworthiness and so on, or "disclosed to a certain level of assurance" - such as identity.  
>> 
>> From a privacy perspective, especially if one is aiming for "privacy by design", there needs to be careful thought if "accurate" attributes are being disclosed about the user, without the user's knowledge or consent. That's not to say it shouldn't happen. For example, citizens who drive a car have to accept the condition that they drive around with a permanent, publicly-visible identifier on the vehicle. However, if you start from an assumption that anonymity online should be possible (whether or not it's the default), then some privacy designs might need to incorporate a trusted third party, who preserves the end user's anonymity under normal circumstances, but can confirm the user's identity if accountability is needed (and under the right legal conditions).
> 
[hannes] OK. This is again about user control. Of course, if the user is not consent to the collecting and processing, or has no control over the who to share the information with and with what granularity then there will be issues. 

Do you think that the current text in the document captures these user control aspects, even though they very quickly reach outside the realm of the author of the protocol specification: 

- ---------

User Participation

Many Web protocols allow data to be made available through APIs and other protocol mechanisms. It is important for users to be able to control access to their data. What controls or consent mechanisms does the protocol define or require before personal data or identifiers are shared or exposed via the protocol/API?

Does the user have control over their data after it has been shared with other parties, for example regarding secondary use? Are users able to determine what information was shared with other parties?

What recommendations can be given to implementers and the deployment community regarding privacy-friendly sharing of information? This in particular refers to the ability to provide additional information about why the sharing is taking place (the purpose), what information is shared and with whom. Further relevant is to control the degree (or the granularity) of information sharing. Will the data subject be given enough context to make an informed decision? Will the decision about sharing with others be persistent? If so, for how long is the decision cached and how can it be revoked?

- ---------


>> Just a couple of thoughts, but I hope this helps. As I say, I think the document is going to be a very useful resource, so wanted to chip in with my 2c-worth.
>>  
Thanks. It indeed helps. 

> 
> Best wishes,
> Robin

Ciao
Hannes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJR3uclAAoJEGhJURNOOiAtlscIAIMvtpjOrKjCB6yoixFX7xlk
F87tPhQmFIS+6SOOyFyDSfMYysrE74NQCSt+YsojHgR4UtUJq7lya3KY6H4Gfo2O
CsCYlHOSFHeTqCGjYciL0vQumJw4eCFzymAsYsKIoKIKcAcxZDc3uVeonJ7xWEds
L31hyo4Pm242n4GbQ4/F4wL9s3y8aiblh9njN2nnQgD7aOaFpFOlgcR0Ghq4720j
/d2lKTSblUQLYjtF8CRqbbGznKtcTd90/OKmgk6F8RZzFepl8gPbEzLYDo+CqUeb
lY+0gTMWFKk628ZRzRalbD71pGwvB84igmYeO1hGuwvjArBi3D5hYBTKY1GXnAQ=
=MP0v
-----END PGP SIGNATURE-----

Received on Thursday, 11 July 2013 17:11:34 UTC