Thank you for your insightful comment, and welcome!
Personally, I am very happy to see Solid in a production-level beta.
At the same time, I would have loved to see the interoperability you say you had in mind.
I think you have a sound reasoning for doing everything within the BBC’s house,
especially when it comes to the security and privacy considerations.
However, I would like to comment on a few aspects (where others are invited to disagree and discuss!):
As the host of personal data in our pod provider, what might other applications do with that data?
Are we happy, as an organisation, absolving ourselves of the responsibility for that data when other applications use it, and is it legal to do so?
The question is if you - as a Pod Provider - are just a provider of access controlled web storage;
then you would be in the same position as, let’s say, Google Drive or Dropbox. None of these do - nor should, in my opinion - care what I do with the data stored there. I feel that most people (I talked to) think that this is the default.
On the other hand, if you consider the Pod Provider to be a data processor (as storage is processing) or data fiduciary, then you are in a whole different (legal) argument.
Trouble is, I was able to give another WebID of mine access to my BBC Pod and then access that data from a third party app. I was able to do this BECAUSE you designed your PoC in Solid style (e.g., the user setting access rights, the user patching data in resources etc). So, in the end, you did not achieve your goal with the design choices you made. Here, some more restrictive (and thus interoperability-impeding) approaches would be necessary which I would really dislike to see…
As the provider of a Solid app, do we also have responsibility for the data that is produced by that app? And if so, does that responsibility extend into other pod providers that might be connected?
That is a good question. I am genuinely curious about what legally literate people think about this.
However, if I may use a kinda strange analogy: A gun manufacturer is not liable for what other people do with said guns.
From a security perspective, the attack surface is larger when the pod provider and app accept new (or all) connecting implementations. Data inserted into a pod by another app may interact with our app in an unexpected or malicious way, and vice versa.
Agreed, and what is more, I agree that this is something you would want to rule out for a PoC.
In general however, I would think that you only use data you would want to use. If I think about the RDF you produce, you get the RDF from the Pod, you parse it, you query it and use only the part you want.
Can you give an example of data producing malicious behaviour of imperative code that is meant to process personal data? I am genuinely curious!
It’s also worth thinking about the implications on the experience of a live service / app when the pod provider is entirely user-selectable [ … and the whole paragraph].
Take Mastodon, a federated micro-blogging platform, as an example.
Granted, UX for such stuff may be out of scope for a PoC but that would be totally understandable for those people who deliberately choose to use a different Pod provider than the BBC (even more if you just say: “Hey, choose us! When you use a different Pod provider, we cannot guarantee our service.”)
Additionally, even though the BBC is both the Pod Provider, and the App provider in this trial, these are fundamentally two different services, and user consent is required for the the app to have access to the Pod, in the same way as any app and Pod provider would interact [… and the whole paragraph]
Thank you, I noticed this while tinkering, and I did appreciate it! Good job on this!
So while I still question some design choices, I am really happy to see your work out in the wild!