Skip to content
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

Current Container Listing mechanism does not support hidden resource use case #626

Open
dmitrizagidulin opened this issue Jan 21, 2016 · 7 comments

Comments

@dmitrizagidulin
Copy link
Member

The current mechanism to list resources in a Solid container does not support an important social media use case.

Say I'm implementing a social blog service (like LiveJournal or Facebook) that allows me to specify access control on each post: public, private (only I can see and read those posts), and friends-only.
Using the current Solid spec and implementation, I cannot simply put my Posts as resources in a /blog/ Container, and set their corresponding ACL files. This is because when an un-authenticated user (or an authenticated user who is not on my Friends list) does a List Resources request on the /blog/ container, they will see all of the posts listed on my blog, even private or friends-only ones.

In other words, as a non-friend, I do GET dmitri.databox.me/blog/, I will see that it contains:

  • public post 1 (which means I have read access to it, no problem)
  • private post 2 (I can see it on the list, but get a 401 / access denied when I try to request it)
  • friends-only post 3 (again, I can see it on the list but get access denied)

This is completely un-usable, in terms of being able to implement private/hidden resources in the context of a social media app.

After a discussion with @deiu, @sandhawke and @nicola, the proposal is to:

  • Change the Solid spec dealing with listing of containers, do not show resources a user has no access to.
  • Update the relevant implementations (ldnode, etc) to match it.
@bblfish
Copy link
Contributor

bblfish commented Feb 3, 2016

I agree this can be useful. Indeed I found a use case in the Storing an Apps Public Key use case.

But this raises an important question: how can a client know that if it were to authenticate as X then it would be able to see more? This problem is similar to the one raised in issue 45: No way to find out if user is authorized to write to a container and is also described in Client Authentication Discovery.

@dmitrizagidulin
Copy link
Member Author

I think you may be missing the point of hidden resources. The client is not supposed to know that if it were to authenticate it would be able to see more. And shouldn't. As in, that's the main value of the feature.

@bblfish
Copy link
Contributor

bblfish commented Feb 3, 2016

As pointed out I have a use case for hidden resource in Storing an Apps Public Key and I can see other uses for it too, in cases of strong privacy protection.

But this does not mean that there are no use cases where it is useful to see resources that are protected. For example

  • if I want to say there is a resource available to members of my club, but I want people to know that, so that they can join the club.
  • if I have a resource that is only visible to people over a certain age, but I actually want people of that age to see it, if they can prove it, because I want them to check it out.

What is actually needed is a way to state that links to a certain hidden resources should be hidden when one wishes that to be the case, and to be able to state that links to hidden resources are visible when one wants that to be the case.

So I think actually we need a vocabulary for describing views on resources, which could be part of acl.

That is a new feature since:

  • LDP says nothing about it.
  • The current WAC ontology says nothing about this either

If we don't document this there is no reason some servers will go one way and others the other, and clients won't have any way of knowing what the server will do ahead of time.

@dmitrizagidulin
Copy link
Member Author

I agree, there's definitely a need to explicitly state the two different intentions - 1) this resource is hidden (and so doesn't show up on lists, and accessing it yields a 404), and 2) this resource is not hidden but locked (and so yields a 401).

@melvincarvalho
Copy link
Member

@bblfish +1 this is a new feature, and not a bug.

I would prefer this issue to be phrased in amore neutral way.

The opening premise:

The current mechanism to list resources in a Solid container does not support an important social media use case

That's not the case is it. The argument is that the names of files may be leaked, if they are put in a public container.

Of course there is another solution: dont put the names of those in a public container.

This is completely un-usable

I would also like to see this rephrased in more neutral language, I think it's too strong.

Update the relevant implementations (ldnode, etc) to match it.

Also what are all the relevant implementations? Does this not apply to all LDP next and upcoming Solid implementations? Could we try to investigate all the systems that might need to make changes?

After a discussion with @deiu, @sandhawke and @nicola, the proposal is to:

Do you have a pointer to this? From what @sandhawke said in the meeting I remember, containers should either list all resources in them or none. I may have misheard there. It seems like this proposal actually is an architectural change. Perhaps there's implications as to the RESTfulness etc. that may need a lot of consideration.

@ebporter
Copy link

@dmitrizagidulin Is it just that the unauthenticated user or not-connected user can see a list of all the resources in the container, or that they can see the listed items themselves? Either way, it's not acceptable, I'm just trying to understand. It seems very important to support the ability to set a general permission on a container (public, for example), but allow an arbitrary number of overrides on the items in the container, including other containers, etc. For example, let's say you have a blog post in an unfinished state and you just want to save it and come back to it tomorrow. So, you want it to be private for the time being until you're ready to publish it. Anyway, there are dozens of use cases...

@csarven csarven transferred this issue from solid/solid Feb 25, 2024
@csarven
Copy link
Member

csarven commented Feb 25, 2024

Just throwing this out there.. Thinking along the lines of the following behaviour:

gitignore - Specifies intentionally untracked files to ignore

  1. An index of URIs can be tracked in a reserved URI - doesn't matter where for the time being but it could be in container's ignore/hide list (e.g., /.ignore), container's description resource (e.g., /.meta), or even the resource's own description resource (/foo.meta)
  2. Specific data model for their discovery and description.

The "resources to ignore/hide from containment listing" can be managed by applications.

Server can look up the ignore/hide index when it needs to generate the containment statements. Being on the ignore/hide list can/may impose additional semantics, behaviour, access on resources.

https://solidproject.org/ED/protocol (as of this writing) does not specify the visibility of auxiliary resources in containment statements. Some server implementations do omit auxiliary resources in containment statements. This behaviour is equivalent to the declarative approach of using an ignore list. The default behaviour could be to hide auxiliary resources from containment - whether or not mentioned in the ignore/hide index. Furthermore, while it'd be an implementation detail for the servers to omit the visibility of certain resources (at least from a container description) that it deems it should, e.g., .swp, the actual behaviour on such resources may be the same as the resources listed in ignore/hide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

5 participants