On Feb 26, 3:24 am, Tad Glines <[email protected]> wrote: > there is no way to explicitly enforce access > control policies in a TP2 environment when the servers are owned and > operated by separate entities.
You appear to assume that a server necessarily trusts another server, and go on to conclude multiple servers aren't a good idea in general. Hence your subject heading for the thread which is an unqualified rejection of TP2. Below is my current thinking on how security can work in a peer-peer system using TP2. Note that I'm using terms like peer, client and server in a general sense - i.e. for any system that may utilise OT (not just a system using the Wave Protocol). Read access If confidential data should only be read-accessed by trusted users then obviously a "server" machine must constrain what data (and operations on that data) can be sent to what peer. It is never permissible to send confidential data to a peer that is not trusted. Whether a peer is regarded as another "server" or a "thick client" or just a "thin client" is immaterial. Note that a peer may not be trusted only because it is not known to implement the minimum security checking required. Trust is a transitive relation, therefore if B trusts C and A doesn't trust C, then A cannot trust B either. Write access If data is not at all confidential, but a "server" machine nevertheless wants to constrain who is allowed to make changes to its local copy of the data, then that is easily achieved according to whether edits received from a peer are allowed to be applied to the local copy of the data. Under TP2 this works beautifully because there is no need for global agreement on who can make changes to what machine. Instead each machine can independently define its own rules for write access and this is enforced in the communication layer. When users disagree they can "branch" their local copies of the data - as indeed happens analogously on open source projects where disagreements cause the development effort to splinter into factions. When OT supports TP2 it fully accommodates divergence and convergence of data, so it's not surprising that it offers the ultimate solution to complex write access policies. Integrity There are a number of ways in which a malicious machine could attack a system, trying to break its integrity. For example a malicious machine could issue valid operations that randomly add and delete content. Since the operations are valid, technically this doesn't break system integrity. In practise it can be just as bad. A machine can protect itself from that form of attack by preventing edits that are received (directly or indirectly) from non-trustworthy peers from being applied (i.e. as per the section on write access). This is regardless of whether the system utilises TP2. Alternatively a machine could try to issue invalid operations (e.g. that cause out of bounds check failures, use incorrect sequence numbers, incorrectly apply OT algorithms etc). A machine can protect *itself* from that form of attack by fully validating all received operations before they are applied. It is always possible in principle for a machine to protect the integrity of its local database in this way (even in a true peer-peer system using TP2). -- 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.
