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

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.
>
> - Other 4xx HTTP responses should be treated as a permanent error and the
> UA must not retry sending the beacon (If the script gathering analytics has
> been deleted the UA shouldn't be retrying unnecessarily and it would make
> sense for authors to reject requests with status 403/410 without having to
> pretend that the request was accepted.)
>
> - 5xx HTTP responses should be treated as a temporary error and the UA
> should retry(this often includes proxy and load balancer errors that are
> temporary.)
>
> - DNS lookup errors and TCP/IP connection errors should be treated as
> temporary errors and the UA should retry. First version of Server-Sent
> events spec made a mistake of defining DNS errors as a permanent failure,
> but in practice the DNS can be flaky when the device has a weak Internet
> connection.
>
> - 3xx HTTP responses should be treated as a temporary error and the UA
> should retry. The RFC 2616 says UAs MUST NOT automatically do POST after
> 301/302/303/307/308 responses, and sendBeacon doesn't have any use for the
> subsequent GET request, so there is no need for authors to ever use any of
> these statuses. However, this simple rule will catch captive portals that
> redirect all unknown URLs to portal's homepage (this isn't precluding more
> sophisticated captive portal detection by the browser or the OS, but at
> least gives some baseline).
>

This list looks reasonable to me.

The only caveat being that we shouldn't add any language around captive
portals. It may be the case that considering 3XX will catch most of those,
but that's not a guarantee. If you want to guard yourself against someone
injecting themselves in the middle... use TLS:

- Adding HSTS to your beacon URL would force the browser to default to TLS.
- Pinning the cert (HPKP) would ensure that someone doesn't inject
themselves with an invalid cert.

HPKP is still a work in progress, but both Chrome and FF have "preload
lists" [1] which you can use in the meantime.

ig

[1] https://blog.mozilla.org/security/2012/11/01/preloading-hsts/