Implementation of BBC Together+ Data Pod

9

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.

3 Likes
10

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?

1 Like
11

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.

12

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.

1 Like
13

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)

2 Likes
14

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.

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 :slight_smile:)

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.

15

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.

2 Likes
16

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.

2 Likes
17

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 :-).

1 Like
18

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

19

@rajugeorge - I moved your question to a topic of its own as it is unrelated to this topic. Please continue discussion there.

7 posts were split to a new topic: Use Case - Vaccination Cards

27

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.

8 Likes
28

Personally, I am in favor of a big tent - you want to promote Solid, come on in! At the same time though, we need to demand and evolve a concept of “the Solid spirit”.

So, welcome Togther+ crew and thanks for your work! Hopefully this discussion and ensuing discussions at Solid World will let us all collaborate on defining and manifesting the Solid spirit.

5 Likes
29

This is so great Charlie, thanks for sharing all that. I think it’s fantastic not just that you’re running the experiment, but are also sharing the challenges you encounter in public. That will help us all learn and hopefully tackle these challenges together. At least personally I’m looking forward to seeing how you move forward in your Solid journey, and what solutions you and others envision for the problems you so clearly outline. Again, thanks for sharing!

2 Likes
30

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! :slight_smile:

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! :+1: Good job on this!

So while I still question some design choices, I am really happy to see your work out in the wild!

1 Like
31

Hi @charliehalford, thanks for joining the conversation and giving more insights into the conception of the app.

Although I disagree with some of the points you made, I totally understand your position and I think it’s great to see companies like the BBC diving into Solid. Many of the issues you raised are problems that the community hasn’t solved either, and I’m sure that use-cases like yours will help in shaping the way forward. Thanks for your work!

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

I think this is the crux of our disagreement. You say it’s your duty to keep the users’ data safe, but the point of Solid is the opposite. If it’s the users’ data, it should be their choice where to keep it. If they chose you as guardians of their data, that’s great. But if you don’t give them a choice, you’re keeping the data hostage.

As you mentioned, being a POD provider and an app provider are two different things. And it’s true that given the current state of the Solid ecosystem, a company like yours is forced to fulfill both roles because there isn’t any POD provider that is ready for the public. So, from the POD provider’s point of view, I agree with everything you said.

But when it comes to the app, the fact that you don’t let users choose their own POD renders the whole point of Solid useless.

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

I have to say, this is one of the things that tripped me up the most whilst checking out the app. As I said, I understand your position and why you decided to take this approach. But then, I don’t understand why you’re exposing users to these concepts they can’t enact.

And I still think this onboarding screen is misleading, because there is a button saying “experience the future now”.

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

This is also something I somewhat disagree with.

If we’re strictly talking about technology, sure, it’s an undeniable fact that BBC Together+ is a Solid App, because it uses the Solid protocol to move data around.

But, from the user’s point of view, I don’t think it’s a Solid App at all. @cbraun has mentioned that he’s been able to do some things with his data outside of the BBC, and that’s great. But I’m looking at the app from a user’s point of view, and I don’t see anything in this app that makes it different from any other app in the market.

If this is really a Solid App, where is my data? How can I access it outside of the BBC Together+ app? @Vincent also mentioned that he found his WebId in solid.bboxservices.net, but I haven’t seen any of that in the UI. So a user who understands what Solid is, but is not technical, wouldn’t be able to find this out. And even if they do, I don’t think they can use the WebId for anything because as far as I can tell, BBC Together+ is the only app they can use. At the very least, I expected to have access to a POD browser.

Just to be clear, as it stands right now, what do I have to do as a user to get my data? Do I have to send an email or something asking for a data export? How is that different from any other non-Solid App?

1 Like
32

how is what BBC is doing, warranting such criticism, different from any other combo implementation out there? im aware there are likely some “pure” SOLID implementations (someone please link a list here) … but im curious .

I havent heard the same criticism put forth towards @gibsonf1 regarding Trinity and GraphMetrix even though they are a combo implementation whereby you cant be interoperable with their apps by hosting your own pod elsewhere (a different scenario from BBC but still a question of “pure” solid implementation) .

1 Like
33

essentially the biggest players in the solid space currently are all doing centralized and integrated implementations … smaller players are building some more decentralized things assuming said infrastructure already exists .

1 Like
34

The difference I see with GraphMetrix is that it does allow you to see your RDF data and interact with other apps. For example, I have been able to log in using a TrinPod account into my own apps, and then find the data my app created in their POD.

Although I guess that’s looking at it like a POD. If we look at Trinity as a Solid App I would agree with you, but I hadn’t considered it because I just saw Trinity as functionality on top of their POD. I do understand that POD providers will have their own functionality, otherwise POD providers would just be faceless servers that respond to the Solid Protocol.

Also, the BBC has a much bigger audience than GraphMetrix, and I think the reason why more people is interested is that it is one of the apps that was supposed to bring Solid into the mainstream. But in my opinion, using BBC Together+ you can’t do anything that you wouldn’t be able to do with a non Solid App.

In any case, this is just my opinion. And maybe the reason why other apps haven’t received criticism is that nobody raised the issue. If you’re interested in talking about any other particular Solid product, I suggest that you open a new thread to talk about it.

3 Likes
35

We got more insight into the project in last Thursday’s Solid World. If you missed it, you can watch the full recording here: Solid World November 2022.

There is a demo of the onboarding and usage of the app that is about 2 minutes long at 06:37, in case you want to learn more about how it works.

Seeing the video, it solved one of my doubts which was how to add friends. As I could gather, when someone creates a watch party, they get a link they can share with their friends using 3rd party channels. They can then use this link to join the party, and you can add people from the watch party to your friend’s list. As far as I could tell, the friends’ profiles do not expose the webId nor any Solid-specifics either. So this reinforces my opinion that Solid is just an implementation detail and this app could be implemented without using Solid at all.

Other than that, there are a couple more things I’d like to mention.

The first one is they shared some of the results of their research, and there is one in particular I’d like to comment. At 21:05 they say one of the UX challenges was that “people’s attitudes to controlling data don’t match their behaviour”. Although I understand the point, I think there are a couple of problems with reaching this conclusion.

One problem is that even if most people wouldn’t enact control over their data, and they really trust BBC to keep it, there will always be a small percentage of people who don’t. And the point of Solid is precisely letting this small percentage of people do it without hurting the majority (I still think the UX can be as good whilst respecting data ownership). This is the same idea as making websites accessible. There is probably a very small percentage of people who have accessibility requirements, but that doesn’t mean that we shouldn’t make websites accessible.

Another problem is that this part of the user journey is probably the worst one to gauge whether people want to do something with their data or not. It’s all sunshine and roses when you start using a service, but it’s really when you want to switch to another service or make it interoperable with another that you would enact your data control.

Other than UX challenges, I also wanted to comment on the reason why they are not allowing 3rd party PODs to use their app. They replied to this specific question at 46:15 (and allude to some comments they made at 19:22).

One of the things they mentioned is that RDF data is already exposed in the HTML markup, and they encouraged people to check that out, so that’s great.

They also mentioned that the main reasons why they aren’t opening up the POD are the existing policies at the BBC and some UX challenges. I don’t think the policies are going to change any time soon, so I understand not opening their POD to 3rd party apps. But hopefully their policies don’t prohibit using 3rd party PODs in their app, so the main blocker should be UX challenges.

2 Likes