Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow apps to request permissions, and explain why #31

Open
james-martin-jd opened this issue Sep 4, 2019 · 9 comments
Open

Allow apps to request permissions, and explain why #31

james-martin-jd opened this issue Sep 4, 2019 · 9 comments

Comments

@james-martin-jd
Copy link

james-martin-jd commented Sep 4, 2019

As part of building the React SDK application, we recently added a "tic tac toe" game. The idea isn't that Solid now supports TTT, but rather to demonstrate to developers the best way to create a game that sends notifications, creates it's own data files, shares the data files in a collaborative way, and so on.

Because of this, the SDK application requires specific permissions. We create game files, then update the permissions for others to edit. We also create an inbox and change the permissions there so anyone can push notifications into it. For this reason, the app (and likely MANY apps) need Control permissions. However, this is not part of the default set of checkboxes when granting permissions, and additionally many people when using our test servers and deployed application at generator.inrupt.com had already visited previous versions, meaning they'd already granted now out-of-date permissions via the handy popup.

For this reason, we think it would be a nice addition to have the following features:

  • Ability to request certain permissions for my application and override the default checkboxes. My app knows it needs Control permission but currently doesn't have a nice way to indicate this.
  • Ability to pass over a string for each permission, so we can explain what we're using the permission for. Informing the user why the app needs Control for example.
  • Ability to re-request the popup, for example if the user attempts to do something requiring a missing permission.

That last one came up during testing, as some users (I believe Vincent and Michiel) had run the app prior to Control permissions being required, and couldn't receive notifications as Everyone was not set to the proper permission on the inbox. But they had no way of knowing it, so it just failed silently. Ideally, we could show the popup again saying "Hey you tried to do something that requires Control permission but you didn't give this app permissions, change it?"

@elf-pavlik
Copy link
Member

Ability to request certain permissions for my application and override the default checkboxes. My app knows it needs Control permission but currently doesn't have a nice way to indicate this.

I don't understand what do you mean by 'default checkboxes'. In #29 I suggest that person should have a way to chose which app they want to use to manage permissions for all the other apps, so we can't assume to much details about how this application UI functions.

Ability to pass over a string for each permission, so we can explain what we're using the permission for. Informing the user why the app needs Control for example.

👍 I thing we should have this as requirement. Since we talk about text presented to user it may also have some @solid/internationalisation-panel related aspects.

Ability to re-request the popup, for example if the user attempts to do something requiring a missing permission.

👍 It sounds related to #24 - general management of app authorizations, in that case changes initiated by application iself.


To clarify your general use case, I understand that user always wants to grant to application some subset of permissions they have for certain resource. Does it require application to know what permissions the user oneself has to that resource? Could it happen that application want to request permission which user onself doesn't even have?

@james-martin-jd
Copy link
Author

@elf-pavlik Regarding the "default checkbox" comment, right now the app permissions popup that is shown has 3 out of 4 of the permissions checked. What I am proposing here is that the application itself should be able to show what permissions it needs to function properly, instead of having 3 permissions checked automatically.

I'm approaching this from an application developer perspective, and we had several people not know they were missing permissions on our sample app because they had already granted incorrect permissions. We also had people who just click "Ok" assuming the popup will take care of everything they need, when in fact it didn't because the Control permission we needed was unchecked.

@elf-pavlik
Copy link
Member

elf-pavlik commented Sep 6, 2019

What I am proposing here is that the application itself should be able to show what permissions it needs to function properly, instead of having 3 permissions checked automatically.

and earlier

We also create an inbox and change the permissions there so anyone can push notifications into it. For this reason, the app (and likely MANY apps) need Control permissions.

I still lack clarity if we talk about user specific access modes in ACL files or app specific access modes - which to my knowledge we currently don't even have proposed way to express (maybe except doing it with acl:origin).

Maybe you could share two snippets with 'permissions' in question

  • one before intended changes
  • one after intended changes

As part of building the React SDK application, we recently added a "tic tac toe" game.
Because of this, the SDK application requires specific permissions.

I must admit lack of familiarity with mentioned React SDK. Given 'tic tac toe' app lacks specific permissions, with what app user will modify the permissions (and where those permissions get stored)?

I appreciate your patience with helping me clearly understand your scenario.

@james-martin-jd
Copy link
Author

My apologies, I lost track of this!

In this request I am specifically talking about application specific access modes, not user-based. Those are, in my opinion, two different things. The React SDK deals with both, but the application itself can help manage user-access permissions (either by displaying an error, or by granting access if appropriate).

I must admit lack of familiarity with mentioned React SDK. Given 'tic tac toe' app lacks specific permissions, with what app user will modify the permissions (and where those permissions get stored)?

The root problem is that the example app requires Read, Write, Append, and Control permissions for tic tac toe to work. This is due to many factors - Read is pretty obvious, as well as Write. We need Append control as we create notifications, and we need Control permission as well to grant access to your opponent.

Right now, with NSS pods, the trusted app dialog is displayed showing the 4 choices, and 3 are pre-checked by the dialog. They are Read/Write/Append. Control is unchecked by default. Many people have simply clicked "ok" and accepted these settings, but in fact we need all 4, and this breaks parts of the app. What I am asking for is a way for the app requesting the permissions to explain what they need (which it sounds like you agree with) but also perhaps give a list of permissions we want, to pre-check what we need. Either that, or uncheck everything by default, instead of providing a list of 3 permissions that may-or-may-not be correct.

@jaxoncreed
Copy link
Contributor

@james-martin-jd I'd say this is a feature request for NSS not a spec request.

The full solution to attenuated access control will be much more complicated, but if I'm understanding you correctly, this is something desired in the short term.

@james-martin-jd
Copy link
Author

@jaxoncreed yes, this is a problem we're currently having to work around in the SDK apps. Currently we show a little popup with a link to a dokieli doc that explains how and what permissions to set for the SDK to function properly. It's also an issue we've seen many, many people have, because it seems most people just rubberstamp the permissions dialog and select whatever is already checked by default.

@elf-pavlik
Copy link
Member

elf-pavlik commented Dec 11, 2019

I think we can take it as one of Use Cases here. For that it would come helpful to besides read, write, append, control access modes document what kind of information the app wants to access.

  • When it comes to sharing, it probably would also need to access some kind of contacts / address book information, only in read mode. If User has access to contacts in various group (organizational) storage instances, do we want app to also access those or only User's personal contacts, for example stored in certain location.
  • When it comes to sending notifications, what kind of notifications this app wants to send? Just notification that board was shared or also that opponent made move?
  • Does game use some dedicated inbox for sent and received notifications?
  • I understand that anyone can host a board and invite someone else, which means that Alice with app she uses would need to allow it to write 'tic, tac, toe moves' to any storage, since any of her friends could host a board and invite here to make moves.

All those question relate to three common aspect of permissions / authorizations

  • access mode - read, write, append, control
  • kinds of data - shapes which use types
  • location of data - LDP containers in solid storage instances

Often, for each 'kind' of data authorization will have specific access mode and sometimes location detail (or left global).

@james-martin-jd
Copy link
Author

That is a very good point. Some folks have commented that having to give an SDK-generated application Control permissions is "scary" because it can do a lot of things. Same with Write and Append. Really it only needs access to a few things (profile info, public and it's own app-specific inbox, and a few files it manages in its own folder).

@zenomt
Copy link
Contributor

zenomt commented Dec 19, 2019

Some folks have commented that having to give an SDK-generated application Control permissions is "scary" because it can do a lot of things.

i think that giving any app (other than a designated sharing-control app) the Control permission is scary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants