Outstanding Questions
Can you define, for each property in a POD, who has access to it, not just the whole POD?
If access controls are that granular how do we simplify the UI such that ‘normal’ people can understand and want to engage with it?
How can we alert people to unscrupulous consumers who have taken a local copy of the data? - this is a good thread on that topic How exactly does Solid decouple data and applications? - #17 by Trond
I think the diagrams are about right except for the first one where I think you are equating WebID and POD.
A WebID is a URI (including the URI frament = the bit after the ‘#’) which points to a profile document (ie the part before the ‘#’). So the profile can be any HTML web page/document, and doesn’t need to be on a POD but that’s the best place for it! The fragment points to an ‘entity’ in the profile (such as a person, group, app). The profile can be read to see if there is more information about that entity - such as “this is a person”, with name “James”, etc
Whereas a POD is somewhere that data can be stored and accessed using the Solid web protocols. Normally a server. A server can host one or more PODs owned by different entities - identified by their WebID. So I could own a POD on a server with a WebID that points to a different server, but most often they’ll have the same base URI (web address).
Yes.
It’s a challenge indeed. Currently its hard even for developers to do this, so that is being worked on by people creating libraries for code to make this easier. UI is also going to need a lot of careful work to make this simple and intuitive.
That’s a good question and another thing to be worked on.
Something I want to add here is, that for several use cases there is no need to send the data to any other server. If I want to listen to my music, I just stream it directly from my pod. If I want to update a text file, I open it in an online editor which only communicates with my pod. So in these scenarios, no other server will ever see the data, and hence not be able to copy it.
Of course, there is still the question of trust towards such apps. It would likely be good if they are open source, so developers can double check it. Also there would be the option of a browser extension which watches the traffic and ensures that no data is sent to third parties, though this could be a bit inconvenient I guess.
Thanks for the feedback everyone. Good to know I am on the right track.
@A_A I agree you do not need to send data to other platforms, but there is nothing stopping an unscrupulous company (lets call them FaceNovel for now) taking all the data from the POD and storing it for their own benefit. Clearly these commercial companies will not open their code for scrutiny, so really we have to take it on trust that FaceNovel will not abuse the process.
It would be great if there where some terms and conditions in the Solid standards that explained what is acceptable use of data once it has left Solid. (say cached for 2hrs in memory only cache etc), But I suspect we are deviating from the thread and should perhaps pick this up in the other thread?
You inspired me to think about the granular access controls.
The access control can always be complicated in practice. Usually (I may be wrong), systems are using the inheritance mechanism to simplify it. That is, if not specified, refer to my container’s settings. In my understanding, ACL follows the same tactic.
The inheritance mechanism is very efficient in tree-like structures, where people can generally set the root to high-level classification for certain visitor groups, then reduce it or elaborate the sub-layer settings only when required, or sometimes move a branch into a path with different classified level.
Come to Solid. If the scope of access control is still “resource”(URL or document), we can stay with the same mechanism. However, another meaningful scope of access control is “knowledge”, which has the structure of graph rather than tree.
Say if my host has file1 and file2 both contain some knowledge about Alice and Bob, my restriction of access to the visitor Victor is “all knowledge about Alice”, while open “all knowledge about Bob”. I may not care whether such knowledge is stored in file1 or file2 or even both.
In this case, the inheritance strategy may not be that effective due to the above-mentioned reasons. With a brief thought, I think the rule-based approach maybe perform better however raising the bar in maintaining. Anyway, I believe this is something we need to think about.
@dprat0821 Yes I think you are right opening access to content around a particular subject or object would be desirable, regardless of its location in the graph. Role based is going to be the way to go, but will obviously require some very careful thinking.
@Smag0 Yes I realise that, but trying to think of a way to conceptualise it. Perhaps I will add your comment to the narrative text on the slide. Thanks for the input
