localhost_frssoft/ocappub
1
0
Fork 0
mirror of https://gitlab.com/spritely/ocappub.git synced 2024-11-26 23:23:03 +00:00
Code Issues Projects Releases Wiki Activity

A way forward

Browse Source
This commit is contained in:
Christopher Lemmer Webber 2019-07-18 17:20:01 -04:00
parent dfa268200c
commit be27c3e64f
No known key found for this signature in database
GPG Key ID: 4BC025925FF8F4D3
1 changed files with 54 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
README.org
View File

@ -625,11 +625,62 @@ standing up for human rights; if the choice is between doing
business in a country or not violating its citizens' rights,
most companies will seek to maximize value for their shareholders.
But don't give up hope!
There is a way out of this mess, after all.
** A way forward: networks of consent
Don't give up hope!
There is a way out of this mess, after all.
It lies with the particular use of a security paradigm called "object
capabilities" (or "ocaps").
We will get into the technicality of how to implement ocaps in
[[*How to build it][How to build it]] but for now, let's think about our high-level goals.
The foundation of our system will rely on establishing trust between
two parties.
If Alice trusts Carol to be able to perform an action, she might
"give consent" to Carol.
However, giving consent to Carol is not necessarily permanent; Alice
has the tools to track abuse of her resources, and if she sees that
Carol is responsible, she can revoke her consent to Carol.
(While Carol could have handed this authority to someone else, Alice
would still see the abuse coming from the access she handed Carol,
and could still hold Carol responsible.)
What about users that do not yet trust each other?
If Alice does not yet know or trust Bob, it is up to Alice's default
settings as to whether or not Bob has any opportunity to message Alice.
Maybe Alice only gets messages from entities she has existing
relationships with.
However, it is possible that Alice could have a "default profile"
that anyone can see, but which bears a cost to send a message through.
Perhaps Bob can try to send a message, but it ends up in a moderator
queue.
Or, perhaps Bob can send Alice a message, but he must attach "two
stamps" to the message.
In this case, if the message was nice, Alice might refund Bob one
or both stamps.
She might even decide to hand him the authority to send messages to
her in the future, for free.
But say Bob is a spammer and is sending a viagra ad; Alice can keep
the stamps.
Now Bob has to "pay" Alice to be spammed (and depending on how we
decide to implement it, Alice might be paid to be spammed).
There is always a cost to unwanted messages, but in our current
systems the costs lie on the side of the receiver, not the sender.
We can shift that dynamic for unestablished relationships.
And critically, it is up to Alice to decide her threshold: if she
is receiving critically abusive messages, she can up the number of
stamps required, disable her public inbox entirely, or hand over
moderation to a trusted party during a particularly difficult period.
But even if she disables her inbox, the parties which have existing
trust relationships with Alice can still message her at no cost.
This document does not specify mechanisms but opens up several
opportunities.
It is up to the community to decide which routes are considered
acceptable.
But the framework for all of this is object capabilities.
** Must we boil the ocean?
* How to build it