Re: TAG on privacy by design for web applications

(some cc's removed)

On Sun, Apr 29, 2012 at 7:18 PM, Larry Masinter <masinter@adobe.com> wrote:
> Hi Thomas,
>
> I know (and knew) the draft minutes are public, and are posted to a public list.  I was having trouble reasoning about "privacy" as an abstract, and thought it would be useful to discuss a situation where I cared about the result.

I like this as a use case, too.

One 'architectural' principle around privacy is that if information is
received with a policy attached, such as "don't quote out of context",
then it is a good idea to make policy attachment itself be part of the
policy and its supporting infrastructure, since if the policy ever
gets detached from the data, one might experience "privilege
escalation". That is, data use policies should be contagious, if there
is any chance the receiving agent might retransmit the data (or
information derived from it).

The most reliable way to "attach" a policy to data is "manifestly" at
the level of data structure, message or document format, or API level
(these are all equivalent). That is, put it in the receiving agent's
face. Then if the receiving agent wants to discover the policy bearing
on the data (as it might be motivated to, by, say, statute) then it
has its hands on the policy and can just look at it. The fact that the
policy is "in its face" makes it harder to ignore. There are other
ways to "attach" policy to data. E.g. if a program is known to satisfy
a policy by virtue of its internal logic, there is no need to make the
policy manifest at the data structure level (API, etc.). The policy is
"attached" by virtue of its being observed within a context. Of course
if the data is passed out of such a scope on to an agent, such as a
person, that is not known to observe or be aware of the policy, then
the policy should become manifest again at that point.

Agents might have either of two distinct attitudes toward policies. If
an agent is predisposed to think that no data use is permitted in the
absence of a policy statement permitting it, the agent will want to
discover the policy as a way to get permission to use the data, since
otherwise it will have to just discard the data. Other agents might
have the attitude that in the absence of a known policy the default is
that any use is to be permitted. In this case putting the policy "in
its face" (manifest) has a chance of having the desired effect of
motivating the agent to avoid use that is contrary to policy
(especially if the data form, document format, API, etc. says that
policies must be respected), while erasing the policy or leaving it
implicit is a recipe for disaster.

In the case of our TAG minutes example, the above considerations would
argue for the addition of a contagion clause to the "policy" added to
the draft by the perl script, i.e. an additional request that the
policy (including the contagion clause) be replicated along with any
copy of the data (or part of the data, or "derived" data, etc.).
Without this, agent 2 can adhere to the letter of the policy, but not
reproduce the policy itself; agent 3 on receiving the data then
doesn't see any attached policy, and might assume a default policy
that any use is permitted. That would not be good.

(Ack: Joe Pato.)

Jonathan

Received on Wednesday, 9 May 2012 14:26:17 UTC