App whitelisting

[anon36056958]

Databrowser webapp

My $0.02: It seems like solid-panes from the data browser don’t have to go through the system of app authorization. That system of whitelisting apps was put in to prevent apps from messing up each others data, even though they might be given permissions by the WebId using them. That system seems to go against the spirit of permission-less innovation. For example, when you first use an app you get a screen that is sort of like an ultimatum – either I can access everything on your pod – or not…

and

Databrowser webapp

If app whitelisting becomes predominant, then the apps become a point of centralization.

[jeffz]

How do I prevent the WeStealYourData or HateMongersRus apps from accessing my data or spamming my pod?

[anon36056958]

That’s a really good question, I don’t have the answer to that…

…but neither do I want to see a consolidation to a small set of apps administered by a central authority.

I think it would be useful to ask what the parallel on the desktop would be.

[happybeing]

@jeffz

How do I prevent the WeStealYourData or HateMongersRus apps from accessing my data or spamming my pod?

If only there were some people around here who would engage with these kinds of questions.

[anon36056958]

We are asking them, because after all, its supposed to be the web we want :).

I myself am not too good at answering them but I’m not afraid to try (sometimes)

Anyway I thought allowed shapes for each public resource or folder were supposed to mitigate the need for some of that. Beyond that you could have subscription services you could defer to but that just kind of moves the point of centralization.

[A_A]

Regarding whitelisting, I think that it’s important for the UX to have a default data-browser app installed. For new users this makes it easier to get started, as they don’t have to choose the data-browser while starting.

This could be done per provider, and also doesn’t necessarily means that it’s completely whitelisted, setting it as a default should suffice for several use cases. So users could still switch or probably change it in the setup process. When we assume that we have multiple providers and that they give the user the choice to switch, I don’t feel like it will become a centralization problem.

[anon36056958]

Linked Data may make some kind of semantic firewall possible too. These could be more individualistic and adaptable than whitelists.

[MitziLaszlo]

You might be interested in https://github.com/solid/process/blob/master/panels.md#authorization-and-access-control

[anon36056958]

Thanks @MitziLaszlo. These issues also involve the interoperability panel.

I kind of think of myself as a voice of the average noob, and I don’t think they want that or are ready for it (although I think that, due to their task, and with due respect, they need it

I do want to be constructive, but unfortunately my ability to actually construct things is limited. I am finally learning not to promise things I can’t deliver.

So I like to just stir up trouble here occasionally. It would be nice to think that they are listening though

[HansCroteau]

@A_A

Regarding whitelisting, I think that it’s important for the UX to have a default data-browser app installed.

Agreed, but not blindly. I only agree to the extent that the browser does not contain some inherent, but currently unforeseen, means of exploitation which would make the objective of a decentralized browser, a moving target.

@anon36056958

Beyond that you could have subscription services you could defer to but that just kind of moves the point of centralization.

Agreed, but only in part. Noobs seek out third party apps because the finished product is bright and shiny, as developed by a team of experts. But decentralization requires a “trustless” system. Noobs either trust skilled experts, or become their own experts. Yet jacks of all trades are the masters of none. Financial incentive motivates masters, but inversely undermines trust. Note that this is a “sliding scale”, not a binary choice.

My own $0.02: Define the fundamental elements (as best we can) separately from those elements which are optional. Allow noobs to rely on those fundamental elements as a starting point to cast votes for the apps they wish to incorporate. If its fundamental, then it’s applied to the entire winning population, but not to the group who did not vote for it. If it’s optional, it appears in a whitelist made viewable only to the group who cast the winning votes. E.g., think Red States and Blue States. In an analog nation State, we all have, quite unfortunately, only one President. In a digital world, we reserve the freedom to say… “that’s not my President”.

@anon36056958

I am finally learning not to promise things I can’t deliver.

@anon36056958

I kind of think of myself as a voice of the average noob

Indeed; based on our individual strengths, it’s up to us, the Solid team, to lead the way for noobs, but we must be cognizant of our weaknesses. We must not unwittingly influence them back into a centralized system. @anon36056958 I will help you be the voice of the average noob. Where I am weak, I will seek out your strengths. Where you are weak, feel free to lien on me. BTW - That offer is extended to the entire Solid community.

[anon36056958]

With the first iteration, the Solid Protocol, Solid will be a data hub that you can also subscribe to for changes. It may be able to filter data according to a shape or shapes you provide, and only data conforming to those shapes gets written.

Probably with later iterations it will be able to do more active processing, and filter things that shapes alone can’t filter. For example a more complicated phrase or paragraph or series of such might alert you to something that isn’t acceptable, and it might be detected with a Sparql query, whereas the same thing might get past a simple shape. Black or white lists won’t be enough. Somebody that sold you one thing that worked out well might have a conflict of interest when it comes to another thing.

These kind of filters will need to be very individual and built up from experience or advice. It would quickly get too complicated for simple lists, especially when and if Solid becomes something like a virtual assistant that can also process speech.

The infrastructure for all that will take a long time and need a lot of experts to build.

[HansCroteau]

On filters, I agree with @mikeadams1. Solid should not attempt to reinvent the wheel by altogether replacing Facebook, Twitter, Instagram, etc. Using a Solid POD should not prevent access to these platforms which users are most familiar and comfortable with. But in order to connect a Solid browser to Facebook, all words and images could be “filtered” through a process such as the dual leveled one that @anon36056958 suggests.

At least one “test” could be the difference between fact and opinion. Users are entitled to their own opinions, but not to their own facts. So when a user views a Facebook page through a Solid “filter”, controversial words or phrases could appear in red, while words or phrases detected to be factual could appear in green. Because it is a sliding scale, when a word or phrase is a mix of controversy and facts, then the word could appear in yellow. Right clicking on the word could display the hierarchical tree structure which the algorithm used to choose the color, thus allowing the user to quickly identify the logic behind the provenance of that data.

[anon36056958]

I like the idea of the visualization. That kind of thing will increase understanding. But I don’t think there could be a one size fits all filter for facts. Those kinds of filters will have to be built or adopted individually by each pod owner, from their life.