Re: [w3ctag/design-reviews] Web Share API (#179)

Hi David, thanks for taking a look!

> what's the value of [exposing](https://wicg.github.io/web-share/#dom-navigator-share) whether the user chose to share somewhere or cancelled, relative to the violation of any privacy expectation the user might have (that is, the user might not expect that whether they've chosen something at the choice of applications gets exposed back to the Web page)

Honestly this wasn't something we really considered. I think the value is probably pretty small but so is the privacy risk, and it just seemed like a logical thing to return (success or failure). Uses for this information are:

1. If you are showing some modal UI with a share button, share success could dismiss the UI while failure would keep it up. For example, at the end of a game, "You got a high score! <Share> <Close>" The user isn't forced to share, but if they do successfully share, the dialog dismisses itself. If they cancel the share dialog, we keep the dialog up in case the cancellation was by accident.
2. Just for collecting metrics on share numbers. You would not want to count cancelled shares.

Are there real privacy risks in exposing whether the user cancelled?

Are you similarly concerned with the provision that the [user agent may differentiate the three failure cases](https://wicg.github.io/web-share/#share-method) (no targets available, cancellation, or starting the target)? If there's concern about that, we could mandate that all the errors look the same. The only concern I can think of is that differentiating "no apps available" from "cancellation" could indicate what apps the user has installed in a world where there are only a very small number of share targets (just by whether it gets past the "are any targets available" step). Or in a future world where the site can filter by MIME type or something, the set of targets that can accept a particular MIME type. So it might make sense to combine "no targets available" with "cancellation".

If those two error cases are indistinguishable, I can't really see how an app could take failure as a definitive or even probable signal that a particular app is installed or not installed.

> are there possible share targets where success or [failure starting the target or transmitting the data](https://wicg.github.io/web-share/#dom-navigator-share) might leak other information about the user's configuration? (For example, if there were a common share target that failed if the user's username in that system plus the length of the share target were greater than 140 characters, then it would be possible to extract the length of the user's username.) Or is that intended to be avoided by the provisions about how [declining to receive the data](https://wicg.github.io/web-share/#h-share-targets) must happen immediately?

Spooky. No, that provision was not intended to prevent such a "scanning" attack, because it would still be possible for a target to "immediately" decide to accept or reject based on some stateful (private data) condition.

I don't think this would be a privacy problem if the error cases were indistinguishable, because it would be impossible to distinguish failure (app not installed, user cancelled, or revealing a bit-value-0 from private data) from success (revealing a bit-value-1 from private data, or a successful share to any other application). In light of this discussion, I'm happy to change "The user agent MAY differentiate between the three different causes of AbortError failure" to "The user agent MUST NOT differentiate between the three different causes of AbortError failure". But I would prefer to still allow the site to distinguish between success and failure.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/179#issuecomment-305424392