-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LDN Inbox: add guidance and security considerations #464
Comments
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. #253 covers access requests. #394 is about processing HTTP messages. |
ACP supports maintaining a blacklist on otherwise an https://solid.github.io/webid-profile/#inbox
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. |
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 ( 1b7dadb ) to include a general consideration:
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. |
👍
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.
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.
WebID Profile promotes it but this can be handled at solid/webid-profile#56 I also proposed removing public access inbox from SAI solid/data-interoperability-panel#280 |
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 @csarvenI 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 ofldn: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.The text was updated successfully, but these errors were encountered: