LDN Inbox: add guidance and security considerations

[elf-pavlik]

Currently, Solid Protocol only has a small section about LDN Inboxes https://solidproject.org/TR/protocol#notifications

I see it underspecified and I also miss security considerations related to use of inboxes.

CSS has a way to assign an inbox to a resource: https://communitysolidserver.github.io/CommunitySolidServer/5.x/usage/metadata/#example-of-a-workflow-for-editing-a-description-resource

I think this is the only exception that allows clients to set a link header. I see that #375 tracks this already.

When it comes to using inbox which has access set to acl:AuthenticatedAgent I think we should add considerations about them being prone to spam. I would go as far as a recommendation to only only use such inboxes at dedicated storage providers which have spam protection in place.

Related to the above, access control should be able to blacklist identities that were marked as sources of spam. I believe APC has such a capability of combining acl:AuthenticatedAgent policy with a blacklist. I'm not sure if WAC has any comparable features. /cc @matthieubosquet @csarven

I would also see it helpful to have some strategy for specializing inboxes. For example, SAI introduces the dedicated property interop:hasAccessInbox which probably should be defined as a sub-property of ldn:inbox. I don't see a need here for Link header-based discovery but it would be good to know if anyone else needed to define specialized inboxes.

[csarven]

Any container can be used as an inbox. The concern is about public-append to a container (or any resource in fact).

Unless otherwise specified in the specification, resource- or implementation-specific processing of HTTP messages is a variability - to allow for a wide variety of use cases. The URI owner (e.g., of a container with public-append) can set up processing rules for HTTP requests based on whatever measures they deem to be necessary or useful, at any time, for any reason.

https://solidproject.org/ED/protocol#consider-request-validation covers the essence of sanitizing and processing messages.

Specialised inboxes can work when validation rules, authorization rules, or something else is well-defined and required.

https://github.com/solid/specification/pull/253 covers access requests.

https://github.com/solid/specification/issues/394 is about processing HTTP messages.

[elf-pavlik]

The URI owner (e.g., of a container with public-append) can set up processing rules for HTTP requests based on whatever measures they deem to be necessary or useful, at any time, for any reason.

ACP supports maintaining a blacklist on otherwise an acl:AuthenticatedAgent append inbox, which can be the result of suggested processing. Does WAC provide similar functionality?

---

https://solid.github.io/webid-profile/#inbox

If no inbox is found a Pod Management App MAY create an inbox by creating a container. In that case, the app SHOULD also create access controls for the container that give read and write permissions to the WebID owner and append but not read or write permissions to everyone else.

I think that besides creating a tracking issue in the webid-profile repo, we could have some general security considerations warning about doing what is suggested above. Again, such public inboxes can lead to spam unless deployed on specialized storage which has a spam protection infrastructure.

[csarven]

Please use "denylist" instead of "blacklist" (harmful language).

A denylist will not prevent spam from throw-away WebIDs.

Again, a request may be forbidden for any reason at the discretion of the server. I've updated the ED ( https://github.com/solid/specification/commit/1b7dadbf1ec72f5a8413d3de248b1b515961f284 ) to include a general consideration:

Servers are encouraged to restrict untrusted requests.

Solid Protocol and WebID Profile do not require a public inbox. It is the specs that require a public inbox should include additional requirements and considerations to prevent spam.

[elf-pavlik]

Please use "denylist" instead of "blacklist" (harmful language).

👍

A denylist will not prevent spam from throw-away WebIDs.

True, while it would force spammer to generate new WebID every time, it will also bloat servers' acl resolution. Which looks like a losing battle.

I think dedicated inbox provider with spam protection infrastructure seems like the only realistic way to use public inboxes.

Again, a request may be forbidden for any reason at the discretion of the server. I've updated the ED ( https://github.com/solid/specification/commit/1b7dadbf1ec72f5a8413d3de248b1b515961f284 ) to include a general consideration:

Servers are encouraged to restrict untrusted requests.

How do you imagine it working? If a user, or an app if it is for whatever reason allowed, creates a public inbox, the server doesn't have any way to prevent it. Looks like another reason to use a dedicated access policy management application which can prevent users from opening their storage up to spam.

Solid Protocol and WebID Profile do not require a public inbox. It is the specs that require a public inbox should include additional requirements and considerations to prevent spam.

WebID Profile promotes it but this can be handled at https://github.com/solid/webid-profile/issues/56

I also proposed removing public access inbox from SAI https://github.com/solid/data-interoperability-panel/issues/280