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

Address long-running vs. session-based permissions #6

Open
johnpallett opened this issue Sep 4, 2018 · 6 comments
Open

Address long-running vs. session-based permissions #6

johnpallett opened this issue Sep 4, 2018 · 6 comments

Comments

@johnpallett
Copy link
Contributor

johnpallett commented Sep 4, 2018

An explainer should outline the concerns of an AR session soliciting permissions and gaining access to system resources (e.g. microphone, camera) for longer than the duration of the AR session, that the site might use later for other, non-AR purposes.

@johnpallett
Copy link
Contributor Author

johnpallett commented Sep 4, 2018

If an AR experience offers resource permissions to a site for longer than the AR session exists, then one example threat vector could be as follows:

  1. A site offers an AR sticker to attract users and incent them to grant permissions for that experience
  2. The user grants permissions (e.g. for the camera) within that context, potentially not realizing they are permanent, and later forgets that they were granted
  3. Later the site incents users to revisit (e.g. for other reasons) and uses those resource permissions to capture compromising information

@blairmacintyre
Copy link

By "permanent" do you mean "if I grant this site permission once, it has it forever?"

Wouldn't this be an option, and wouldn't a dialog box on a reasonable browser warn against such a thing? Certainly, current permissions (mic, camera, location) aren't permanent by default.

Also, I'd like to raise another concern, namely "permission based on site, not URL". Certainly, both might be possible, but site permissions seem dangerous. I certainly wouldn't even want it possible (for example) to give long lived permission to a site like blogspot.com or glitch.io or wordpress.com ...

@johnpallett
Copy link
Contributor Author

re: "site" - that's an important point. If I understand correctly the Permissions API provides information relating to the origin, not the top-level domain - so john.blogspot.com would be different than blair.blogspot.com.

However, the entire design of the site could change, which is a potential concern. For example, excitingstuff.badactor.com could offer an AR sticker one week, gain permissions, then completely revamp their user experience to offer free music, but really use those permissions in bad ways. Unless the user was paying close attention to which origins had which permissions, they probably wouldn't realize it was the same origin.

@johnpallett johnpallett changed the title Address permanent vs. session-based permissions Address long-running vs. session-based permissions Sep 4, 2018
@johnpallett
Copy link
Contributor Author

re: "permanent?" - different user agents have different rules regarding the duration (or permanence) of permissions, and you're right that it may not be 'permanent'. I've updated the title and original issues to reflect that this is a threat vector in the case of permissions granted for longer than the AR session.

Note: The threat vector above is intended to highlight that AR could be used as a strong user incentive to gain permissions (regardless of how long those permissions last).

@peterclemenko
Copy link

I have to agree with @johnpallett. That being said, also different pages on a domain could be problematic as well. For example if a user authorizes vulnerable.lol/goodpage and an attacker finds a stored xss on vulnerable.lol/badpage, or if a user authorizes content on cdn.lol/good but cdn.lol/bad is used by an attacker, that needs to be considered as well. Don't even get me started on ad network vulns and how swiss cheese they are security wise. That could cause major issues down the road with malicious entities and malicious entity injection.

johnpallett added a commit that referenced this issue Oct 12, 2018
Added section on Permissions and User Consent which includes perception of camera access, and considerations for permissions.

This addresses issues #3 and #6
@johnpallett
Copy link
Contributor Author

I've added #15 to address this issue, PTAL and comment!

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

3 participants