New Feature - Resource Timing
Hello webkit-dev, The W3C Performance WG has been working on a Resource Timing spec. The spec is starting to stabilize and we'd like to start landing it in WebKit too. Resource Timing is a follow up to Navigation Timing, which is already in WebKit. Resource Timing allows site developers to collect detailed network timing information for the subresources they load. The data is exposed through the window.performance namespace and we expect developers to ping this information back to the server with their other analytics data. For security reasons, the spec limits the detailed information to same-origin resources, but there is also a provision for a CORS-like header to allow cross-origin resource timing. Resource Timing will be behind ENABLE(WEB_TIMING) since it relies on some of the same infrastructure as Navigation Timing. We can add an additional ENABLE to keep Resource Timing separate from Navigation Timing if that's desired. The current draft of the Resource Timing API is here: http://w3c-test.org/webperf/specs/ResourceTiming/ A meta-bug to track the necessary work is here: https://bugs.webkit.org/show_bug.cgi?id=61138 Please post any feedback. Thanks! James
Seem like this new web-facing API would provide more data for sites wanting to do user fingerprinting, even when cookies etc. are disabled. Simon On May 19, 2011, at 6:14 PM, James Simonsen wrote:
Hello webkit-dev,
The W3C Performance WG has been working on a Resource Timing spec. The spec is starting to stabilize and we'd like to start landing it in WebKit too.
Resource Timing is a follow up to Navigation Timing, which is already in WebKit. Resource Timing allows site developers to collect detailed network timing information for the subresources they load. The data is exposed through the window.performance namespace and we expect developers to ping this information back to the server with their other analytics data. For security reasons, the spec limits the detailed information to same-origin resources, but there is also a provision for a CORS-like header to allow cross-origin resource timing.
Resource Timing will be behind ENABLE(WEB_TIMING) since it relies on some of the same infrastructure as Navigation Timing. We can add an additional ENABLE to keep Resource Timing separate from Navigation Timing if that's desired.
The current draft of the Resource Timing API is here: http://w3c-test.org/webperf/specs/ResourceTiming/
A meta-bug to track the necessary work is here: https://bugs.webkit.org/show_bug.cgi?id=61138
Please post any feedback. Thanks!
On Fri, May 20, 2011 at 3:17 AM, Simon Fraser <simon.fraser@apple.com>wrote:
Seem like this new web-facing API would provide more data for sites wanting to do user fingerprinting, even when cookies etc. are disabled.
Good point. To my knowledge this is the most thorough explanation of the issue: http://sip.cs.princeton.edu/pub/webtiming.pdf Unfortunately, the techniques mentioned in that paper are all possible without navigation or resource timing. It is also highly unlikely that anything can be done to prevent such attacks (beyond, say, artificially slowing network requests in the same way encryptions algorithms are sometimes slowed). No one has yet identified a new attack vector, but that doesn't mean one doesn't exist. Given the concern, perhaps this feature should have a run time enable guard underneath the ENABLE(WEB_TIMING) compile guard. This would give embedding applications the flexibility to enable/disable via a user preference.
Simon
On May 19, 2011, at 6:14 PM, James Simonsen wrote:
Hello webkit-dev,
The W3C Performance WG has been working on a Resource Timing spec. The spec is starting to stabilize and we'd like to start landing it in WebKit too.
Resource Timing is a follow up to Navigation Timing, which is already in WebKit. Resource Timing allows site developers to collect detailed network timing information for the subresources they load. The data is exposed through the window.performance namespace and we expect developers to ping this information back to the server with their other analytics data. For security reasons, the spec limits the detailed information to same-origin resources, but there is also a provision for a CORS-like header to allow cross-origin resource timing.
Resource Timing will be behind ENABLE(WEB_TIMING) since it relies on some of the same infrastructure as Navigation Timing. We can add an additional ENABLE to keep Resource Timing separate from Navigation Timing if that's desired.
The current draft of the Resource Timing API is here: http://w3c-test.org/webperf/specs/ResourceTiming/
A meta-bug to track the necessary work is here: https://bugs.webkit.org/show_bug.cgi?id=61138
Please post any feedback. Thanks!
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
20.05.2011, в 1:55, Tony Gentilcore написал(а):
Given the concern, perhaps this feature should have a run time enable guard underneath the ENABLE(WEB_TIMING) compile guard. This would give embedding applications the flexibility to enable/disable via a user preference.
Presumably the embedding application would need to require explicit user consent to enable the feature. What incentive will users have to enable it? For other privacy sensitive features (be it cookies or geolocation), there is a clear benefit to gain from them. - WBR, Alexey Proskuryakov
Presumably the embedding application would need to require explicit user consent to enable the feature.
My conclusion was different. Given that the timing based privacy attacks are demonstrable without the interface, I thought it reasonable to enable-by-default with a hidden pref to disable. But this is based on the assumption that we aren't actually exposing any new private information. Am I missing an exploit here?
20.05.2011, в 10:10, Tony Gentilcore написал(а):
Presumably the embedding application would need to require explicit user consent to enable the feature.
My conclusion was different. Given that the timing based privacy attacks are demonstrable without the interface, I thought it reasonable to enable-by-default with a hidden pref to disable. But this is based on the assumption that we aren't actually exposing any new private information. Am I missing an exploit here?
I'm nowhere near to being an expert here. The reason I'm worried is that this API provides very precise timing data, potentially making fingerprinting and information disclosure much more reliable in practice. - WBR, Alexey Proskuryakov
On May 20, 2011, at 10:10 AM, Tony Gentilcore wrote:
Presumably the embedding application would need to require explicit user consent to enable the feature.
My conclusion was different. Given that the timing based privacy attacks are demonstrable without the interface, I thought it reasonable to enable-by-default with a hidden pref to disable. But this is based on the assumption that we aren't actually exposing any new private information. Am I missing an exploit here?
I understand that we have to keep a balance, and statistical fingerprinting is already dismayingly effective without any new features. However, "enable[d]-by-default with a hidden pref to disable" sounds like an extremely weak approach to protecting user privacy. Is it possible to find experts on the topic of statistical fingerprinting, as well as security experts in general, who could review this API? Things I'd really like to know are: - Does this feature, as designed, increase the effectiveness of user fingerprinting, assuming the user is running something like private browsing or incognito mode, or is regularly deleting site data? The relevant question here is marginal increase in effectiveness - are things worse with this feature than without? - Presumably some known statistical fingerprinting techniques can be mitigated, if not always than at least in private browsing mode. If that was done, then would this timing feature provide an additional fingerprinting vector? - Could this feature directly reveal otherwise hard-to-guess information about users? - Can this feature be used to aid timing-based security attacks? I would really like to see this kind of review done ahead of time and delivered to the Working Group. My worry here is that the feature may have fatal flaws as currently designed, or perhaps even in the basic concept of its functionality. If that's the case, then we'd certainly want to find out before we get locked into it. Perhaps some of the privacy risks can even be mitigated, such as by returning fake or random data in private browsing mode. I can ask some of Apple's security experts to review with a mind to these questions, but I'm wondering if there are other independent experts we could ask. My preference would be to tread very carefully around anything that could be perceived as a privacy risk. Regards, Maciej
I've forwarded these questions on to the working group: http://lists.w3.org/Archives/Public/public-web-perf/2011May/0102.html In the meantime, we'll hold off on landing anything until we have satisfactory answers. -Tony On Fri, May 20, 2011 at 6:51 PM, Maciej Stachowiak <mjs@apple.com> wrote:
On May 20, 2011, at 10:10 AM, Tony Gentilcore wrote:
Presumably the embedding application would need to require explicit user consent to enable the feature.
My conclusion was different. Given that the timing based privacy attacks are demonstrable without the interface, I thought it reasonable to enable-by-default with a hidden pref to disable. But this is based on the assumption that we aren't actually exposing any new private information. Am I missing an exploit here?
I understand that we have to keep a balance, and statistical fingerprinting is already dismayingly effective without any new features. However, "enable[d]-by-default with a hidden pref to disable" sounds like an extremely weak approach to protecting user privacy.
Is it possible to find experts on the topic of statistical fingerprinting, as well as security experts in general, who could review this API? Things I'd really like to know are:
- Does this feature, as designed, increase the effectiveness of user fingerprinting, assuming the user is running something like private browsing or incognito mode, or is regularly deleting site data? The relevant question here is marginal increase in effectiveness - are things worse with this feature than without?
- Presumably some known statistical fingerprinting techniques can be mitigated, if not always than at least in private browsing mode. If that was done, then would this timing feature provide an additional fingerprinting vector?
- Could this feature directly reveal otherwise hard-to-guess information about users?
- Can this feature be used to aid timing-based security attacks?
I would really like to see this kind of review done ahead of time and delivered to the Working Group. My worry here is that the feature may have fatal flaws as currently designed, or perhaps even in the basic concept of its functionality. If that's the case, then we'd certainly want to find out before we get locked into it. Perhaps some of the privacy risks can even be mitigated, such as by returning fake or random data in private browsing mode. I can ask some of Apple's security experts to review with a mind to these questions, but I'm wondering if there are other independent experts we could ask.
My preference would be to tread very carefully around anything that could be perceived as a privacy risk.
Regards, Maciej
Sorry for taking so long to get back to this. I'm planning to start working on it again, so it's time to close the loop here. The main concern earlier in this thread was the ability to take advantage of the extra timing information. We forwarded these concerns to the W3C security group as well as Google's and Microsoft's security teams. Tony's summary of the discussion on the W3C security list is here: http://lists.w3.org/Archives/Public/public-web-security/2011Oct/0019.html Everyone agreed that this spec makes timing attacks more explicit. But, since the timing attacks are already possible, this is not a concern. The only concern was that if the prior timing attacks could be patched, then this new spec would still leave us vulnerable. But, since nobody knows how to close the existing attacks, this wasn't considered an issue. So, they all are okay proceeding with Resource Timing. Are there any other concerns? As for spec updates... part of the Resource Timing spec was split out and generalized into the Performance Timeline spec [1]. It provides a uniform API for accessing the collected timing data. It'll include data from Navigation Timing, Resource Timing, and User Timing (to be discussed later). I'll land Performance Timeline before Resource Timing. Ports that wish to expose these APIs should enable: WEB_TIMING, PERFORMANCE_TIMELINE, and RESOURCE_TIMING. James [1] http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PerformanceTimeline/Overvie... On Fri, May 20, 2011 at 12:17 PM, Tony Gentilcore <tonyg@chromium.org>wrote:
I've forwarded these questions on to the working group: http://lists.w3.org/Archives/Public/public-web-perf/2011May/0102.html
In the meantime, we'll hold off on landing anything until we have satisfactory answers.
-Tony
On Fri, May 20, 2011 at 6:51 PM, Maciej Stachowiak <mjs@apple.com> wrote:
On May 20, 2011, at 10:10 AM, Tony Gentilcore wrote:
Presumably the embedding application would need to require explicit
user consent to enable the feature.
My conclusion was different. Given that the timing based privacy attacks are demonstrable without the interface, I thought it reasonable to enable-by-default with a hidden pref to disable. But this is based on the assumption that we aren't actually exposing any new private information. Am I missing an exploit here?
I understand that we have to keep a balance, and statistical fingerprinting is already dismayingly effective without any new features. However, "enable[d]-by-default with a hidden pref to disable" sounds like an extremely weak approach to protecting user privacy.
Is it possible to find experts on the topic of statistical fingerprinting, as well as security experts in general, who could review this API? Things I'd really like to know are:
- Does this feature, as designed, increase the effectiveness of user fingerprinting, assuming the user is running something like private browsing or incognito mode, or is regularly deleting site data? The relevant question here is marginal increase in effectiveness - are things worse with this feature than without?
- Presumably some known statistical fingerprinting techniques can be mitigated, if not always than at least in private browsing mode. If that was done, then would this timing feature provide an additional fingerprinting vector?
- Could this feature directly reveal otherwise hard-to-guess information about users?
- Can this feature be used to aid timing-based security attacks?
I would really like to see this kind of review done ahead of time and delivered to the Working Group. My worry here is that the feature may have fatal flaws as currently designed, or perhaps even in the basic concept of its functionality. If that's the case, then we'd certainly want to find out before we get locked into it. Perhaps some of the privacy risks can even be mitigated, such as by returning fake or random data in private browsing mode. I can ask some of Apple's security experts to review with a mind to these questions, but I'm wondering if there are other independent experts we could ask.
My preference would be to tread very carefully around anything that could be perceived as a privacy risk.
Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On 5/20/11 1:51 PM, Maciej Stachowiak wrote:
Presumably the embedding application would need to require explicit user consent to enable the feature.
I understand that we have to keep a balance, and statistical fingerprinting is already dismayingly effective without any new features. However, "enable[d]-by-default with a hidden pref to disable" sounds like an extremely weak approach to protecting user privacy.
I can't speak to the security or insecurity of enabling the Resource Timing APIs. However, I'll note that I see this API as part of the diagnostic side of WebKit, just like the Web Inspector debugger. In the case of the Web Inspector today, it requires explicit user consent to enable the feature - you need to perform a UI gesture to open the debugger (hot key, menu item, etc). Besides Resource Timing and Navigation Timing, hopefully in the near future, all our WebKits will have remote debugging enabled: http://www.webkit.org/blog/1620/webkit-remote-debugging/ So there's another case where we will need some kind of explicit user consent to enable the feature. I wonder if we could lump all this stuff together into a single "diagnostic mode" run-time guard. Turn it on, all the diagnostic, perhaps dangerous, API and capability is available. Turn it off - and it's off by default - and dangerous API and capability is not available. -- Patrick Mueller - http://muellerware.org
On 5/20/11 12:46 PM, Alexey Proskuryakov wrote:
What incentive will users have to enable it? For other privacy sensitive features (be it cookies or geolocation), there is a clear benefit to gain from them.
This is a developer-mode feature. There is no direct incentive for end users to enable something like Resource Timing. However, it's not hard to imagine a site suggesting that people could enable Resource Timing, and have that timing information sent back to the site for analysis, much the same way many programs today allow users to opt-in to sending diagnostic information back to a server somewhere. -- Patrick Mueller - http://muellerware.org
On May 23, 2011, at 8:16 AM, Patrick Mueller wrote:
On 5/20/11 12:46 PM, Alexey Proskuryakov wrote:
What incentive will users have to enable it? For other privacy sensitive features (be it cookies or geolocation), there is a clear benefit to gain from them.
This is a developer-mode feature. There is no direct incentive for end users to enable something like Resource Timing. However, it's not hard to imagine a site suggesting that people could enable Resource Timing, and have that timing information sent back to the site for analysis, much the same way many programs today allow users to opt-in to sending diagnostic information back to a server somewhere.
Hi Patrick, I may have misunderstood the feature, but I don't think that is the intent. I believe that Resource Timing and Navigation Timing are meant to be on in a normal user configuration. Websites can then make use of these APIs to get real-world performance data in the field, from users' machines. If the feature was meant to be opt-in and for developers only, then that would greatly reduce my concerns. Perhaps someone more familiar with these APIs can explain the design. Regards, Maciej
On Tue, May 24, 2011 at 8:14 AM, Maciej Stachowiak <mjs@apple.com> wrote:
On May 23, 2011, at 8:16 AM, Patrick Mueller wrote:
On 5/20/11 12:46 PM, Alexey Proskuryakov wrote:
What incentive will users have to enable it? For other privacy sensitive features (be it cookies or geolocation), there is a clear benefit to gain from them.
This is a developer-mode feature. There is no direct incentive for end users to enable something like Resource Timing. However, it's not hard to imagine a site suggesting that people could enable Resource Timing, and have that timing information sent back to the site for analysis, much the same way many programs today allow users to opt-in to sending diagnostic information back to a server somewhere.
Hi Patrick,
I may have misunderstood the feature, but I don't think that is the intent. I believe that Resource Timing and Navigation Timing are meant to be on in a normal user configuration. Websites can then make use of these APIs to get real-world performance data in the field, from users' machines.
If the feature was meant to be opt-in and for developers only, then that would greatly reduce my concerns.
Perhaps someone more familiar with these APIs can explain the design.
Yes, Maciej is correct. The use case is for performance monitoring rather than as a developer tool. In a dev environment, the Inspector already provides all of these details and more. However, a web page's performance characteristics may vary significantly with network conditions, geographic location, browser, OS, hardware, server load etc. A developer may be able to simulate a few of these in a controlled dev environment, but that doesn't necessarily accurately represent what real world users experience. For instance, imagine you invested in a more expensive CDN which claims to serve your static resources closer to your users. It would seem wise to have some way to monitor that this CDN actually improves user performance. That would be difficult to convince yourself of with dev tools alone. Today, many websites employ some form of performance monitoring. The problem is that only a limited picture can be obtained by timing existing events in JS. The intent of this API is to allow websites to obtain a more complete picture of the page's performance. The concern is that this may inadvertently expose side channel information. My hope is that we can trim down the API to the point where there is no new exploitable side channel information so that this can be enabled by default. -Tony
participants (6)
-
Alexey Proskuryakov
-
James Simonsen
-
Maciej Stachowiak
-
Patrick Mueller
-
Simon Fraser
-
Tony Gentilcore