Privacy Rewrite GSoC Project

Felipe Contreras felipe.contreras at gmail.com
Thu Aug 6 15:53:54 EDT 2009


On Thu, Aug 6, 2009 at 2:25 PM, Sulabh Mahajan<sulabh.dev at gmail.com> wrote:
>
>
> 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..

As I explained before, such granularity is impossible in MSN; it's
either blocked, or allowed. How are you going to represent that
visually? And what happens when you have a meta-contact with MSN and
IRC contacts? In which cases are you going to show a "blocked" icon in
the contact list?

I simply don't see how this can work. Why don't we keep it simple and
allow two states: blocked, and allowed. Presence visibility and
reciprocity is an entirely different thing.

> 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.

Think about this use-case:
Dude, I feel like chatting, but I normally have too many people
blocked, let's "allow all"

AIM: protocol supports it, a bit is switched
MSN: protocol doesn't support it, all contacts are manually unblocked

Hmm, I'm back to my usual busy status, I want my usually blocked
people to be blocked again

AIM: protocol supports it, a bit is switched
MSN: protocol doesn't support it, you are screwed

You want all of the protocols to work the same? Sorry, that's just not possible.

> 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.

Every UI designer will tell you that the UI must change as little as
possible. The best way to do that is to have privacy settings per
account, and the UI should be like this:

Permission setting <- drop-down: deny others, permit others, deny all,
permit all, permit buddy list

--------------------------------------------------
| blocked users | allowed users | others         |
--------------------------------------------------
| foo at bar.com   | meh at bar.com   | chilli at bar.com |
--------------------------------------------------

The permission setting drop-down should show only the options
supported by the protocol. And depending on the selection is when the
table below should be greyed or not.

This is the simplest solution that fixes the issue with MSN privacy
stuff. All other proposals I've heard are only introducing problems
rather than solving them.

Cheers.

-- 
Felipe Contreras




More information about the Devel mailing list