[Fwd: dashboard privacy issues]

[Nat Friedman <nat ximian com>]

These are interesting points, especially with regards to the backends
that hit the network (Google, Amazon, etc.).

--- Begin Message ---

• From: marius aamodt eriksen <marius monkey org>
• To: nat nat org
• Cc: jose monkey org, provos citi umich edu
• Subject: dashboard privacy issues
• Date: Sun, 20 Jul 2003 11:01:25 -0400

hi - awesome work on the dashboard.  have you given any thoughts to
privacy issues with the dashboard yet?  for example with the gtk input
frontend, if i type in my credit card number somewhere i don't want
dashboard to try to interpret it as an isbn number and try to look it
up on amazon, for example.  of course, you can imagine the endless
examples.  perhaps a distinction should be made with backends which
reference "internal" and "external" data?  perhaps creating filters
which will only allow very sanitized and specific (perhaps even
following a specific syntax) cluepackets being sent to frontends which
reference "external" data?

any thoughts?

marius.

-- 
> marius monkey org > http://monkey.org/~marius

--- End Message ---

--- Begin Message ---

• From: marius aamodt eriksen <marius monkey org>
• To: Nat Friedman <nat nat org>
• Cc: jose monkey org, provos citi umich edu
• Subject: Re: dashboard privacy issues
• Date: Sun, 20 Jul 2003 17:55:36 -0400

* Nat Friedman <nat nat org> [030720 17:37]:

> Very interesting point.  We haven't thought about this much, beyond
> making the gtk typing frontend not send password-dialog text.
> 
> I'd love to hear some thoughts about this; how can you tell when data is
> private?

any solution would necessarily be heuristic, unless applications are
designed for the user to mark which data is private and which is not.

one simple, but probably effective heuristic would be to apply a
policy in which every application in which you are already submitting
information "publically" (irc/aim (unless you are using encryption
plugins), etc.) are OK with referencing external data.  whereas
applications that read and write local files are not OK with
referencing external data.  a blacklist or whitelist (containing
applications) approach would probably be quite an effective start.

another approach would be to apply strict filters on cluepackets sent
to frontends that reference external data.  this is probably much
harder, though.  for example: it's probably OK to reference any URLs,
since they will be browsed anyway.

also, maybe tagging onto the cluepacket the location (URL?) from which
the data is collected.  for example file://u/marius/public/* would be
OK with being queried but file://u/marius/loveletters/* would not.  so
simple policies could be composed, perhaps even interactively like in
systrace[1].  http://* would be ok, but not https://*

thoughts?

marius.

[1] http://www.citi.umich.edu/u/provos/systrace

-- 
> marius monkey org > http://monkey.org/~marius

--- End Message ---