Re: [Beacon] Off-line behavior, captive portals and error recovery

On Mon, May 19, 2014 at 11:07 AM, Ilya Grigorik <igrigorik@google.com> wrote:
>
> On Fri, May 16, 2014 at 4:50 PM, Kornel Lesiński <kornel@geekhood.net>
> wrote:
>>
>> - HTTP 305 Use Proxy, 401 Unauthorized, and 407 Proxy Authentication
>> Required should be treated transparently as for any other subresource.

For 401s I think we should simply make the request fail. If the user
has already left the page that sends the beacon, the browser isn't
going to want to open a username/password dialog for the old page.
That could too easily confuse the user into entering the wrong
username/password. Consider the following:

1. User goes to evilwebsite.com
2. evilwebsite.com sends a beacon to evilwebsite.com/gotyerpasswd
3. evilwebsite.com sets window.location="bank.com"
4. evilwebsite.com/gotyerpasswd waits 10 seconds before doing anything else
5. User sees bank.com
6. evilwebsite.com/gotyerpasswd sends a 401 response
7. Browser displays authentication UI on top of bank.com

We don't want step 7 to happen because there's a very large risk that
the user will enter his bank username/password into the dialog, which
would cause the username/password to be sent to evilwebsite.com.

We could still put up the authentication dialog if the user hasn't
left the website yet, however given that one of the main usecases of
sendBeacon is to send data as the user is leaving the page, that
doesn't seem worth optimizing for.

Especially given that it would introduce a race condition where the
authentication dialog may or may not come up depending on how fast the
server is that received the beacon, when the user navigates, and how
quickly the navigated-to website responds.

So I think we should specify that 401 responses should always be
treated as a permanent error.

The rest of the list seemed reasonable to me except for the
captive-portal one which I don't really have an opinion on.

A more tricky subject is offline though. I personally would prefer if
the UA queued any requests that were scheduled when the user is
offline and then return false. Up to some queueing limit of course, at
which point the UA should return false from sendBeacon.

So far we've decided to leave UA-limits unspecified and I see no
reason to do something else here.

However I believe that we elsewhere have talked about simply pushing
the responsibility of offline onto apps and always having the UA make
sendBeacon return false whenever the user is offline. But I would
prefer to not do that, although that is what the current Gecko
implementation does I believe.

/ Jonas

Received on Tuesday, 20 May 2014 18:08:41 UTC