Privacy Rewrite GSoC Project

[Felipe Contreras]

On Wed, Jul 22, 2009 at 3:48 AM, John Bailey<rekkanoryo at rekkanoryo.org> wrote:
> Ethan Blanton wrote:
>> Felipe Contreras spake unto us the following wisdom:
>>> MSN supports "Allow users below" and "Block users below", so you
>>> should show only those options.
>>
>> Many developers have expressed a desire to unify the privacy interface
>> across all protocols, such that we have only ONE privacy model, and it
>> is implemented in each protocol as necessary.  I don't think this
>> point is on the table any more.  Someone can correct me if they
>> disagree.
>
> Yes, we should be presenting a unified privacy interface.  The purpose of
> libpurple is to abstract away the differences in the protocols as best it can,
> and unifying privacy is one way to improve this.

If you present a unified privacy interface, then the privacy settings
for some protocols will become nonsense.

In MSN you don't cannot have FT without IM, chat = IM, and you cannot
chat with somebody you cannot see online, nor send message to somebody
who has you blocked.

In short: blocked means completely blocked. You are going to make the
same mistake again: present privacy settings that are not feasible in
MSN, and thus, confuse the user.

>>> There's already a way to block file transfers: click on the "Cancel"
>>> button when you receive one.
>>
>> This is non-sensical -- that isn't blocking file transfers, that's
>> requiring the user to deal with each file transfer independently. And,
>> yes, we do have users who ask to have *all* file transfers, chat
>> invitations, and subscription requests blocked.
>>
>>>  And why would you want to block file transfers but not chats? And why
>>>  would you want to block chats, but not block the user?
>>
>> These questions, I cannot answer.  It may be that it is sufficient to
>> have "Block everything but messages".
>
> Let's provide a practical example here.  Let's say I have users A, B, and C on
> my buddy list.  User C is fine in one-to-one IM and I have a legitimate need to
> transfer files with him, but I can't tolerate his behavior in multiuser chat.
> Thus, I may decide I want to ignore any chat request from him but allow IM and
> file transfer.  Now with user B, I don't want anything to with files he sends me
> but don't care about IM or MUC.  Obviously in this case I want to block file
> transfers but nothing else.  And in the case of user A, I want to allow everything.

That's not practical, that's hypothetical. I bet you don't have a user
B, nor C in your buddy list, and I haven't heard of anyone who has
such needs.

> You may not agree with this scenario, but I guarantee it *will* happen, and it's
> a valid use case to be prepared for.

I disagree, if it happens, it will be for a very few users. So you'll
add options for a few, to the detriment of the grand majority. Is
there a bug report asking for such feature, how many votes does it
have? Not only will you complicate the API and UI with such settings,
some protocols cannot honor such granularity, so you are making the
same mistake again. The original purpose of the privacy rewrite was to
present to the user realistic privacy settings; something that
actually has the expected behavior in the protocol used.

How about we concentrate on real problems instead of hypothetical ones?

-- 
Felipe Contreras