Think Privacy

Data never dies

Good morning from the Datamaze exhibition at DOX.

Follow

A11y notice 

Yesterday I've used heavily to tag the . But since @maloki mentioned an accessibility issue with screen readers, today I'll use the latter tag instead.

Replies to this feed will cover the upcoming keynote.

Cheers!

Architectures of Robust Openness 

On stage Mark S. Miller...

@cwebber is introducing the keynote speaker and his work on Object Capabilities and the Principle of Least Authority...

Show thread

Architectures of Robust Openness 

Chris has brought a copy of Mark's thesis on Robust Composition (erights.org/talks/thesis/) and have him autograph it :)

Show thread

Architectures of Robust Openness 

Mark S. Miller starts with thanking his colleagues over the years...

This is collective work.

Show thread

Architectures of Robust Openness 

Robust against attacks, while open to strangers.

Over time the cooperative networks grew through phase transitions to cover the whole world, with isolated pockets of violence remaining.

Our world is comparatively much less violent today than it was before.

We would be able to approach the world with a premise of cooperation. But then a new set of problems emerged that broke this premise. E.g., junk mail, spam.

Show thread

Architectures of Robust Openness 

In the physical we cannot build impenetrable walls. Stronger wall require stronger forces to be broken.

In the digital world we have cheap bricks: address space boundary, object encapsulation, modern cryptography.

In the physical world, the attacker's attention and effort is required. But in the digital world, the attacker can use automation to scale up attacks.

A very small number of bad actors can flood the world with poison.

Show thread

Architectures of Robust Openness 

The danger is that we react to this flood of poison by retracting from the world, and stop being open to strangers.

There's a trade-off between cooperation and safety. In the beginning of th eInternet we were naive about the danger. As attacks appeared we moved down the trade-off curve towards safety.

Show thread

Architectures of Robust Openness 

Decentralized Designation

(an unsafe form of naming)

Impersonation: no one can seem to be you

Censorship: No one can take your "name" away from you.

We want to solve the impersonation problem without hitting the censorship problem.

Show thread

Architectures of Robust Openness 

Decentralized Designation

An analogy with Bitcoin:

Theft: no one can spend your bitcoin

Capital controls: no one can prevent you from spending your bitcoin.

We want the same kind of security in decentralized systems to communicate with wach other

Show thread

Architectures of Robust Openness 

Two kinds of safety

Proactive and reactive.

Sometimes, we mess up or the system will operate in ways that are less safe, so we need reactive safety aka damage control

Show thread

Architectures of Robust Openness 

OCaps vs. ACLs

Object Capabilities are authorization-based, and ACLs, are identity-based.

Proactive safety vs Reactive Damage Control

Program decisions vs. Human decisions

Least Authority vs Most Responsibility

Fine-grain vs large-grain

virus & worm resistant vs spam and troll resistant

local knowledge vs central administration

We need to build a system that has both of these strengths...

Show thread

Architectures of Robust Openness 

If you're stuck with Access Control Lists, you may want to look into Polaris, Plash or Bitfrost.

In the 1970s, "Hybrid" Cap Systems (SCAP, Sys/38). But these systems showed problems of composition...

There's one last thing to try: start with a pure object capabilities foundation. (Horton)

Show thread

Architectures of Robust Openness 

Delegating Least Authority

(Sorry, this is going to be visual language from now on, so very hard to convey in text...)

The slide is showing three circles A, B, C. A has two arrows going to each of the other nodes.

A, B, and C are three objects, and the arrows are references.

Show thread

Architectures of Robust Openness 

Object A can execute code: A invokes the foo method of object B on C. b.foo(c). "c" is A's pointer to C.

Messages are only means to cause effects.

References are permissions

Leverage Object Oriented patterns.

But from the perspective of reactive damage control, object C does not know whether the invocation came from A or B.

Show thread

Architectures of Robust Openness 

That's the problem with Hybrid systems... You can't know in retrospect what happened.

There's something adding a granularity that is useful to human beings making the decision of cutting off access.

So proactively, when abuse did not happen yet, we want a system that operates as a simple ocaps system. A can act as if it was running from object B.

Show thread

Architectures of Robust Openness 

There's a "sentry" in A asking "Do I still use B's services?". The answer is yes, so the message is delivered to B. Then B's "sentry" asks whether B still is accepting A's requests.

Show thread

Architectures of Robust Openness 

In the SCoopFS at HP Labs, there was such a system that kept track of the updates in the "secure cooperative file system".

So what unit in the system is held responsible?

A is Alice, the human, plus her PC.
B is Bob, the human, plus his PC.
In the simplest case, Alice will hold bob responsible for the bad action of software running on Bob's PC.

Show thread

Architectures of Robust Openness 

If Alice sends an email to Bob to share a lamp, Alice nmeans she's sending the lamp. This is what is designated by the system.

Meanwhile, there are other objects and processes happening in the background.

It does not matter: both Alice and Bob are talking about the same lamp, this is what designation means.

Show thread

Architectures of Robust Openness 

Zooko's traingle

- 1 Globally meaningful
- 2 No impeersonation, no censorship
- 3 Human meaningful

No system can have all three properties, only two at once.

en.wikipedia.org/wiki/Zooko%27

1+2 -> crypto address
2+3 -> petnames

Show thread

Architectures of Robust Openness 

Three-party intermediation

Something amazing happened this morning: I called a car, someone I never saw before, in a car I never saw before, came to me and I got into the car. Vice-versa for the driver.

The introduction was contextual: not "Is this Alice?" but "Is this Alice that the company sent to me for this ride?"

Show thread
Show more
Sign in to participate in the conversation
Une fois pour TOOT! A Mastodon in Brussels

Une fois pour TOOT !

This instance is provided by Petites Singularités ASBL for like-minded people in Brussels and elsewhere.

We speak English, French, Dutch.

P.S.: works with free software and grassroots activists across disciplines, ranging from agro-ecology to cartography, libre aesthetics & ethics, (self-)organization & policy.

Discuss this on ps.zoethical.org.

Support this instance

Donate using Liberapay

Send donations to IBAN BE16 3630 1548 4674 (Petites Singularités ASBL) with mention ps.s10y.eu (and your name if and only if you want to be credited): we publish donations as we receive them, and expenses. Yearly service is expected to cost ~ 150 € (without sysadmin expenses.)


“We've got to fight the government, fight the oligarchy, fight capitalism, be internationalist and fight the empire because it's the best hope to enrich hundreds of millions of lives, and build towards a truly equitable future.”
— Abby Martin

Norms

  • Use English, French, or Flemish on this instance. Other languages will be excluded.
  • Be excellent to each other! We reserve the right to ban anyone who doesn't comply.
  • Fight the power!

Break in Case of Emergency

If you have any problem with someone on this instance, thank you to flag messages appropriately and contact the staff.

As this is a federated network, we expressly forbid contents such as: spam, pornography without NSFW tag, hate speech, racism, sexism, consumerism, corporatism, and nationalism.

Your Friendly Staff

@how, @natacha.