TiddlySpace presents a security model that is unashamedly oriented towards web scale public discourse. The primitive mechanisms by which this is achieved are:
This design is not directly suited for common "extranet" scenarios where information needs to be published to a private audience. Using space membership and private tiddlers is almost adequate, but not quite:
These issues could be resolved by changing the TiddlySpace security model established above, for instance to allow for additional levels of privacy beyond private and public. However, I believe that a simple extension of the model suffices to cover many of the common extranet scenarios:
Note that the distinction is made at the level of a server rather than a space. The implication is that a separate server has to be created for each publishing group. Most of the time, this would mean having a separate virtual server for each distinct extranet client organisation, with individual user accounts within each one.
This proposal could lead to an unmanageable profusion of servers. But for the scenarios where it is practical it strikes a good balance between unusably fiddly fine degrees of control, and something simple enough to be practical. In particular, it is simple and logical for users that have learned how to read URLs properly.
- Spaces contain tiddlers that can either be public or private
- Only the members of spaces can see the private tiddlers
- Space inclusion works with public tiddlers
- Users can only create or modify content in spaces in which they are a member
This design is not directly suited for common "extranet" scenarios where information needs to be published to a private audience. Using space membership and private tiddlers is almost adequate, but not quite:
- The same privilege (space membership) is used to confer the ability to modify content as well as just to read it, making it impossible to grant someone access to read private information without also giving them the right to modify it
- The private content cannot be included into other spaces, making it impossible to create derived works
These issues could be resolved by changing the TiddlySpace security model established above, for instance to allow for additional levels of privacy beyond private and public. However, I believe that a simple extension of the model suffices to cover many of the common extranet scenarios:
- Spaces reside on servers (which may be virtual)
- Public servers allow anonymous guests to see public content within their spaces
- Protected servers require users to have an account in order to see their spaces and the public content within them
Note that the distinction is made at the level of a server rather than a space. The implication is that a separate server has to be created for each publishing group. Most of the time, this would mean having a separate virtual server for each distinct extranet client organisation, with individual user accounts within each one.
This proposal could lead to an unmanageable profusion of servers. But for the scenarios where it is practical it strikes a good balance between unusably fiddly fine degrees of control, and something simple enough to be practical. In particular, it is simple and logical for users that have learned how to read URLs properly.