Privacy Rewrite GSoC Project

[John Bailey]

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.

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

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

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20090721/df57d014/attachment.sig>