solid
Name "defaultForNew" doesn't agree with semantics
People tell me defaultForNew actually means "default for when the ACL file is missing or maybe empty or maybe doesn't have any triples in it or maybe doesn't have the right kind of triples in it".
It should either be implemented as "default for new" -- meaning when a resource is created in a container, this is the ACL it's given -- or the name should be changed (and the exact conditions for when it applies should be specified).
I don't currently have an opinion which is better.
If the semantics stay as I believe they are implemented, then I suggest the name change to "background" (or something like that), but I don't know how to say when it applies. Every idea I can think of for that is a hack.
+1 to this. I agree that the name and semantics are currently confusing. And, more importantly, kind of dangerous, security wise.
(See also Nicola's writeup of the issue at https://github.com/solid/solid-spec/blob/master/acl-inheritance.md, where he outlines both the current defaultForNew strategy, and an alternate default mechanism. Both seem to have serious drawbacks.)
(See also https://github.com/solid/solid-spec/issues/60 which is only vaguely related)
In an earlier discussion with @nicola, he pointed out that this current defaultForNew mechanism makes it way too easy for the user to make mistakes (and unintentionally expose previously-private resources en mass).
I propose we keep the name, defaultForNew, but change the semantics/implementation to match it:
Change semantics to match name: a Solid server should explicitly create an ACL file for each new resource created to match the one specified in defaultForNew.
Support user convenience through alternate mechanism: The defaultForNew mechanism was created as a user convenience mechanism, to allow users to quickly mass-change permissions on all resources in a container. However, the aim of user convenience can be supported through client-side code. (For example, client apps like Warp that let you change ACLs on containers can offer a 'Change permission on all contained resources' type buttons that iterate through resources and mass-convert them).
I think if this has to happen, then we need to have a way to recursively set all the acls in a folder with one HTTP request only, or it will be impossible to change permissions to 3000 pictures in a folder.
I agree. We should have a server-side API call to recursively set ACLs. I didn't propose it because I know you tend to dislike server-side approaches :)
I can't think of a way to fit it into our current architecture that wouldn't be a complete outlier, not really fitting REST at all. Ideas?
Yeah, maybe. Patch is a standardization mess. And where would you post the patch that makes sense in a restful way?
I guess maybe: given a SPARQL endpoint whose dataset is all the RDF LDPRs, and which has some convention for how to make link headers available, and includes the acl graphs, maybe there's a SPARQL update that would make the change. Yeah.... I think so.
@dmitrizagidulin Is there an actual "Default for New" -- meaning a default setting for newly created things, such as files in Warp or wherever? If there is, then the actual default setting should be private and people should have to make things public (or grant specific permissions to people or apps). If there isn't, then we should have such a setting.
