Hi! We’re Juliette & Charlie, part of the BBC R&D team that built Together+ Data Pod.
Thank you so much for checking out our prototype, it’s the result of a lot of effort and research into personal data stores and Solid by a number of people. We wanted to provide a bit more context on some of the decisions we’ve taken, and our general direction of travel.
First off, as a few people have mentioned, these are some of our first steps into the Solid ecosystem, and we’ve made a few decisions to get this in front of the public in a reasonable time frame - more on that below. We also wanted to point out that this isn’t our first Solid experiment, we’ve previously trialed a service called My PDS.
It is worth mentioning that BBC Together+ is a trial, both to test out the viability of using Solid in the BBC, and to understand the general public’s appetite for personal data stores in general. As such, we designed the application using Solid and Solid concepts, whilst keeping in mind our duty as a public service organisation to keep our user’s data safe, and up-skill them on data practices. Most of the decisions we took are in the context of this trial, and that includes the limitations that most of you have highlighted in this thread, which hopefully this response will help clarify.
So, to the main point of discussion: Why have we prevented users from using their own pod providers, and why have we prevented other Solid apps from using our pod provider?
Our first and primary concern when working with personal data is the duty of care we have to our users, which, as a public service media organisation, we have a greater responsibility for. As a large organisation with an audience in the millions, we rightly need to make sure that the personal data that is entrusted to us when people use a BBC service is as safe as possible. Part of that safety also means that we need our handling of that data to follow BBC policy, and all applicable law.
Technically, the Together application should be able to accept a different pod provider (providing that pod provider supports Solid OIDC, Solid ACP and Solid Notifications), although we haven’t tested the app with different implementations. So although in the context of the trial we have locked down the Pod provider, it is built for interoperability.
However, from a data protection and security point of view, we have many more things to consider:
- 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?
- 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?
- 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.
It’s also worth thinking about the implications on the experience of a live service / app when the pod provider is entirely user-selectable. When both the service / app and the pod provider are hosted and managed by a single entity, the performance characteristics and error scenarios can be controlled to produce the desired service experience for the user. If a pod provider is selectable, we now need to think about how to inform the user if something unexpected happens. What if that pod provider is very slow to respond - what UX patterns need to be in place to ensure the user knows where the problem is and how to fix it? We completely believe these concerns are solvable, but require further thinking, experimentation and work by us and the Solid community.
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. As the BBC we have not given ourselves access to read and use the user’s data on their Pod without their permission, which conforms with the Solid approach. Our choice for hosting our own Pods are two-fold: Firstly, we wanted to answer some research questions about the viability of the BBC to become a Pod provider, and decided that trying it out during a large scale trial was a good way of getting started on that. And secondly, as a public service media organisation, we have to make sure that anyone is able to use the experience, even of they do not have a Pod, or understand how to create one with a provider of their choice. We therefore decided that by linking the Pod provisioning with our BBC Account log in flow, all of our users would be able to access and use our application and get a Pod.
We also took the decision to abstract away things like WebIDs and Pod Provider options from users, to reduce the friction for users that are not familiar with Solid, which we imagine will be the vast majority of the public. Our hope here was to make the app more approachable when explaining new concepts around data management.
All of this is a long way of saying: We want to open up those things - as you can see in the onboarding screens, we describe a world where this is possible, and exploring that world is why we produced this experiment. We also need to make sure that we meet our other goals as well: proving that Solid is a usable technology for working with personal data; finding out if handling personal data in this way is desirable for users (most of which know nothing about Solid and Pods); and finding out if we can continue to derive audience insight whilst deliberately splitting our services from the personal data of our users.
Finally, our answer to the question of is Together+ really a Solid app: We think so. Every aspect of the apps design has been looked at from a Solid perspective, for example:
- We store detailed analytics events on the users own Pod, and don’t give the BBC any access to that data by default. Users can then opt-in to giving the BBC access to their analytics event data, which again, is done through a Solid app.
- Watch parties are decentralised - all watch party co-ordination data is stored in Solid Pods. The watch party host stores the main watch party resource, granting access to it for other party members. All member actions are driven by Solid resource writes with notifications, making the application a complex manager of distributed state.
- There is a caveat to this - the actual time synchronisation of the media playback is done with “cloud-sync”, a media sync service co-developed by BBC R&D as part of the 2-IMMERSE project
If you’ve got any questions about Together+ DataPod, we’ll be at the next Solid World, 10th November.