Re: Define return value for cancelled/missing session for startSession/joinSession (#20)

Hi Anssi,

I found the following Chromium policy on the fingerprinting issue [1]. If I
read it correctly, we should be fine if returning the reason for failing
the promise to the page. I still think giving distinct error codes would be
useful for developers at least for debugging and may even help the page UI
to be more informative to the user.

WDYT?

Anton.

[1]
http://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-isn-t-passive-browser-fingerprinting-including-passive-cookies-in-Chrome-s-threat-model-

On Mon, Sep 22, 2014 at 1:27 PM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> Hi Anton,
>
> On 17 Sep 2014, at 17:07, Anton Vayvod <avayvod@google.com> wrote:
>
> > I think not rejecting a promise is inconsistent with the promise design
> and purpose.
>
> Generally speaking, it is fine to have a promise that never rejects. We
> happened to have a discussion recently on this particular topic in the
> context of another spec.
>
> > Leaving the promise in a hanging state makes it unpredictable and leaves
> the site in the hanging state too. The website will have to be always ready
> for it to succeed because there's no way to distinguish between "it takes
> some time to connect to the device" and "starting the session failed”.
>
> Many APIs that plug into hardware capabilities (e.g. the Geolocation and
> getUserMedia APIs) work like that, so there’s precedence for this.
>
> The implication of this design is that it forces web sites to not put such
> APIs on the critical path. For example, it would be a rather bad UX if a
> maps app would refuse to run if the user did not allow it to access
> Geolocation. OTOH, a web-based navigation app would probably be less useful
> without Geolocation, but I think the user should still be able to open such
> an app even if she’d not want to share her location.
>
> IOW these APIs succeed/resolve or fail/reject only after getting the
> user’s express consent. I suggest we do not divert from this best practice
> without good reasons.
>
> A good reason would be a valuable use case. It could well be that we
> cannot apply the existing design patterns for this API, and that’s fine,
> but I’d like to be sure we document the reasons clearly in such a case.
>
> > I think rejecting the promise doesn't give anything out about the user.
> The UA could show an additional message if it's actually a connection
> failure (i.e. with an advice on how to troubleshoot the problem).
>
> If we leave it to the user agent to decide when to reject and for which
> reason, would the rejection provide useful information to the web developer?
>
> If we’d need to disclose the reason, what type of reasons would make sense
> without disclosing too much information?
>
> Thanks,
>
> -Anssi