forked from indymedia/epicyon
Note about ocap enforcement
parent
b9ebf425b1
commit
5693f0fda1
|
@ -128,6 +128,8 @@ When posts are subsequently sent from the following instance (server-to-server)
|
||||||
|
|
||||||
Subsequently **Bob** could change the stored capabilities for **Alice** in their database, giving the new object a different id. This could be sent back to **Alice**, perhaps as another **follow Accept** activity with attached capabilities. This could then change the way in which **Alice** can interact with **Bob**, for example by adding or removing the ability to like or reply to posts.
|
Subsequently **Bob** could change the stored capabilities for **Alice** in their database, giving the new object a different id. This could be sent back to **Alice**, perhaps as another **follow Accept** activity with attached capabilities. This could then change the way in which **Alice** can interact with **Bob**, for example by adding or removing the ability to like or reply to posts.
|
||||||
|
|
||||||
|
Object capabilities can be strictly enforced by adding the **--ocap** option when running the daemon. The only activities which it is not enforced upon are **Follow** and **Accept**. Anyone can create a follow request or accept updated capabilities.
|
||||||
|
|
||||||
## Object capabilities adversaries
|
## Object capabilities adversaries
|
||||||
|
|
||||||
If **Eve** subsequently learns what the capabilities id is for **Alice** by somehow intercepting the traffic (eg. suppose she works for *Eveflare*) then she can't gain the capabilities of Alice due to the *scope* parameter against which the actors of incoming posts are checked.
|
If **Eve** subsequently learns what the capabilities id is for **Alice** by somehow intercepting the traffic (eg. suppose she works for *Eveflare*) then she can't gain the capabilities of Alice due to the *scope* parameter against which the actors of incoming posts are checked.
|
||||||
|
|
Loading…
Reference in New Issue