Re: Implementing the web timing spec

Srirang Doddihal wrote:
>> DNS time, connect time and so on is information that is interesting for the
>> end user, who may switch collecting this information on or off.
>
>
> It's not just the end user who is interested in this. A lot (most?) of
> people hosting webapps ask for this information.

I'm also interested in your account information to suck money from it. 
But you probably won't accept satisfying my interest to fetch your money 
by default. So their interest is no agrument.

>
> It should be off by default and should never be accessible to none chrome
>> because this is sensible information.
>>
>
> Why would you classify this as sensible information?

It gives a lot of information about infrastructure. Accessing DNS may 
cause proxy to first request for authentication, which all causes a long 
delay, because this requires user interaction. From point of view of the 
application all this is client side infrastructure, which must not be 
known to the application without explicit acceptance of the user before 
collecting this information.

If name resolution of the first request takes more than 10 seconds, I 
can assume that there is a proxy in between, which request for 
authentication, because otherwise name resolution usually does not take 
so much time. So timing information on that level is critical, because 
it exposes information about client side network infrastructure.

> This information is necessary to understand the end to end
> behavior/performance of  the web app as seen by the end user. So this is not
> for technicians trying to troubleshoot a connectivity problem, but this is
> for people hosting the websites who want to know the QoS as seen by their
> end users.

If they do not have a contract with the end user permitting them to 
collect detailed information about his infrastructure, they must not be 
able to collect any information related to other IP/port pairs than 
directly communicating with.

Additionally, if they do not have a contract with other involved hosts 
like DNS permitting them to collect such information, they must not do that.

> Only the browser can provide this information to the website and
> DOM is probably the best way to expose this information in a standard
> manner.

If I provide a server in the internet, why should I permit others to 
collect timing statistics and exposing them to third parties without 
being asked for doing this?

If others refer to resources on my server i.e. by embedding it into 
their web application, why should I permit them to collect and publish 
timing statistics about my server?

Embedding the external resource into the application makes it being a 
piece of the application and therefore also a target of desire to 
collect timing information. So the target also needs to be asked, 
whether it permits collecting timing statistics and to whom it permits 
collecting this information.

If timing information collected about my server is published this 
enables comparison to servers of competitors which might expose my 
server as a poor man server, which might cause potential customers to 
say, oh if that server is so poor, we don't make business with that poor 
company, even though the server might be not part of the business. So 
collecting such timing information is very critical. So each involved 
host must explicit grant collecting timing information telling who may 
access this information before collecting this information starts.