Implementation of BBC Together+ Data Pod

[Vincent]

As I’m sure some others have also seen, BBC R&D launched a Solid-powered “Watch party” app called BBC Together+ Data Pod (BBC R&D blog post, Inrupt blog post).

I thought it was interesting to look into the implementation a bit, and figured I’d share my findings since others might find it interesting, for some good old speculation and gossipping

The first thing that struck me when opening the app, was that you could only use it by creating a BBC account, even though the in-app explainer mentions

You create a pod online from a provider of your choice (a bit like choosing a bank account)

In other words, I was unable to use it with one of my existing Pods.

When signing up for the BBC account though, you do get a Pod that is powered by a BBC instance of Inrupt’s ESS software. The server appears to be running at https://solid.bboxservices.net/, but despite the “Login or register” link, it doesn’t look like you can actually log in or register there

There’s no mention of my WebID anywhere, but inspecting network requests I can see that mine is https://id.solid.bboxservices.net/8zqZ4uoKYiXT8j_GnE0luHPdQjvkW-vq5zoiSJqWHso.

And from that, I can deduce that the Solid Identity Provider URL is https://openid.solid.bboxservices.net. And using that I can actually log in to another Solid app (Penny, in this case)!

Unfortunately, as soon as I try to use it to view any of the data in my new Pod, permission is denied — it looks like the Pod is locked down to only allow access via BBC Together+.

So that means at this point in time, the app can not be used with any other Solid servers, and the Solid server cannot be used with any other Solid app, which essentially means that the fact that it builds on top of Solid technologies behind the scenes is an implementation detail — as a user, it would not have made a difference if it was built on top of an app-specific back-end and stored the data in a custom app-specific database. Where the BBC blog post says

After the watch party has finished, rather than the BBC sweeping up all the data which has been generated, we make it visible to the user with the option to edit, delete or share back with the BBC to help build future services.

it appears to mostly be talking about giving BBC permission to use the data for other purposes — it will remain on the BBC’s servers anyway.

But! Of course this is just a first version. With this proof-of-concept, they’ll have hopefully learned how to split and access the data across different Pods, and hopefully in the future, we’ll hopefully see the app opening up to servers not under the BBC’s control, and the server opening up to apps not under the BBC’s control.

Have other people tried it? What do you think? Any other interesting findings?

[NoelDeMartin]

I also gave it a try and found similar limitations. In fact, you got a lot further than I did because I wasn’t even able to find my webId. I could look at the network requests and such, but to be honest, I won’t be bothered because my interest in this app is from the user’s point of view. I guess if it were Open Source I’d be more interested in the tech.

The point I’d emphasize which you already mentioned is that I don’t see the point of advertising this as a Solid App. Maybe in the future they’ll do something to open it up, but I’d advertise it as a Solid App at that point. As it stands right now, all that talk about PODs will only confuse people more than anything (or even worse, create false expectations). And I’m not sure I like the idea of calling this “Solid”, given that apparently this is all I can see from my data. I can’t even look at the RDF:

Also notice the lack of a logout button. Let alone talking about Solid standards, there are some things missing here that even Facebook would let me do.

Something else I noticed from the UX point of view is that I wasn’t able to add any friends, so I’m not sure how to use that Friends tab.

And finally, I wasn’t able to watch anything because I’m outside of the UK But I guess that’s to be expected. Again, I could use a VPN or something but I don’t think that’d change anything about what I’m trying to do, which concerns the Solid aspects of the app.

[nickform]

Thanks for the tip-off @Vincent. Unlike @NoelDeMartin , I am in the UK but there’s no-one I know who would be interested in watching any BBC content with me this way so I won’t use the service either.

I agree that it is frustrating that the main attractions of Solid are not supported by this app but I still think it is encouraging that the BBC have invested enough to stand up a real service using the technology.

[ThisIsMissEm]

Out of curiosity, @Vincent, @NoelDeMartin & @nickform — do you think a core proposition of Solid is that any application should have full access to your pod? (that is read & write access, just by logging in)

I know that with Inrupt’s PodSpaces, just by signing in you gain full pod access, and that you can give that access with NSS and CSS, though those screens in the OIDC consent flow aren’t specified by a standard – OIDC to my knowledge only supports “allow requested access” or “deny requested access” via scopes, and there is no defined OIDC scope for access to your Pod, just to your WebID.

As far as I know there’s also nothing in the specs that prohibits server implementations from granting full access to the pod only to a limited number of clients; there is an example in the ACP spec that shows denying access to all clients apart from a specific client identifier.

[nickform]

I think that the core proposition is that you can choose your pod provider. This is advertised as a feature in the marketing material on the main solidproject.org site. As @Vincent says, a situation where the only pod provider choice is the same organisation that provides the app is really no different from that organisation keeping your data in their proprietary database, especially if the pod can’t be used with any other application.

Is this situation what you were hoping the future of Solid would look like? What benefit does this even really offer to users? It doesn’t give me the benefit of only having to fill in my details once which is a feature that many people like about Solid.

[Vincent]

do you think a core proposition of Solid is that any application should have full access to your pod? (that is read & write access, just by logging in)

I would like to at least be able to give them partial access [edit: with me choosing which parts]. Lacking that, if I had to choose between no access at all for any application, or full access for applications I choose, then I’d choose the latter - similar to how applications I install on my laptop used to have full access to basically everything.

(That is being locked down more and more these days, which is good, but I think the main reason that this is feasible is because it can basically be done without changing any habits - the existing file selector UI can still be used to implicitly give that permission. But considering how the concept of files is already hard to grok, I’m sure this will be an even bigger UX challenge in a world where “files” aren’t the atomic concepts and different apps want access to different slices of the same data.)

But if the only option I’d have is no access at all, then I don’t think there’s any way a user can see a difference between the current version of Together+, and one that would not have been powered by Solid — in which case, what’s the point? (To which I’m guessing the answer is that this is the first step on the road to unlocking some of Solid’s benefits.)

[aveltens]

@Vincent

So that means at this point in time, the app can not be used with any other Solid servers, and the Solid server cannot be used with any other Solid app, which essentially means that the fact that it builds on top of Solid technologies behind the scenes is an implementation detail

Wow this sounds really sad and not like Solid at all.

An app does not become a Solid App by using a Solid Server behind the scenes, but by following the Solid specfication and this should make a difference to the end user, otherwise it is - like others said before - pointless.

do you think a core proposition of Solid is that any application should have full access to your pod? (that is read & write access, just by logging in)

No, this is not necesarry and not desirable in any case. These are the things I would - in general - expect from a Solid App:

• Log in with my existing WebID from a provider I choose
• Allow me to choose where to store data (explicitely or implicitly by something like type indexes)
• Allow to others (users and apps) to access this data

The core minium I would expect from an App like BBC to consider calling it a Solid App would be:

• Give me a new Pod and maybe WebID, but allow me to link the data from my existing Pods / Identities (i.e. give me at least read access to the raw RDF)
  • Ideally allow my to “sameAs” my existing WebID
• Enable CORS so that I can access the data with Solid Web Apps of my choice.
• It might be ok to restrict write access or at least apply validation rules to protect the data from corruption by other apps but it has to be applied carefully to not break interoperability

[cbraun]

Hi all,
I also had a look at the BBC’s PoC yesterday.
Like others, I was surprised to see that I could not see anything. Also tried Penny, Podbrowser and my own test app to access my BBC Pod.

do you think a core proposition of Solid is that any application should have full access to your pod? (that is read & write access, just by logging in)

I would expect that I can specify which Pod to use, or at least bring my own WebID.
And then free choice of app to consume my data.

I would expect from my Pod that I at least have read access such that I know what others (may) know about me. Otherwise I can not give informed consent when providing said data.
For giving others access, the same way, I would expect this to work at least for reading/consuming my data.
This, however, does not mean that I or others should always be allowed to edit that data, as there are some cases where this is undesired.

Currently, I only see things implemented that may benefit the operating company while actively obstructing the ideas of Solid that bring value to the user - control (to some extend).

By the way, the BBC’s implementation did not prevent me from getting to my own data in my BBC Pod. It was just really unnecessarily complicated…

I want to be able to use my own data. Period.

[jaxoncreed]

I echo the sentiments said above, specifically the responses to this question.

do you think a core proposition of Solid is that any application should have full access to your pod? (that is read & write access, just by logging in)

The solution to this problem is something called “client constraining access control,” (CCAC) though I’m unsure what it’s called now. Under client constraining access control, a user could prevent an app from getting access to only certain parts of their pod.

Fortunately, as far as I’m aware, @elf-pavlik and the rest of the data interoperability panel have been trying to solve this problem with delegated grants (Solid Application Interoperability). Efl-pavlik do you know how far this spec is?

It would be great if Inrupt could prioritize this for the BBC project because as it is now the BBC’s Solid implementation might as well be a traditional database.

[jeffz]

Great discussion. Stepping back a level, I see these issues :

Is it within the “Solid spirit” for a storage provider to maintain an allow list of applications they permit to access storages they host? What if that list is limited to applications provided by the storage provider? At what point does the owner’s implicit contol over their storage become abrogated by the storage provider?

[NoelDeMartin]

Hey @ThisIsMissEm I think I’m going to repeat what others said, but since you asked me directly here’s my opinion :).

do you think a core proposition of Solid is that any application should have full access to your pod? (that is read & write access, just by logging in)

No, actually I think it’s the other way around. I think a core proposition of Solid is that applications allow me to choose where to store my data (because it’s my data, right?). Whether the POD is government-funded, held by a private corporation, or sitting in a corner in my basement should only be of my concern; not the App’s. That’s the whole point of Solid.

Now, I understand the need to have a “sign up” option at the moment, because most people don’t even know what Solid is. I’m even a proponent of not bothering users much with Solid concepts (I’d say my “Solid Apps” explain Solid a lot less than Together+). But the golden path should still be to log in with an existing POD.

To me, a Solid App that only allows me to use a POD provider is like a website that only works with a single browser. The point of Solid is that it’s a protocol, so I should be able to use the implementation of my choice.

[ThisIsMissEm]

I think there will be applications that for now will enforce a specific pod provider, even if not in the “Solid Spirit”, ideally that’s not the case long term, but there are certain areas where data in pods might be more sensitive, so there’s a duty of care for Governments and Business to protect that data.

The last thing a company or government wants is to be blamed for a data breach because someone poorly secured pods & stored a lot of highly sensitive data there. With controlling pods comes responsibility that folks may not be aware of just yet, but that will be something that we need to guide the path on.

That, or it’ll be something like: use our app with your own WebID & sign this long liability form stating that you are responsible for your data & absolve the company of any liability relating to your pods’ security being breached

Either way, poorly secured pods pose a fundamental risk to mass adoption of Solid, all it would take is one instance to be mired in a data breach for folks to start mistrusting Solid as a whole, especially while the project is so young.

[ThisIsMissEm]

As for Together+ and other prototype/new apps in the ecosystem, I believe they’ll evolve towards the “Solid Spirit” or “Solid Way” in time; BBC are not the only one’s to control the signup experience, I know use.id’s docs are full of information about controlling the signup journey (not picking on y’all, it’s just an example that comes to mind)

[NoelDeMartin]

@ThisIsMissEm

I think there will be applications that for now will enforce a specific pod provider, even if not in the “Solid Spirit”, ideally that’s not the case long term, but there are certain areas where data in pods might be more sensitive, so there’s a duty of care for Governments and Business to protect that data.

Sure, I understand that, but if they have that mindset I’m not sure what’s the point of using Solid (other than as a marketing ploy). Just use a traditional database, it’s a lot easier to implement.

@ThisIsMissEm

As for Together+ and other prototype/new apps in the ecosystem, I believe they’ll evolve towards the “Solid Spirit” or “Solid Way” in time; BBC are not the only one’s to control the signup experience, I know use.id’s docs are full of information about controlling the signup journey (not picking on y’all, it’s just an example that comes to mind)

I don’t know what use.id is, but thanks for sharing I’ll check it out. (edit: ok, I knew what it is I just didn’t remember the name )

In any case, as I said before if BBC is eventually going to do something in the spirit of Solid, then I think it’s at that point that they should even mention the word “Solid” to users. I don’t see the point of confusing them with it as the app stands right now.

[A_A]

@NoelDeMartin

Sure, I understand that, but if they have that mindset I’m not sure what’s the point of using Solid (other than as a marketing ploy). Just use a traditional database, it’s a lot easier to implement.

This way, they can try out if the Solid pods are feasible for their purposes. They see if they can make an app, that stores data distributed, see what problems they face, how users react to having more control, etc. To me it looks like a test, if Solid pods are able to support their use case.

[NoelDeMartin]

Sorry @A_A, I don’t want to be pedantic but I just want to make sure we’re on the same page here. I understand what you mean, and this was also my impression when I first heard about the project. But I’m not sure how they are testing any of the following with the current version of the app:

• “Stores data distributed”: How is data distributed if it’s only using a single POD provider?
• “How users react to having more control”: What exactly is giving them more control than a non-Solid App would?

What they do test is if “solid pods are feasible for their purposes” and “they can make an app”. But surely, that doesn’t justify talking about Solid in any user-facing copy. I don’t see any other websites around advertising what technologies they are using in the backend.

Also, I still don’t understand why they included the image that @Vincent posted at the beginning. “You can create a pod online from a provider of your choice”. The first step in those instructions is already not true. And then they have a button saying “experience the future now”, just to find an app that doesn’t even have a logout button (I’m sorry to be so annoying with that, but I find it very aggravating in terms of UX and privacy).

Again, if they are thinking on actually fulfilling any of those promises at some point, or if I’m missing something, that’d change my opinion. But as things stand right now, I don’t understand it.

It seems like they’ll present the project at the upcoming Solid World next week, so maybe that will clear up some of our doubts.

[Tom]

Just to be clear, use.id is not about controlling the signup journey. We leave it to our customers to decide whether or not to let non-use.id WebIDs login or not.

So far, not a single one of our customers aims to restrict their logon journey to use.id WebIDs - as it should be :-).

[ThisIsMissEm]

Oh! Your documentation seemed to focus so heavily on that aspect of things, so I must’ve had the wrong impression! Sorry!

[charliehalford]

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.