Re: Implementing the web timing spec

On Mar 20, 12:38 am, Georg Maaß <[email protected]> wrote:
> 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.

   In this particular case, there are other similar ways to tell,
e.g.,
websocket's readyState changes from CONNECTING to OPEN. Another minor
point but timeout from dns and tcp handshake will also makes it harder
to tell
if user interaction is involved. (Timeout is more common on lossy
access links.)
In short, I am not sure if there is any "added value" from this spec
to what's already
out there.




>
> > 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.

   It doesn't take the timing info provided in this draft to figure
out if a service
has poor server/design. IMHO, it's more reliable to tell a poorly
performing
service by making it into an iframe and time its the loading time. In
fact,
I would argue this spec gives a tool to those companies and now they
can
find out whom to blame and what to do when they see poor user
performance.

   Security issues are important. The draft tries to export timing
information in a way that it's
useful for performance diagnostics but not enough to expose client
info/privacy. Should there
be conner cases, fix it we shall.


thanks,
Zhiheng