Re: Cross-Origin Resources and Resource Timing

This is critical to get right. Like James said, we can't do anything
that would encroach on privacy, but like the other performance experts
on this thread have noted, the feature isn't useful if common
use-cases are blocked. Even in the spec's current state (with third
party detailed timing information guarded by a CORS-like header) there
are unanswered privacy questions[1] preventing us from moving forward
with a WebKit implementation. So really folks with performance
interests and folks with privacy interests are both unhappy with the
current state.

The problem is that no one in this group is an expert on web privacy,
user tracking, statistical fingerprinting, etc. So, we have reacted to
address concerns that have been raised over time without a serious
enumeration of the valid novel attacks that could be available with
detailed timing information for subresources.

A good way to work through this seems to be to compile a list of novel
attacks that could work with timing information. We can engage the
experts on the Privacy Interest Group (public-privacy@w3.org) and Web
Security Interest Group (public-web-security@w3.org) to help.

Then, working from this list we can determine the minimal set of
guards (e.g. cross-origin, https, etc) we need to introduce into the
spec to prevent any concerns. This list of potential concerns as well
as how the spec addresses them should be captured in Section 6 [2] to
avoid rehashing any of this unnecessarily.

-Tony

[1] http://lists.w3.org/Archives/Public/public-web-perf/2011May/0102.html
[2] http://w3c-test.org/webperf/specs/ResourceTiming/

On Wed, Sep 14, 2011 at 11:34 AM, Bryan McQuade <bmcquade@google.com> wrote:
> This is a good example. I agree that we don't want to leak the details of
> secure sites like banks, so opt-out for those sites makes sense. However I
> recommend that we opt in all HTTP resources to help developers and ops folks
> understand exactly what makes a page load slow.
> I've heard a number of people in the web perf community express great
> disappointment when they find out that third party resources are opted out
> by default. Despite our best intentions, the header opt-in approach just
> isn't going to get adoption, and it allows slow providers to continue to
> hide their latency. If a third-party resource provider knows their service
> is slow, they have no incentive to turn on the header, and they can continue
> to hide their latency from the web community. Their timing data won't show
> up in web perf monitoring systems, allowing them to continue to make the web
> slow w/o any accountability.
> I recommend changing the spec to opt out HTTPS resources by default, and to
> opt in HTTP by default (no header needed).
> Do others on this thread support this proposed change? If so, please speak
> up now!
>
> On Tue, Sep 13, 2011 at 1:51 PM, James Simonsen <simonjam@chromium.org>
> wrote:
>>
>> On Wed, Sep 7, 2011 at 2:18 AM, Alois Reitbauer
>> <alois.reitbauer@dynatrace.com> wrote:
>>>
>>> Getting the overall time is already helpful while it makes diagnosing
>>> problems really hard missing the details. I have to say I am no security
>>> expert, so I am not the right person to judge the security implications.  It
>>> might be a good idea to state the security concerns in a non-normative
>>> section. As Pat pointed out third party providers will have to be convinced
>>> to support the new header. Having a strong reference like a W3C standard
>>> would be helpful here.
>>
>> The main attack is determining if a user is logged in to a third party
>> site. If they include a resource from a third party site and see that it
>> loaded quickly, for instance because an HTTPS connection already existed,
>> then they can learn things like which bank the user uses.
>> We are trying to make this useful for developers, but our users' privacy
>> comes first.
>> James
>

Received on Wednesday, 14 September 2011 11:40:23 UTC