Privacy Rewrite GSoC Project

[Felipe Contreras]

On Fri, Aug 7, 2009 at 1:29 PM, Sulabh Mahajan<sulabh.dev at gmail.com> wrote:
>
> 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" ?

People do complain about these settings because they don't do the
expected thing currently:
allow all -> deny users
block all -> permit users

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

You should not offer "remove all" nor "allow all", the protocol
doesn't support that, and there's no reliable way you can support that
in any client.

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

The native client doesn't offer any privacy state in MSN? Have you
read about the BLP command? Maybe we are not talking about the same
thing.

You cannot offer consistency across all the protocols. You can try,
and you will fail.

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

I don't recall agreeing to a unified interface, perhaps the "official"
pidgin developers did. However, I was the last person to spend a
considerable amount of time designing the privacy stuff, I gave up
because KingAnt rejected my idea of a PurpleDude, that for some reason
now he likes, but forgot it was mine. So considering that I was right
back then, and that nobody else has spent so much time working on
this, I would think that you should consider my opinion seriously.

I already offered you a solution; it's clean, simple, and it will
work. All you need to do is implement it.

But apparently nobody backs the idea (maybe they'll do in 5 years). In
theory you should ignore me and implement the "decided" unified
interface. But I am being honest with you, I am certain if you follow
that way, the result will be total failure. I am not being
counter-productive since I am telling you exactly what I think should
be done.

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

When you click a check box and the endresult is nothing, you have
designed something wrong. And that's what will happen with your design
in MSN.

The UI should abstract the features of each protocol, but allow *all*
the functionality, and make visible to the user what *exactly* is
happening behind the curtains.

-- 
Felipe Contreras