Privacy Rewrite GSoC Project

[Sulabh Mahajan]

On Fri, Aug 7, 2009 at 1:23 AM, Felipe Contreras <felipe.contreras at gmail.com
> wrote:

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


Under current UI, the one similar to what you propose ...

Think about this use-case:
Dude, I feel like chatting, but I normally have too many people
blocked, let's "allow all" in AIM, and hit "remove all" under "block these
only" in MSN.

AIM: protocol supports it, a bit is switched
MSN: 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

Whats the point?
You can have a block list, and offer "remove all", if you can do so, why not
offer "allow all", it does exactly the same. Did any of our users ever
complained about loosing a privacy list because he clicked "remove all" ?

What if I had accidentally clicked "remove all"?
I am not sure, does MSN offer a "remove all", if Yes, how do you recover the
list then.

*Now, I say we offer an "allow all", and issue a warning/confirmation, let
the user know that this and that protocol will loose his server side list,
and will not be recoverable. Not worse than offering a block list with
"remove all". Isn't it ?*

BTW, MSN has both block list and allow list, both active all the time, so
what privacy state are you following, "allow these", or "block these", hmm..
both. By looking for "all others" meta contact in a specific list, and
deciding what privacy state equivalent to AIM's , you are offering
consistency across AIM/MSN while handling how-to stuff in the core. The
native client, doesn't offer any privacy state in MSN. Then what is wrong
with offering consistency across all the protocols.

As I said, it would be more productive to offer me solutions to workaround
the rough edges, and not to reject the design because of a few issues. These
things have been discussed so many times, and it was decided long time back
to offer a unified interface.
It sucks to leave coding, and go back to drawing board every 2-3 days,
because the system we chose is not perfect.


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



Exactly, not possible. But then we are not making them "work" the same way.
We are coding the core to manage them work in their different ways, and
designing a UI to present the "controls" that are as consistent as possible
across all the protocols.

You feel a problem with the interface, because you think in terms of a
certain protocol, and how it handles privacy in its core.
Thinking in terms of a user, I don't care whether you have a block list, or
an allow list, or both, or none, or five privacy states. I want to block a
certain guy, and I want YOU to manage all the list/state stuff, just give a
button I can click to block this guy. Also, if you can't do a certain thing
because a protocol won't let you, like block presence per contact, just let
me know.


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