Privacy Rewrite GSoC Project

[Sulabh Mahajan]

Hello everyone,

I am Sulabh Mahajan, the GSoC student implementing "Privacy Rewrite" this
year. I am the same guy who did the yahoo! project last year. My
college exams just finished, I have some practicals for next 7 days, but I
can extract good amount of time for the project. The project can start, or
rather can't wait to start :-)

So, lets discuss the design issues related to the privacy subsystem. The
current implementation of the privacy system needs to be redesigned from the
scratch. Because of the nature of the work I have done so far for Pidgin, I
am thoroughly aware of yahoo! prpl and bits and pieces of libpurple. I have
never done the designing part, so to be able to come up with a great design,
I would need the help of the experienced developers.

Let us use this thread to discuss the design issues.

Please go through these links:
    Protocol specific privacy features:
http://developer.pidgin.im/wiki/GSoC2009/PrivacyRewrite/protocol_specific
    The initial design idea:
http://developer.pidgin.im/wiki/GSoC2009/PrivacyRewrite/initial_proposal

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?
   - 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.).
   - 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.
   - 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.
   - 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?
   - What about signalling, what signals the privacy subsystem would want to
   emit?
   - 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?
   - 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.

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.


Sulabh Mahajan,

Project: Privacy Rewrite
Mentor: Ethan Blanton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090525/b2cf0cc7/attachment-0001.html>