W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2013

Re: [Beacon] spec feedback + few suggestions

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 30 Oct 2013 14:24:57 -0700
Message-ID: <CA+c2ei_cNh_X=fRKbqcY+jJBU4LevKHNfPWm77TyUQSTOwBxOw@mail.gmail.com>
To: Chase Douglas <chase@newrelic.com>
Cc: Jatinder Mann <jmann@microsoft.com>, Ilya Grigorik <igrigorik@google.com>, public-web-perf <public-web-perf@w3.org>
On Wed, Oct 30, 2013 at 12:04 PM, Chase Douglas <chase@newrelic.com> wrote:
> On Wed, Oct 30, 2013 at 11:36 AM, Jatinder Mann <jmann@microsoft.com> wrote:
>>
>> > Beacon API should limit size of send payload to <TBD> KB
>>
>> I agree that we should add a limit. Iíve heard feedback where some folks
>> were hoping to use this API to do large background uploads. Adding a limit
>> would prevent this kind of abuse of the API. What is a decent limit?
>
> Why is it the spec's responsibility to set a limit? Shouldn't this be up to
> the website developer to decide what is reasonable? A W3C spec just isn't
> the right place to try to limit the functionality of the web in the name of
> safety.

I'm sorry but this is just plain wrong. It would be gravely
irresponsible of us to create a spec which doesn't take security into
consideration. If a spec can't be implemented without sacrificing user
or server security then it's just a plain bad spec.

Implementations won't be willing to use a lot of bandwidth after the
user has left the page. A key part of the security model of the web is
"it's safe to go to any page. If it uses up too much system resources,
simply leave it".

If pages could do tons of uploads after you leave the page then we
break that security model.

The only way to enable that would be to use prompting "this page wants
to run in the background", and that's clearly not something we want to
force upon all Beacon users. I agree that background uploads is an
interesting use case, but the security model is different enough that
it's better handled separately.

For larger uploads you also want to handle things like resuming
uploads that failed partway through, which plain HTTP can't handle. So
for the foreseeable future you need to have application-specific logic
anyway.

> I think it makes sense that browser implementations have limits. But
> implementation-specific variability can change as needed over time. Specs
> can't be changed as easily.
>
> Could we add a method for scripts to ask what the implementation limits are
> (both size and frequency)? We're using query strings to send data in certain
> places, and figuring out what will fit into query strings is annoying.

If the limits aren't specified it means that authors won't be able to
depend on what works and what doesn't work. Being able to depend on
such things is the whole point of having an API. Asking authors to
remember to check what the limits are of the specific browser/user
seems bound to lead to bugs.

The usecase here isn't generic background uploads. The usecase here is
being able to send signals to the server in a way that is low cost to
the user (in terms of bandwidth and battery). That usecase we can
solve with a much simpler API than would be required to support larger
uploads.

/ Jonas
Received on Wednesday, 30 October 2013 21:25:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC