Perspectives Technical Documentation

From the above, some obvious security concerns follow. We’ve identified the following:

The local user account secrets are accessible to anyone with (enough) access to the device and with enough knowledge to access the IndexedDB database 'localusers' for the https://mycontexts.com domain. In other words, a users' data is as secure as his own device. Once an attacker can log in to MyContexts, he can impersonate the user, and can steal his data.
An agent might try to inject Transactions into a message queue, targeting a specific user, impersonating another. This requires the message queue address of that user and the secret key of the impersonated user, to sign the Transaction. Encryption is used for authentication purposes.

Note that even if an agent would successfully impersonate someone’s peer, they still can only change a persons' data in accordance with the modelled authorisations of that peer (an attacker cannot assume more authorized privileges, since the receiving peer himself compares the privileges he has stored with those claimed by the attacker).
An agent with access to the device running the private Couchdb installation might manipulate its data. This would require the users' credentials for Couchdb or it would require him to set up and admin account on the Couchdb (which is as hard as Couchdb makes it, after the first Admin account has been established).
The window.postMessage method might be vulnerable in the sense that processes running in other domains can intercept or even manipulate messages going between the screens and the PDR.