Privacy Rewrite GSoC Project

[John Bailey]

Sulabh Mahajan wrote:
> There are several issues that need to be discussed, like:
> 
>     * What are the current requirements of the privacy subsystem apart
>       from being able to support the privacy features provided by the
>       protocols, and display them in a non confusing manner?

It would be nice if we could make it possible to fake options not supported by
protocols.  For example, if I use a protocol that doesn't support allowing only
people on the buddy list to contact me, we should emulate it (working within the
protocol's toolset wherever possible).  I know there are at least a couple
developers against this, but the argument in favor of it is that we'd be
providing consistency such that our users don't need to care about protocols as
far as the privacy settings are concerned.

>     * Ethan suggested we should keep in mind that libpurple is used by
>       several UIs other than Pidgin. Our design shouldn't be Pidgin
>       specific. What do non-Pidgin-style users of libpurple need that
>       the current situation doesn't provide, and what are their
>       requirements for a new API? (specifically, telepathy -- but also
>       Meebo, the XMPP transport, etc.).

Adium's input would be particularly helpful here as well.  I believe they are
currently working around our current limitations, but that's better for them to
explain.

>     * How far do we want to unify the outer interface to protocol
>       privacy, and do we want to "paper over" functionality differences?
>       For instance IRC provides no privacy support, everything has to be
>       done client side. Similarly for some protocols, a few additional
>       features might be supported above the ones provided. Should we
>       implement such features?  I am in favour of implementing at least
>       those features that we can do without passing anything unusual to
>       the server.

As I said above, I'm definitely in favor of this.  If we need to just silently
drop messages to achieve functionality, we could do so.

>     * A related issue is, what if a function can be handled both client
>       and server side, like rejecting a file transfer to a blocked user,
>       should we let the server decide it for us, or should we always let
>       the privacy subsystem handle the case? I am in favour of letting
>       privacy system drop all the requests, and not pass it to the
>       server, helps simplify the system.

I would say apply the settings from the server at login, like we do with AIM for
a bunch of stuff, then push updates to the server.  It might make the task more
difficult, but it will help us play nice with our users who switch clients.

>     * What about the privacy issues with
>       conference/chat/multi-user-chat/etc? How should we handle the
>       multiple user environment, when each protocol differs in the way
>       it handles this issue?

I'm not sure of a good mechanism to handle this within MUC's.

>     * What about signalling, what signals the privacy subsystem would
>       want to emit?

We should probably have signals to indicate when a buddy has been blocked or
unblocked, when a chat user has been ignored or unignored, and possibly one to
indicate that we dropped a message (and send the message text to the callback so
plugins and other UI's can do stuff with the message if desired).  Additional
opinions from the authors of other UI's would be helpful here.

>     * What about privacy issues related to xmpp? Do we support XEP-0191
>       ? What about sending presence notifications (invisibility?). How
>       is the privacy handled differently in gtalk compared to xmpp?

There is some XEP-0191 support in the current im.pidgin.pidgin.  Paul and Mark
can probably explain better.

>     * Also, while coding the subsystem, I would like to use one (or two)
>       protocols initially to test. What that protocol(s) should be? I
>       am most familiar with the yahoo!, and would naturally want to use
>       it, but yahoo! is very simple in privacy concerns and won't
>       provide me with enough testing scenarios. XMPP is naturally the
>       second choice for being well documented, but the
>       privacy extensions are too complex, and I am not sure which one
>       Pidgin implements, and if that implementation is complete or not.

My current understanding is that, next to XMPP, MSN has the most complex
protocol-level privacy capabilities of all the protocols we support.  There are
several privacy-related lists that need to be carefully and properly managed.
Ka-Hing and Elliott should feel free to correct me if I'm wrong, though.

> What are the other design issues? There must have been discussions on
> privacy hundreds of times, I am sure everyone has lots of ideas. I would
> be grateful, if you can share those ideas with me. I request developers
> to come up with more questions and issues related to privacy, so we can
> have discussions and finalize a design.

I would say that we need to account for Yahoo's "Appear Permanently Offline"
functionality in this design too, so that any other protocols that have similar
support can take advantage of existing support within libpurple instead of
needing to reinvent the wheel or work around our limitations.

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/20090529/8b25c444/attachment.sig>