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

Reduce extension authorization scope #8

Open
yozlet opened this issue Dec 4, 2017 · 7 comments
Open

Reduce extension authorization scope #8

yozlet opened this issue Dec 4, 2017 · 7 comments

Comments

@yozlet
Copy link

yozlet commented Dec 4, 2017

The authorization request on installation asks for permission to "Access your data for all websites". This seems like a far wider scope than is necessary - at most, it should be accessing my data for pinboard.in, surely?

@Cito
Copy link
Owner

Cito commented Dec 5, 2017

That bothers me as well. I hate when apps require such scary sounding permissions - not only scary, but also ambiguous, since what is meant with "your data" in this permission?

The reason here is that Pinboard-Pin needs to know the URL and title of the page that you want to store on Pinboard and also must inject a small script into the page in order to get the description and keywords from the meta data to prefill the description and tag input fields.

If you have any suggestions how this can be done with less scary permissions, let me know. I'll also experiment a bit to see if that permission can be avoided.

@yozlet
Copy link
Author

yozlet commented Dec 6, 2017

Thanks for the fast response!

Of the features you describe, URL & title are obviously vital, but the other metadata less so. I have my own tagging scheme, so I don't think I'm interested in how the site has tagged itself. As for description, I'm guessing this is generally useful when pinning a site's front page, less so for individual articles, but I've never tried it so I don't know.

Note that I'm working on a sample size of one here, and I've not even used your extension yet because the permission requests put me off. It could be that this metadata is far more useful to most other people.

However, if my comments above don't sound too out-of-touch with reality, would it be possible to have the description & keyword filling be off by default, then request expanded permissions when the user turns it on in the settings? Obviously this depends on you being okay with the extended work this requires, and the insidious, often inadequate nature of "just make it a configurable setting" feedback.

@Cito
Copy link
Owner

Cito commented Dec 7, 2017

This is a good idea. Thanks for the pointer to the permissions API. I wasn't aware that it exists - seems it was added this summer and not yet available when I created the extension. But I appretiate very much that this is possible now. I don't like it either when apps require access to microphone and camera because there is some hidden feature for audio and video messages which I don't use anyway.

@Cito
Copy link
Owner

Cito commented Dec 8, 2017

I've now looked into this some more. In fact, the "access your data for all websites" is only necessary for running the script that extracts the description and keywords (from metatag or selected text). Making this optional, requesting only permissions for pinboard.api at install time and the permission for all other websites when the option is selected is in principle possible using browser.permissions. However, I'm currently blocked by a bug in Firefox which prevents requesting the permission from the options popup or about page.

@Cito Cito added the on hold label Dec 9, 2017
@Cito Cito self-assigned this Dec 9, 2017
@Cito
Copy link
Owner

Cito commented Apr 11, 2018

Note to self: Should revisit this since it has allegedly been fixed in FF 61.

@Cito Cito removed the on hold label Apr 11, 2018
@Cito
Copy link
Owner

Cito commented May 29, 2020

In FF 77 we now have optional permissions which probably can be used to implement this.

@Cito
Copy link
Owner

Cito commented Jul 26, 2020

Note to self: See also "Requesting the right permissions".

Also note that we now require an additional permission for the context menu, but it seems this does not trigger a permission request.

Also: Don't forget to update DEVELOP.md when this has been implemented.

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

No branches or pull requests

2 participants