Skip to content

Don't allow the caller to distinguish different failure modes #29

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

Closed
mgiuca opened this issue Jun 2, 2017 · 0 comments
Closed

Don't allow the caller to distinguish different failure modes #29

mgiuca opened this issue Jun 2, 2017 · 0 comments

Comments

@mgiuca
Copy link
Collaborator

mgiuca commented Jun 2, 2017

Raised by @dbaron on the TAG review.

There is a minor privacy issue in distinguishing between "no apps are available" and "the user cancelled the share"; if only a handful of popular targets exist for a particular payload (especially if we add new share types that might have specialized handlers, e.g., for rare MIME types) then a malicious site could use navigator.share to check whether those apps are installed, based on the response string.

Also, in our current Android implementation, we are totally unable to distinguish between "no apps are available" and "the user cancelled the share". Therefore, let's just remove this provision. I won't go as far as to explicitly bar the user agent from distinguishing these, but add a note under security considerations.

mgiuca added a commit to mgiuca/web-share that referenced this issue Jun 2, 2017
Added a security consideration that implementations should be careful
about exposing this information.

This isn't a technical change, but changes a weak recommendation *to*
differentiate error cases to a weak recommendation *against* it.

Closes w3c#29.
mgiuca added a commit to mgiuca/web-share that referenced this issue Jun 2, 2017
Added a security consideration that implementations should be careful
about exposing this information.

This isn't a technical change, but changes a weak recommendation *to*
differentiate error cases to a weak recommendation *against* it.

Closes w3c#29.
@mgiuca mgiuca closed this as completed in #31 Jun 2, 2017
mgiuca added a commit that referenced this issue Jun 2, 2017
Removed note about distinguishing between different error cases.

Closes #29.
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

1 participant