ACL model
Diana Cheng
After being at ProcessOne in Paris and discussing with developers
Karim Gemayel and Christophe Romain (who are working on an OSW
ejabberd plugin), they suggested that it might be necessary to
simplify the ACL model we currently manage. Their arguments were that:
1) It's complex and not self-explanatory.
2) It will not scale with a large number of users posting a large
number of activities; parsing xml is expensive and moreover, the
current acl-rules require to enter into loops to check for visibility
rules, etc. (I agree).
3) Ideally, an XMPP server should parse as little information as
possible from an activity entry or user profile, to improve efficiency
and make the PubSub service scale.
That said, the current acl model is very xml-pure, well thought out,
and makes good use of namespaces, which might be lost when simplifying
it.
So I was wondering what you guys think of a possible simplification.
For example, in the case of user profiles, an idea would be to move
from:
<fn>
<text>Lord Hamlet</text>
<acl-rule xmlns="http://onesocialweb.org/spec/1.0/">
<acl-action permission="http://onesocialweb.org/spec/1.0/acl/
permission/grant">
http://onesocialweb.org/spec/1.0/acl/action/view
</acl-action>
<acl-subject type="http://onesocialweb.org/spec/1.0/acl/
subject/group">family</acl-subject>
<acl-subject type="http://onesocialweb.org/spec/1.0/acl/
subject/group">friends</acl-subject>
<acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/
person">jul...@capulet.lit</acl-subject>
</acl-rule>
</fn>
to
<fn>
<text>Lord Hamlet</text>
<osw:acl-rule acl-action="view" permission="grant" acl-
group="family friends" acl-person="jul...@capulet.lit" />
</fn>
That would still allow to have more than one ACL-rule per profile
field or activity entry.
Any thoughts on this or flaws you see with this approach?
Cheers!
Diana.
Daniel Renfer
been opened in the past that are related to this issue.
https://groups.google.com/d/topic/onesocialweb/-W-v3MXUauw/discussion
https://groups.google.com/d/topic/onesocialweb/nkO7obAIUF0/discussion
https://groups.google.com/d/topic/onesocialweb/ezVJVJGp1ww/discussion
I'd like to do away with the current naming of the elements from
osw:acl-rule to simply acl:rule where the acl namespace maps to some
new namespace, possibly independent from OSW, but can be if there are
no better options.
As far as ACL and user profiles are concerned... is VCard really the
best way to be transmitting this user information? We would probably
have an easier time extending PoCo or FOAF documents. (or a
combination of the 2)
We need to keep in mind that this problem is not unique to OSW and
over time, the other FSW impls will have to tackle these same
problems. While it's not really that bad designing our own system at
this point (what better way to find out what really works) We will
have to try to interoperate eventually, so it wouldn't hurt to see
what good ideas can be stolen from the other systems out there. Some
of them won't work due to fundamental differences in how the systems
are designed, of course.
I remember it once being stated that ACL rules shouldn't be sent to
other servers. While this is not being done in all place. (or any
places, I'd have to check) it's still a good idea. My groups and
labels should be private to me and not leaked to those I send messages
to. Imagine getting a message in your inbox from a user sending to his
entire "assholes" group. How would you feel about that?
If messages are being routed to inboxes based on their recipients,
then the remote server only really needs to know if that post is
public or private. If it's public, then it's all good. Republish it in
any way you want. Show it to any user that wants to see it, and
publish it to whatever feed / stream you desire.
If the message is private, then it should only be shared with those
that have been explicitly been authed to see it. (those it has been
sent to)
just my $0.03 for now.
@eschnou
I remember it once being stated that ACL rules shouldn't be sent to
other servers.
Daniel E. Renfer
>
>>
>> I remember it once being stated that ACL rules shouldn't be sent to
>> other servers.
>>
> Absolutely correct. The ACL is a pure client-server thing and not part of
> the federation protocol. When shared with another server, one should just
> expose if the post is public or private. This also means that other
> developers can write other servers and clients with other implementations
> without impacting the federation.
Thanks for clearing that up. I was pretty sure that was the original
intention, but ACL info is still being sent to other servers, so I
wasn't sure.
> Now, I'm not sure that simply massaging the XML will solve any of the
> scalability issues you refer to. Isn't this premature optimization ? It
> would be interesting to truly understand where lies the bottleneck and then
> optimize. Is it simply processing the xml ? Translating lists to specific
> users ? Database lookups ? Etc etc...
I agree with you on this one. How the acl information is stored /
indexed will have a much larger impact on performance than the XML/Atom
serialization. If you're parsing every single activity into a dom and
searching for acl info on every single request, then you're doing it
wrong. Simpler XML isn't really going to help you there.
That said, it doesn't hurt to take another look at the current spec to
see where things can be improved.
> One idea already discussed a few times inside the xmpp community was to
> remove acl content from the payload and put it at the pubsub protocol level,
> in combination with a new kind of pubsub nodes allowing for per item
> privacy. There are some threads somewhere discussing this on the xmpp list.
> The benefit would be that servers can safely treat the payload as opaque.
I don't like this idea. So it's going to be up to the server devs to
implement ACL controls for Pubsub? When would Openfire implement that
one? Also, chances are whatever is implemented won't work for some's
business requirements.
What of hybrid HTTP/XMPP applications? Moving the acl info to the pubsub
layer means that the info would either need to be duplicated in the atom
feed, or specialized atom generation routines would need to be used for
the 2 different types.
It's a good idea of itself for other pubsub uses, but I'm doubtful it
would work for general FSW use.
> But I really wonder if this is really important today. In my opinion, a much
> more interesting discussion is about decoupling onesocialweb as a xmpp
> component, enabling one implementation to work against any xmpp server. This
> has been the greatest limit to adoption in the xmpp community so far. This
> is also the approach taken by the buddycloud folks, and aligning with them
> seems a key next step as well.
This is the big one. I'm still conflicted on this one. From a practical
standpoint, the ability to use any OSW/FSW implementation with any XMPP
server is very attractive. From an aesthetic standpoint, it's nice being
able to say: "I am <user>@<domain>. My email address is <user>@<domain>.
My instant messaging id is at <user>@<domain>. If you look up the info
for <domain>, it'll tell you how to plug in <user> to get my web page.
If you want my activity stream, it's on the microblog node for
<user>@<domain>."
Moving that last part to a pubsub node discoverable using that user and
domain name is a minor nit, but it's a feature I'd hate to lose if we
don't have to.
And what of the code? Moving away from PEP would 100% break everything.
Anyway, that's best left as a discussion for another thread.
> And finally, beyond technology, the uttermost priority is simply to get a
> stable, usable, easy to setup, product out soon. Making it super easy for
> others to setup nodes. Otherwise, this project will be dead before it even
> got a chance to fly.
+1
although, even more than that is simply being able to talk to your
friends. We still have a bunch of hilled gardens. All of these social
networks understand that interoperability is a priority and do whatever
they can to have good APIs, but the data is still not flowing freely.
When the point is reached where it doesn't matter what implementation
you're using, then we will really see the numbers rise.
>
> Good luck,
>
> Laurent
>
Melvin Carvalho
> Hi everyone,
>
> After being at ProcessOne in Paris and discussing with developers
> Karim Gemayel and Christophe Romain (who are working on an OSW
> ejabberd plugin), they suggested that it might be necessary to
> simplify the ACL model we currently manage. Their arguments were that:
>
> 1) It's complex and not self-explanatory.
> 2) It will not scale with a large number of users posting a large
> number of activities; parsing xml is expensive and moreover, the
> current acl-rules require to enter into loops to check for visibility
> rules, etc. (I agree).
> 3) Ideally, an XMPP server should parse as little information as
> possible from an activity entry or user profile, to improve efficiency
> and make the PubSub service scale.
>
> That said, the current acl model is very xml-pure, well thought out,
> and makes good use of namespaces, which might be lost when simplifying
> it.
There's lots of ways to do ACL and it can get complex fast. Maybe
relevant reading material:
http://www.w3.org/wiki/WebAccessControl
The philosophy is based on permissions of the UNIX system which has
stood the test of time.
This is probably the seeds of how ACL will at first could be
standardized on The Web.
A long way to go on this front, but from a high level perspective,
would be nice to have similar conceptual solutions across the whole
federated social web
@eschnou
>> I remember it once being stated that ACL rules shouldn't be sent to
>> other servers.
>>
> Absolutely correct. The ACL is a pure client-server thing and not part of
> the federation protocol. When shared with another server, one should just
> expose if the post is public or private. This also means that other
> developers can write other servers and clients with other implementations
> without impacting the federation.Thanks for clearing that up. I was pretty sure that was the original
intention, but ACL info is still being sent to other servers, so I
wasn't sure.
> One idea already discussed a few times inside the xmpp community was to
> remove acl content from the payload and put it at the pubsub protocol level,
> in combination with a new kind of pubsub nodes allowing for per item
> privacy. There are some threads somewhere discussing this on the xmpp list.
> The benefit would be that servers can safely treat the payload as opaque.I don't like this idea. So it's going to be up to the server devs to
implement ACL controls for Pubsub? When would Openfire implement that
one? Also, chances are whatever is implemented won't work for some's
business requirements.
What of hybrid HTTP/XMPP applications? Moving the acl info to the pubsub
layer means that the info would either need to be duplicated in the atom
feed, or specialized atom generation routines would need to be used for
the 2 different types.
> And finally, beyond technology, the uttermost priority is simply to get a
> stable, usable, easy to setup, product out soon. Making it super easy for
> others to setup nodes. Otherwise, this project will be dead before it even
> got a chance to fly.+1
although, even more than that is simply being able to talk to your
friends. We still have a bunch of hilled gardens. All of these social
networks understand that interoperability is a priority and do whatever
they can to have good APIs, but the data is still not flowing freely.
When the point is reached where it doesn't matter what implementation
you're using, then we will really see the numbers rise.
@eschnou
> But I really wonder if this is really important today. In my opinion, a much
> more interesting discussion is about decoupling onesocialweb as a xmpp
> component, enabling one implementation to work against any xmpp server. This
> has been the greatest limit to adoption in the xmpp community so far. This
> is also the approach taken by the buddycloud folks, and aligning with them
> seems a key next step as well.This is the big one. I'm still conflicted on this one. From a practical
standpoint, the ability to use any OSW/FSW implementation with any XMPP
server is very attractive. From an aesthetic standpoint, it's nice being
able to say: "I am <user>@<domain>. My email address is <user>@<domain>.
My instant messaging id is at <user>@<domain>. If you look up the info
for <domain>, it'll tell you how to plug in <user> to get my web page.
If you want my activity stream, it's on the microblog node for
<user>@<domain>."Moving that last part to a pubsub node discoverable using that user and
domain name is a minor nit, but it's a feature I'd hate to lose if we
don't have to.
And what of the code? Moving away from PEP would 100% break everything.
Diana Cheng
Thanks everyone for the comments.
Optimization of ACL-rules is also not currently a priority for me. But
ProcessOne has wanted to build their implementation of OSW as part of
a new release of the ejabberd server, which makes them quite concerned
about scalability issues. So this post was mainly aimed at addressing
the concerns of the ProcessOne guys by getting everyone's view on
this.
Absolutely, it is also pretty clear for me that acl-rules should never
be passed beyond the user's server, besides from potentially passing
whether the activity is public or not (in order to allow for
resharing, for example). I'll put my hands on to get this done
everywhere it should in the code.
Yes, being tied to Openfire has limited adoption, and yes, being tied
to any xmpp server will still limit it, so developing 2, 3, etc.
plugins for different servers won't solve it. But with an external
component you still need to host and run a process to keep a live TCP
connection with the xmpp server. I have seen it's possible to create
external components in PHP and use web hooks/callbacks but even so,
you still need an xmpp server to connect to, i.e you still need to
find an xmpp provider, which is not impossible but also not quite
ubiquitious. So I personally think that even when things will improve
by moving to an external component, this adoption and hosting problem
is inherent to the xmpp protocol, which truth being said, has never
been all that popular. That is the advantage of HTTP-based solutions,
hosting or finding a provider is dead easy.
In terms of interop, I thought it was the whole point of the FSW and
challenges like SWAT. And I think it's a good thing, because it helps
get more attention on to OneSocialWeb, and also helps increase
adoption, because you are able to speak with many others (like those
with an Identi.ca account). Yes, you can prob still break OSW with a
malformed message, although I've done my best to put as many client
side and server side validations. "Given enough eyeballs, all bugs are
shallow". That's why it was so easy to identify security holes in the
alpha release of Diaspora. For better or worse, OSW never got that
kind of attention. And the problem is that there aren't many developer
eyeballs at the moment on OSW, otherwise these bugs would've been
detected and solved by someone already. So if you spot something,
please report it!
In terms of priorities, right now I'm focusing on fixing the payload
to align with the latest Atom and Activity Streams specs, see this
page for an example of what I mean: http://goo.gl/ZTfon . That should
allow for the publisher part of PubSubHubbub to work without others
having problems parsing a OSW feed. And yes, since having a better
feature set and easy deployment is VERY important, I would like to add
other cross-referencing flows such as liking and tagging and explore
how to move everything to an external component (and as pointed out by
Daniel see how this impacts the PEP/PubSub-on-a-jid way of doing
things we currently have).
Hope this helped clarify things and the purpose of initiating this
thread.
Cheers,
Diana.
Daniel Appelquist
On 14 Apr 2011, at 10:16, Diana Cheng wrote:
>
> Absolutely, it is also pretty clear for me that acl-rules should never
> be passed beyond the user's server, besides from potentially passing
> whether the activity is public or not (in order to allow for
> resharing, for example). I'll put my hands on to get this done
> everywhere it should in the code.
>
I am wondering how we reconcile this with the (future) implementation of shared groups (see http://bit.ly/e2XXXY). If we want to enable closed-group messaging and privacy functions across different servers then the privacy metadata that flows with the message has to be richer than "private or not private".
Dan
Renato Iannella
> <fn>
> <text>Lord Hamlet</text>
> <osw:acl-rule acl-action="view" permission="grant" acl-group="family friends" acl-person="jul...@capulet.lit" />
> </fn>
This just seems like an abbreviated version of the first example?
(I was trying to see model changes, but all the constructs are still there, just encoded with less characters ;-)
I agree with the comments that ACL's can get complex quickly.
Best option is agree on your requirements and find an existing solution that could fit first...
Cheers
Renato Iannella
http://renato.iannella.it
Daniel Renfer
some of the reasons you feel that the current spec won't scale well?
It's under-specified, for sure, but chances are, no matter what we do,
we're going to come back to the standard Unix-style ACL pattern.
I really liked the WebAccessControl spec that Melvin linked to, but I
worry about how tightly it's linked to WebId and heavy RDF concepts
like SPARQL. Any SemWeb enthusiast knows just how hard it is to get
people to adopt a RDF stack in their application. I'm also not sure
of the external metadata documents, but that may not be a requirement.
Worth looking at at least, if you haven't yet.
Also, for comparison, here's Buzz:
<buzz:visibility>
<buzz:aclentry type="group">
<poco:id>G:@me:@public</poco:id>
<poco:name>Public</poco:name>
</buzz:aclentry>
</buzz:visibility>
The important thing is that ACL should be extendable. It a post
doesn't have any ACL rules, it's considered public. If there are any
rules, it's private. If the server supports the rules, and those rules
match users, they can see it.
That way, servers can choose to support the simple "public" rule and
everything else will be hidden to them. Discovery could be used to
determine what level of ACL is supported. I have to look for it, but I
seem to remember an old OpenID extension that had something like this.
Diana Cheng
building the erlang-based implementation of OSW for ejabberd. As far
as I understood they were worried about parsing too much xml and going
into loop-inside-loop to check for visibility of many posts. Besides
from being, as said by them, way to complex.
But I think it's best if they explain their views (they are in cc) as
I was just passing the message on.
Cheers,
Diana.
Karim Gemayel
> As I said, this was a concerned raised by the developers at ProcessOne
> building the erlang-based implementation of OSW for ejabberd. As far
> as I understood they were worried about parsing too much xml and going
> into loop-inside-loop to check for visibility of many posts. Besides
> from being, as said by them, way to complex.
>
> But I think it's best if they explain their views (they are in cc) as
> I was just passing the message on.
My suggestion was to put ACL as XML attributes of the element to which
it applies so that it make easier to parse.
Putting the ACL element as the next element to which it applies looks a
bit odd, though.
--
Karim Gemayel
ProcessOne
Diana Cheng
one ACL-rule per field, and the current model allows for more than
one, so it wouldn't map.
How about Christophe? I remember he raised scalability as a pontetial
issue.
As I mentioned in Paris, I do not think ease of parsing is reason
enough to simplify the model :-) But scalability would be, if we
actually end up seeing that it is indeed a bottleneck.
Cheers,
Diana.