[Privacy-Practices] General editorial feedback

http://dev.w3.org/2009/dap/privacy-practices/

I believe this document will be obsolete soon, but it was on my to
review pile...

> Privacy should be a default mode of operation,
> including the concepts of considering from the beginning of design

s/including the concepts of considering/its concepts included for consideration/

> and implementation, making privacy the default, and reflect other
> principles of "privacy by design" [PRIVACY-BY-DESIGN].

> Consider privacy as part of design

This item doesn't end with a period

> The user should drive decisions that affect their privacy within the
> context of the service

This item doesn't end with a period

> User decisions should be made in context at the time of an operation
> requiring a decision.

This item does end with a period.

!?

>  The end user should know the privacy implications of the service, and

s/know/understand/ -- knowing is pointless

> be able to make choices based on them. Examples include choosing the
> data to share, making choices about data retention and having enough
> information to know

to know ... ?

> Attempting to make decisions earlier can be difficult since without
> the context can make a difference.

This isn't a complete thought, perhaps: s/without//

> An example is when the decision involves sharing data with a third
> party who could change.

s/a third/an unspecified third/; s/who/because the party/; s/change/be replaced/

> Examples are the presentation of a "picker" interface to a user for

_Good_ examples. or something.

> selecting contacts fields of potential contacts returned from a find
> operation in the contacts API [CONTACTS-API], or the selection of a
> file in response to HTML5 <input type="file"> markup [HTML5].

> Another similar example is drag and drop in HTML5 where a user clearly
> indicates a desired sharing of information.

s/desired sharing of/desire to share/

> A service provider should have the opportunity to know a user privacy
> decision and respond to it.

I'm actually uncertain that I agree with this point. My experience
with service providers responding to `I won't share` is `fine then, no
cookie for you`.

> Knowing the privacy preferences of a user in a given context, a service
> provider may be able to offer different options.

This might be the wrong approach. If the provider is willing to work
with less information, then it should inform the user in advance so
that the user can decide not to provide something knowing that it
isn't necessary and perhaps how that will affect the outcome.

> As an example, a service provider could remember certain information
> (e.g. shipping address) or require re-entry, depending on the user's
> retention choices.

It should be easy to adjust the preceding two sections to address my
previous comment.

> Minimal user interface interaction should be required with minimal
> consent dialogs

Minimal use of minimal in a sentence should be required :(.

s/interface//
s/with minimal consent dialogs/and the number of consent dialogs
should be minimized/

> Services should be clear and transparent to users regarding potential
> privacy concerns.

`transparent` is probably undefined.

s/transparent/explicit about what they will do with/ -- or something like that
s/potential/data whose existence, capture, or sharing could be deemed to be/

> Clarify where collected information is shared, especially when 3rd
> party services are involved in a "mashup".

There are no RFC words in this statement, there probably should be.

Note that indicating where information is shared isn't helpful if you
don't explain what information is shared individually for each entity.

> Services should be clear as to whether information is needed on a
> one-time basis or is necessary for a period of time and whether data
> retention is required.

And for how long.

> Review the granularity of the data and attempt to provide minimal data

`the data`?

> at the "natural" granularity.

This sentence doesn't really make sense, I think it's missing a
concept or action or context or reason or I dunno.

> As an example, an address book record is not the natural level of

s/record/card/

> granularity

s/granularity/granularity for privacy/

> as a user may wish to share different individual address book fields
> differently.

> Thus the natural level of granularity in an address book is the field

s/book/card/
s/the field/a field/

> and no more than the necessary fields should be returned in an address
> book entry request.

`returned` is an odd word. I think `stored` and `requested` are better
words. There's considerable ambiguity about who's acting to whom for
whom.

Note that the thing missing here is the ability to let the user select
the fields. Having a computer automatically choose to drop fields I
care about just because doesn't make me any happier than it storing
fields I don't want it to store just because it was written to do so.

> As an example, retaining user payment information entails the risk
> of this information being stolen and misused.

> Perhaps it does not need to be retained but if it is (with user
> permission) perhaps it should be encrypted (to give one possible
> countermeasure).

If you're giving suggestions, you should suggest that access be
governed by access controls, logged, and audited...

Received on Wednesday, 27 July 2011 16:33:42 UTC