Thanks for re-posting. I have some comments below. On 3 December 2010 13:01, x00 <[email protected]> wrote:
> I posted this idea long ago, but perhaps not many people got what I > was on about. I have a tendency to be long winded so I will try to > keep this succinct as possible. > > The main motivation is that fact is you don't now what use cases are > going to appear in the future. You are not going to be able to please > everyone with set in stone permissions, roles, groups, etc. Also there > is is strong expectation within a user base, of a specific use case > for things to work a certain way. In other word wave agnostic. I'm not convinced that pleasing everyone is a goal at all, but setting that aside I do agree it is valuable to have a simple core model that is agnostic about many application details. At least the policies that access control might enforce, if not the mechanism itself, belong outside this core. > Also > there is admission that the current permission proposal they are not > worry about how they are going to federate it (which I think is > repeating the mistakes of the past) > Just FYI one of the reasons Google Wave never implemented a more sophisticated access control model than the simple "roles document" per-wavelet thing we did was because we were acutely aware that it needed to federate. The basic roles model we implemented does federate. Indeed, any model built on top of wave itself federates fairly naturally, while any system that adds new primitives needs additional thought. I haven't worked out yet whether it's feasible to implement a decent system without adding more primitive data types, but that's a discussion for another thread. > > My idea is for the creator of a wave to add one "public via proxy" > group/permission (which can be a condition of publication). > > This allows all the participant interaction to moderated through that > proxy. Effectivly providing access controll on other interaction > control fefac to without needing predefined roles. It is is not after > the fact like a robot but before. > > How is is federated? When you federate there is a trust relationship. > mailserver are no different. if they abuse that trust then you don't > deal with them. It is as much as a problem as dealing with > individuals. So therefore the proxy could be in the form of > distributed agent code sent to each service. > > Distributed agent code is another idea I have which deserved its own > post. However basics: browser use distributed agent code in a > sandboxed environment it is called client code or javascript/ > ECMAScript (which is the obvious choice). The Caja doodad in effect > provides distributed gent code to the client interface, albient in a > non elegant way. In theory providing distributed agent capabilities > such as spelly or rosie, with performance robots couldn't compete > with. This would be federate simply by virtue of begin included in the > doc, and of course requiring an uptake of the feature. You can also > have distributed agent code sent to the server itself. the proxy is a > special case of this type of agent code. > So if I understand this correctly, a "proxy" is a piece of code (rather than, say, a physical machine). The proxy code can be run by clients, presumably for optimistic enforcement, and also by servers for actual enforcement. The code is actually distributed to servers and systems need to trust each other to correctly run the proxy code for wavelets hosted there. Running procedural code (say ECMAScript) provided by unknown third parties is generally something system administrators flat-out refuse to do, and with good reason. It's a huge security risk. Systems like Google AppEngine and other application hosting providers do it, but only with highly sophisticated sandboxing techniques. I'm not sure it's feasible or would be widely accepted as a means of providing Wave access control. A declarative language for access control would be easier to stomach. Such a system would probably be far less powerful but then far better suited to the purpose. In our previous investigations it proved quite difficult to describe an appropriate set of primitives that such a language might talk about (I'm rising out of the implementation detail now into trying to describe just what policies the access control might enforce). Given Wave's concurrent nature the only place to safely evaluate access control for any delta is under the wavelet lock deep in the wave server while applying said delta. But deep in the waveserver is precisely where we try to minimise complexity and remove application-level concerns. So on the one hand we want to be able to express application-level policies like "user can only edit their own blips" and on the other hand the wave server core doesn't even know what a blip is. Anyway, I'm getting a bit off your topic... Given such a language, one easy way to federate it is to simply write the access control descriptions into a document in the wave they control. The same would work for a more powerful language, but the potential for abuse is large and sysadmins will be wary. I don't think running arbitrary code is on the same trust level as just not sending spam. I do like the general idea of distributed agent code for client-side things though. It always seemed like a bit of overkill that you had to write a robot in order to turn emoticons into images, something that could easily be done by a user's client. Unfortunately some technical issues of the event models in Google Wave's clients and servers meant that we never realised that goal. The same issues still exist in WIAB, but maybe we can work to resolve them in the future. Alex > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
