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

I think the spec should consider what happens regarding captive portals.
 Other specs have done so, for example the application cache:
http://www.w3.org/TR/2011/WD-html5-20110525/offline.html#changesToNetworkingModel
(section 7.7.6.4)

Any conditions where the user agent shouldn't send beacons needs to be
spelt out in the spec.  Even if it's obvious to a user agent how they
should react in these situations, it's not obvious to web developers what's
going on.

Luke


On 15 May 2014 14:21, Arvind Jain <arvind@google.com> wrote:

> Thanks Kornel.
>
> We have discussed many of these issues in the past (I think all of these
> except the captive portal issue). It'd be good to know what Mozilla has
> implemented re:
> 1) Do they persist beacons across restarts?
> 2) How big is the send queue?
> 3) Is there a timer after which the beacon is dropped?
>
> Re. captive portal detection, I think that is out of scope. Captive
> portals behave in many different ways and putting something in this spec
> about that would be odd. If a user agent is able to detect reliably it is
> not "really" connected and is behind a captive portal, it should not send
> the beacons. It doesn't seem like we need to spell it out in this spec.
>
>
> Arvind
>
>
>
>
> On Wed, May 14, 2014 at 1:08 PM, Kornel Lesiński <kornel@geekhood.net>wrote:
>
>>
>> I'm looking at the API from perspective of an off-line capable web app
>> such as http://app.ft.com. The app needs to collect analytics off-line
>> and some of the events collected are quite important and should not be
>> dropped, even if they cannot be delivered for a long period of time.
>>
>>
>> The specification only vaguely says UAs should make "best effort" to
>> deliver the beacons, but doesn't elaborate how persistent the messages are
>> and how much effort UAs should put into the delivery.
>>
>> The spec doesn't say whether beacons should persist across browser
>> restarts, or whether the beacons should be kept for minutes/hours/days or
>> weeks. I think the spec should be clearer how much guarantee there is about
>> beacon delivery to help all implementations be similarly (un)reliable.
>>
>> I'm concerned that very different persistence/error recovery strategies
>> of implementations will be a source of bias in analytics. If one UA gives
>> up after 3 tries in 3 seconds, but another UA persists beacons across
>> restarts and keeps retrying forever, then this will generate very different
>> picture when beacons are sent while the device is having network
>> difficulties.
>>
>>
>> The spec doesn't say whether UAs should take precautions against captive
>> portals. There is a risk that when a user is connected to a free Wi-Fi
>> hotspot that redirects all requests to a captive portal, then UAs may end
>> up sending beacons to the portal and wrongly assume they've been
>> successfully delivered.
>>
>> I think the spec should explicitly advise UAs to detect and avoid
>> submitting to captive portals (e.g. at very least treat 3xx HTTP response
>> as an error). I expect this to be important for web apps used on tablets
>> without built-in 3G — they may be used off-line most of time and
>> sporadically connect to public Wi-Fi hotspots. It'd be very unfortunate if
>> every such connection caused all analytics collected off-line to be lost.
>>
>>
>> And finally, the spec doesn't give implementors guidance how large the
>> send queue should be. I suggest advising UAs to make the send queue as
>> large as quota for localStorage (or use the shared storage pool), so that
>> authors can assume sendBeacon() is very reliable and they don't have to
>> implement their own backup storage.
>>
>>
>> To use this API in its current iteration I would have to treat it as
>> another version of XHR or Image.src hack, and need to keep queue messages
>> myself in localStorage and make AJAX requests to verify that the network is
>> usable before giving messages to sendBeacon, but this is obviously an
>> unnecessary burden and may defeat network utilization optimizations that
>> UAs could make otherwise.
>>
>> OTOH if the spec gave guarantee of persistence across browser restarts,
>> resiliency against prolonged off-line state and captive portals, and very
>> large send queue across all UAs, then the API would be much more useful and
>> I could use it without any wrappers and just fire-and-forget.
>>
>> --
>> regards, Kornel
>>
>>
>>
>>
>>
>


-- 
Luke Blaney
Labs developer, FT Labs [labs.ft.com | 0870 085 2038 | @ftlabs]

-- 

------------------------------
This email was sent by a company owned by Pearson plc, registered office at 
80 Strand, London WC2R 0RL.  Registered in England and Wales with company 
number 53723.