Re: Cross-Origin Resources and Resource Timing

As part of the help can we also get them to validate the novelty of the 
attacks?  For example, I can think of at least 3 different ways to probe 
for timing information to a given domain using existing technologies 
(and that's without really putting any effort into it).

Thanks,

-Pat

On 9/14/2011 7:39 AM, Tony Gentilcore wrote:
> 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 12:12:00 UTC