Privacy Rewrite GSoC Project

[Felipe Contreras]

On Mon, Jul 13, 2009 at 8:20 PM, Sulabh Mahajan<sulabh.dev at gmail.com> wrote:
> Hey guys,
>
> So what method I have adopted is that, I am storing all the privacy
> information in the blist itself.
> Now we have a list of buddies and list of other contacts, with block
> message, block presence, and information being local only as flags to the
> buddy.
>
> To store contacts not on the buddy list, we have a group specifically
> assigned, I have for the time being named this group _Privacy.
> I modified the code in blist.c so that public API remains the same, and
> buddies from _Privacy aren't referenced when we call functions like
> purple_find_buddy().
>
> Right now, I use the name "_Privacy" to differentiate it from the other
> groups, rather than any flag, I have used the name itself. Also, to
> differentiate buddies in the buddy list from the contacts in privacy list, I
> check whether this contact/buddy rests in _Privacy or not. I again haven't
> used any flag here.
>
> Ethan has the following view over the issue:
>
> " I think it would be better to flag the group as private in some way, such
> that its namespace does not interfere with public groups. Perhaps you should
> bring this up on devel@ and see what others think. I dislike magic names,
> and I suspect that hidden groups may have other uses. "
>
> So help me with this:
>
>  How should I differentiate the hidden group _Privacy from other groups. I
> think a flag to denote the group hidden should be fine.
>  How should I name the group (currently named "_Privacy"), so that there is
> minimum conflict with the names of the groups created by the users.
>
> Another issue that needs to be talked is, should we move away from the way
> we handle privacy states, where we present the user with options like allow
> all, allow users on buddy list, block all, block users below, allow users
> below. Should we keep following this interface and fake those states which
> the protocol doesn't provide, or should we scrap it and redesign a new
> interface, that allows us to tune features beyond that can be provided by
> the older interface.
>
> Ethan has to say the following over this topic:
>
> "I think that we all agree that we want to move away from the "Allow all
> below", "Block all below", etc. etc. to something more coherent. I have been
> thinking something like:
>
> [ ] Block messages from all users not on my buddy list
>
> [ ] Block {chat invitations, subscription requests, etc.} from all users not
> on my buddy list
>
> [ ] Allow users who are not on my list to see my presence
>
> etc.
>
> Per-buddy settings
> +------------------+---------+--------------+-------------------------+
> | Buddy name       | Block   | Block Chat   | Block File Transfer     |
> +------------------+---------+--------------+-------------------------+
> | Ethan Blanton    |         | X            | X                       |
> | Sulabh Mahajan   |         |              | X                       |
> | Richard Stallman | X       | -            | -                       |
> +------------------+---------+--------------+-------------------------+
>
> (This final table would almost certainly have more columns.)
>
> The settings applied to each prpl, specifically, would then be computed from
> the union of all of these settings. The user should not have to know that a
> particular protocol is set to "Allow only listed", with the items of the
> list being the buddy list. We should hide all of that from them.  As you
> suggest, we should then "clean up" anything that the protocol itself cannot
> handle with local policy.
>
> There does remain a question of what to do about, for example, protocols
> which simply have no "invisible" type state, or cannot block subscription
> information; we should probably discuss this as a group. "
>
> So please present you views over these issues.

MSN allows only two options:
 * Allow only users below
 * Block only users below

When a user is blocked he cannot chat with you, send you files, or do
anything, there is no need for another level of security. However, the
msn prpl is badly implemented so it opens the gates for messages (this
doesn't happen in msn-pecan).

If you want to implement another level of security (which I think is
redundant) it should be done on buddies that are already blocked on
the msn level; "Block all below" doesn't make any sense from MSN point
of view.


I am curious as exactly what you mean by the information is stored in
the blist itself. I think you should have a way to identify the
permissions of a contact per-account ("foo.bar at hotmail.com" in Account
A), and right now I don't see any structure that can do that:
PurpleBuddy would have many instances of the same contact
("foo.bar at hotmail.com") per account, and PurpleContact would have
buddies for other accounts.

IMHO you should have your own structure, and your own list of those
structures. For example there would be one PurpleDude for
"foo.bar at hotmail.com" in Account A, and it would contain all the
privacy information, even if he is on your buddy list.

Cheers.

-- 
Felipe Contreras