Privacy Rewrite GSoC Project

[Sulabh Mahajan]

On Thu, Aug 6, 2009 at 4:04 PM, Ethan Blanton <elb at pidgin.im> wrote:

> Mark Doliner spake unto us the following wisdom:
> > > I believe the plan is that, for the new system, if that list contains
> > > *anything*, whatever is in that list is blocked.  If you don't want to
> > > block any users, don't put anything in that list.  We are explicitly
> > > moving away from protocol-specific semantics, and to a single,
> > > coherent interface which is mapped onto the protocols as needed by the
> > > core and prpls in tandem.
> >
> > I guess that works flawlessly for blocking messages.  There is still
> > ambiguity about whether the blocked buddy will be able to see if
> > you're online.
>
> Yeah, there's a bit of a problem there, because of the conflation of
> subscription/instantaneous visibility/online-ness on various
> protocols.  I suspect it won't always be perfect.
>
> We've discussed having per-buddy invisibility and blocked-ness handled
> as discrete settings, I'm not sure where that stands in the current
> proposal.  I think maybe it went the way of the dodo amidst cries of
> "too complicated".
>

A buddy blocked, doesn't receive our presence. So when you block a buddy, by
choosing "Block All", it automatically selects the sate of "Block All" +
"Block Presence" + "Block Messages" + "Block FT" + etc
In certain protocols, where you can specifically block presence per contact
(yahoo, irc, xmpp?), you can choose to select "Block Presence", if you try
to do that for protocols which do not support this, either we do not let it
be chosen or grey the box, the core would return FALSE, for such a request.

For protocols like IRC, you can only block messages, so choosing "Block All"
or "Block Presence" is greyed/not allowed.

So on..

(I do not know how to grey a certain box in GTK just yet, but shouldn't be
too tough :P, and not allowing to click a box is easy)

In nut shell, each and every setting per contact is not editable, and the
settings shown reflect the actual state.

I suspect users might get confused about why they can't choose a certain
setting, like "Block Presence" for a certain buddy ( eg - for MSN/IRC/AIM
that do not allow per contact presence change), for that we can offer a
notice in tooltip, or just write above the window for "per contact
settings", that "Ability to choose a certain combination of options is
protocol specific"

Another way to do this is, do not provide "Block presence" column (under per
contact settings) for the protocols that do not support it. But, I am not in
favor of this method, since this gives a false belief to the user that his
presence is blocked, which might not be the case (IRC), or doesn't provide
any information about presence (MSN, AIM, etc).

Right now, I just want to prepare a UI that can let me code/test the core,
exact features of the UI can be discussed laters.

Regarding "Allow All", I am in favor of supporting this feature for every
protocol. For protocols like MSN, we can produce a confirmation dialog,
telling user the consequences of the action, asking the user to confirm that
he really wants to choose this option. If we are choosing to implement a
single coherent interface, we should avoid exceptions, and instead figure
out ways to handle the rough edges.

Regarding "Allow following users only", and "Block following users only"
options of AIM, I still think its not too tough on the user to block/unblock
"all others" meta contact. MSN does exactly this very thing. MSN, doesn't
have these two options but depending upon whether you block/unblock "all
others", you actually end up implementing them. If MSN users do not have a
problem with their GUI, I guess our users won't be complaining either.
We can place the "all others" meta contact on the top of contact lists, and
put it in bold letters, that should be sufficient to denote it different
from other contacts.

Regarding ability to change status to be "invisible to all", this is not
directly a part of the privacy system, but since we manage presence settings
(and consider presence a part of privacy), I think we should allow it to be
controlled through the privacy UI. I am in favor of this, since status
change to "invisible to all" effects privacy states / per contact privacy
settings for every protocol.

The system isn't too complex to use, let me prepare the new GUI, and post
screen shots.


Thanks,

-- Sulabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090806/a912286d/attachment.html>