social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social-discuss] Control own privacy, posted by _others_


From: Rob Myers
Subject: Re: [Social-discuss] Control own privacy, posted by _others_
Date: Tue, 06 Apr 2010 05:53:12 -0400
User-agent: RoundCube Webmail/0.3-RC1

On Tue, 06 Apr 2010 00:05:32 -0400, Ian Denhardt <address@hidden>
wrote:
> 
> Here's the problem I see with this: I'm running a gnu social instance on

> my own server, quite literally a PC sitting under my bed. How do you 
> justify saying I can't make your name, as it appears on my website, 
> running on my hardware, a link to anywhere I please? Supposing I don't 
> have an instance of GNU Social, I just have a website. should I not be 
> allowed to manually link to various people, who may or may not want me 
> to do so? It's possible it would be impolite of me, but ultimately 
> there's a free speech issue there.
> 
> I'm not arguing privacy isn't important, but there's a conflict. 
> Certainly we need access controls so that I can control who can access 
> what on my profile, But it feels a bit draconian for you to be able to 
> have access controls that determine what I can post on my website. I 
> don't think I would run the software at all if it allowed for this, or 
> since it is free software, I would simply remove the functionality.

Certainly everyone should control their own computing resources and their
own running software. This is a free software project. And people will
simply modify the software to work around any restrictions we might be
tempted to add.

But we do need to recognise this conflict and do what we can in the
software to address it.


Possible solutions:

1. Have "anti-tags" that the software respects by default. Or would that
end up being a source of hilarity like Outlook message recall emails to
mailing lists? They would making searching for embarrassments easier than
simply leaving the original tag unchallenged.

2. Allow people to ignore tags from other instances on their instance, and
to not propagate those tags to other instances.

3. Require that tags are confirmed, and simply leave tags unconfirmed on
the other instance if the tagged user declines to confirm them. This avoids
the embarrassment flagging problem of 1.

- Rob.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]