[sugar] Privately-owned data on XOs?
Samuel Klein
meta.sj at gmail.com
Fri Aug 24 19:41:02 EDT 2007
On 8/24/07, Eben Eliason <eben.eliason at gmail.com> wrote:
> I understood this problem to be solved already. We have the notion of
> sharing, and more specifically of scoping (with groups). If I write a story
> by myself, then it's private unless I explicitly say otherwise. If I draw a
> painting in an activity shared with the mesh, then I've already agreed that
> everyone should be able to see it. If I work on project with my study
> group, than likely that will have a "my study group" scope, and thus be
> available for anyone in my group to look at.
I think we have lumped together "hints as to who is working on this
right now / who should see this in their mesh view", "permissions to
write to this item right now" and "permissions to read this", to the
detriment of transparent collaboration.
We should clarify this in the UI, and at the very least allow
individuals to set preferences for the default behavior under a
variety of circumstances. I would be interested to see the
comparative development of sharing in communities given different
defaults (and suitable explanations of what their default settings
are).
> We already have the notion of sharing and group scoping for privacy, so why
> wouldn't that determine the default scope of who can view what? This is a
> reasonable default that doesn't reduce privacy but is not strictly
> non-public.
We need to clarify and visualize the difference between privacy-scope,
current-sharing-scope, write-permission and read-permission scopes.
(Write-permission may not make any sense outside of immediate
synchronous collaboration.)
Among the reasons not to overemphasize privacy in a collaborative
environment: it is extremely hard to preserve. Group permissions in
particular are often illusions. If I set my preferences to make
anything I collaborate on public to all, it doesn't matter that my 3
friends want group-collab activities to have 'group' permissions; the
resulting work is public. If you try to design DRM that keeps people
from sharing work created in a limited context, things get
increasingly hairy.
SJ
More information about the Sugar
mailing list