I thought the group might want to take some time to look at this, would love to hear peoples thoughts.
Take the Data Privacy route…
2 Likes
Continuing the discussion from BBC R&D Data Privacy Project:
Very interesting, I’d try one. Do you have to backup the box though?
1 Like
Yes agreed.
The same thought crossed my mind. How do you backup/restore, what is the box is damaged or stolen.
1 Like
Just for some easier to digest information, this is a blog post they have written which also says they are basing this on Solid, so that’s made it very very interesting
4 Likes
@james I think the BBC needs to re-align themselves a bit first, and then support a single / group / family pod for everyone who pays the BBC license fee; Solid in my view needs some supporting feature stacks, but if the BBC sponsored devs to create a core set of apps, that, in my opinion would be really great! almost as cool as the BBC computer in every schools initiative back in the 80’s!
1 Like
This would be centralisation. IMO we need to decentralise these services in order to obtain autonomy, and the ease with which folks are willing to slip back into centralised systems illustrates why the server and services model is toxic to decentralisation.
I’m assuming the motivation here might be:
- handing management to a third party is the only way to scale server based pods
- we can trust the BBC
I’m not happy trusting the BBC or any centralised entity because they become targets, they change, there people in charge change, government’s changes etc. The BBC already forces me to provide an email and be logged in to use iPlayer. None of that is necessary, but is a way for them to collect data on users. So I am effectively unable to use iPlayer despite being a license payer unless I’m willing to let them monitor and store information on my viewing. Once they had a lot of Solid users, I don’t believe we can expect them to start respecting privacy.
The best way to protect against an ‘attack’ is to reduce or eliminate the reward/incentive, which is why decentralisation is important.
2 Likes
It seems like the only pods that you would be happy with (no pun intended), would be on your local machine. So Solid would be a local thing and not outside of your operating system. There would be no collection or aggregation associated with any person or group outside of your OS, they would all just be resources treated individually. So if say the BBC or someone wanted to help you create a pod that focuses on them they would have to do it with an app you download from somewhere. Or maybe I’m missing something.
Sorry but I’m still stuck in the last millennium 
1 Like
I won’t be happy until we solve the problems of centralisation, privacy, security, surveillance, data breaches, harvesting and selling our data etc!
What I’m saying is that pods as a service is a problem. If you agree I’m pleased because it is rarely acknowledged here except by people passing through. I don’t think we should accept that just because that’s all that’s possible right now.
So I’ve been exploring using p2p storage and Safe in particular as a way to deliver pod storage that is entirely secure and under the owner’s control, without the need to self host or rent a server.
I demonstrated a bare bones version of this on an early Safe Network test network and hope to expand on that again when Safe and Solid are product ready.
If the BBC or anyone else want to create a Solid app that’s fine, they can host it anywhere and anyone with a Solid pod somewhere else can choose to use it. That’s a different issue.
2 Likes
Yes, I agree that pods as a service are a problem, mainly because they can become a target of attack.
But if all the resources outside your OS are treated individually, then some must describe collections of other resources. Then these resources which describe collections of resources are a form of centralization too, and can become a target. So the difference is…? Maybe the difference is in the surface area of a read only resource compared to that of a pod. So it might be more accurate to say that the difference is not so much in the decentralization but in the complexity of each thing out there in the web.
1 Like
Great discussion!!
I hear the argument for a completely decentralised approach and the advantages of that are clear, but there are clear disadvantages too. Primarily simplicity. The stellar success of smartphones isn’t just their closeness but how they simplified the computing experience and opened it to so many parts of society who would not have engaged before.
If Solid and PODs are not as equally simple and transparent to the user then it will never be a success. Complex setup of a POD or even adding a physical device to your personal network are, I think, steps too far.
That’s where I see a ‘trusted’ brand like the BBC having such an impact. If they can legitimise and promote the concept of Solid and simplify its use then it really can start to build a head of steam.
Data is always going to be the target of those who wish to steal it, and whilst a central repository will be an increased target they also have an increased budget to secure that data (declaration of interest here I work for MarkLogic who provide secure DB and graph technology).
The power of Solid as I see it is a centralised standard that the public can have trust in, hopefully the simplicity to implement and the interoperable nature, that should allow you to seamlessly move your data from one source to another if you lose trust in them.
1 Like
I would like to respond a bit on the tracking element but just want to clearly state my skin in the game here in case anyone from the BBC is reading! I work for MarkLogic who provide database technology and the BBC is a customer, but we do not do anything with them in the iPlayer/tracking/recommendation space. So this is just my personal thoughts and no insider insight!
If the BBC do not start ‘monitoring’ that data then they will become the Kodak of the media world!! All media sources are gathering that data and are using to transform their business. The BBC can not afford to be left behind or they will perish. They do not have to use that data to target advertising or similar, that would be a step too far, but they have to drive their future commissioning on real world data or they will be the only media organisation not doing so! Public broadcasting does not cut them off from the demands of a modern audience. Just my opinion.
I agree and you’ll find me saying not just this but that we need to deliver solutions which are better, trivial to adopt, easier to use etc., and this is the kind of p2p solution I’m working to deliver. If you don’t think we can do that with p2p, hop over to the Safe Network forum and we’ll show you what’s coming in that area, and I can point you to a couple proof-of-concept demos showing Solid apps and concepts (such as WebID) working on the same platform.
Accepting the BBC as a trusted brand is a poor option now and set to get worse. But it is the principle rather than the entity (BBC) that’s the problem IMO. If we compromise on such a key aspect as centralisation, we’ve lost before things get adopted.
It’s the same with the NHS as a trusted brand. Only very recently the Doctor patient relationship was confidential and sacrosanct in the UK, but government and corporations have found they can push these boundaries and people haven’t got the awareness or collective ability to challenge or prevent them. If we let the NHS brand be used in the same way, it will be no different from any other bait and switch. Play nice to start, while gradually shifting the goalposts from being user-centric to user-exploitative.
We can solve this with p2p solutions that are easier to use than Solid as currently envisaged. There are still quite a few areas of friction in adoption and use, and also in app development and I’ve seen improvements on key areas of this already in Safe’s p2p system. It has its own adoption challenges too, so those are being worked on. But my point is that p2p can be easier, more functional and decentralised, and it can have Solid’s approach to inter-operability and decoupling of apps and services from your data, and even actual Solid apps using it.
EDIT: on your point, the business case for the BBC wanting/needing to track users. I agree, there’s a business imperative, but that is the problem not a reason we should succumb to it as users, enable it by using it as a platform for adoption of Solid, etc. The point of Solid is to give people the control to not have to succumb to this. If the BBC can’t compete, that’s fine. We should be giving users an alternative to Netflix or a bad-BBC, not going along with it because we give up on solving the problem we started with.
1 Like
If its the case that pods will only be local, either in the browser or in a local executable, then if you want to use a pod from the BBC or somewhere, you would have to find a read only resource for it out on the web and build the pod corresponding to it locally with a trusted app.
-edit-
So I guess there would need to be an ontology for creating a pod
I don’t understand the issue you are putting here. If a pod is local, it is isolated, but I’m not aware of a proposal which involves pods being inaccessible. The pods we’re discussing must be accessible whether they are provided by Inrupt, the BBC, or yourself, and that’s what I’m talking about. In all those cases anyone can create an app, and if your pod is accessible from the web, it can be granted access to your pod.
You would create the pod locally, for your own use, to use as an interface to the data out on the web. Others would use the same pod description on the web to create their own local pods, which would be the same or similar to yours.
-edit-
So no pods out on the web, only pod descriptions.
-edit #2-
The data is still on the web, your local pod is just the interface to it.
replied in new topic: