Should there be trust between owners when a server supports multiple storages on the same origin

[justinwb]

Creating this issue to unblock #264, and to continue this thread.

For context, a note is provided in the addition of ownership requirements in #264 that states:

When a server supports multiple storages, there must be complete trust between its owners

Assuming that:

• server in this context is equivalent to a running instance of a solid server (e.g. community-server at https://pod.example)
• support of multiple storages with different owners equates to a typical pod hosting scenario (e.g. https://solidcommunity.net)

In this case, it would be true more often than not that a server with multiple storages does not realize complete trust between the owners of those storages. For example, I have a solidcommunity.net pod, but I do not know the majority of that user population, let alone completely trust them.

If server in this context was meant to uniquely identify scheme, host, and port (e.g. https://justinwb.pod.example/, that may address cases where server represents a storage partitioned by subdomain, but not cases where a server partitions storages by path (e.g. https://pod.example/justin/, https://pod.example/alice/).

[d-a-v-i--]

Perhaps we can break it down by even more levels of trust. There's server, yet really there's hardware, OS, database, driver and application. Running an instance of the server as trusted storage can beg the question of trust being established across all those tiers and even more. If I were to diagram this, it might look like a hexagon of six or more tests, and I would expect only storage adhering to the same test criteria to ever look similar enough to be trusted the same.

[kjetilk]

It seems the spec doesn't define the term "server" and it seems like it needs to, to be clear about this.

[csarven]

The Protocol doesn't (re)define "server" because it builds on HTTP server (as per 7230, 7231).

[kjetilk]

The Protocol doesn't (re)define "server" because it builds on HTTP server (as per 7230, 7231).

I don't think it resolves enough possible confusion though, because the first that you find when you look it up is:

An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.

and that could arguably apply to both of @justinwb 's versions of what a server means. We need to define it in terms of the authority component of the URI, right?

[csarven]

In the PR thread:

This is really about when a server supports multiple storages with different owners under the same host.

The key word that I used was "host" but perhaps I should've used "scheme, host, and port" to be more accurate. This is boils down to origin (see RFC 6454).

So what's intended/implied:

"When a server supports multiple storages on the same-origin [RFC 6454], there must be complete trust between its owners."

(Edit: happy to update the spec with that text in any case)

Right that /alice/ and /bob/ can be on the same origin, and again, nothing is prohibited from doing that. We're just saying that if you do that, make sure you (the server people) and its users understand / agree on what that entails.

[kjetilk]

Right, that clearifies what we are talking about!

[kjetilk]

I'd like to add:

"When a server supports multiple storages on the same-origin [RFC 6454], there must be complete trust between its owners. It is therefore discouraged to implement servers with multiple storages on the same-origin."

[timbl]

"..because web apps running in one storage will have the same rights as web apps running in the other". ?