Re: [webkit-dev] New Feature - Resource Timing
On Fri, May 20, 2011 at 3:17 AM, Simon Fraser simon.fra...@apple.comwrote: 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Question on font property value inherit in HTML Canvas
Hi, I am analyzing the following issue https://bugs.webkit.org/show_bug.cgi?id=48575 (the attachment in the issue description contains multiple issues) I was particularly looking into * http://w3c-test.org/html/tests/approved/canvas/canvas_text_font_001.htm*(Test-case passes in FF but NOT working in Safari(5.0.3)/Winlauncher setup [r86221]) After going through the HTML5 Canvas spec ( http://www.w3.org/TR/2dcontext/#dom-context-2d-font), my understanding is that if any of inherit/initial/default are used in the font property assignment statement (e.g., 20px inherit OR inherit 20px), then it must ignore the font value assignment continue with the previous font value assigned. This is in contrast to the CSS2.1 specification which allows the usage of inherit (The values initial/default are reserved for future use). Is this understanding correct? After debugging CSSParser CSSGrammer.y I have found that: = for normal HTML/CSS the code flows through CSSParser::parseSheet() = cssyyparse() = CSSParser::parseValue() = for HTML5 Canvas, the code flows through CSSParser::parseDeclaration() = cssyyparse() = CSSParser::parseValue() In the CSSParser::parseValue(), the handling is same for normal HTML/CSS as well as for HTML5 Canvas, i.e., it is handling the inherit in the same way. However, if my understanding as mentioned above is correct, the handling within the parser should be different (reason: CSS2.1 spec the HTML Canvas 2D Context spec expects inherit to be handled differently). Can somebody help share thoughts/perspective on this... Thanks, Rahaman ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature - Resource Timing
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature - Resource Timing
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? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature - Resource Timing
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature - Resource Timing
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 m...@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
[webkit-dev] JSObjectSetPropertyCallback not always called ?
Hi,
I wrote a simple loop in javascript:
for(var index = 0; index 1000; index++) {
if(myobject.color == 'red') {
myobject.color = 'blue'
} else {
myobject.color = 'red'
}
}
after 4 or 5 iterations i noticed that my JSObjectSetPropertyCallback
is not called anymore, but the JSObjectGetPropertyCallback still is.
is this the result of some kind of optimization ?
or am i just too tired ? :)
i really need my setters and getters to be called every time.
Martin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSObjectSetPropertyCallback not always called ?
A JSObjectSetPropertyCallback should be called every time.
Geoff
On May 20, 2011, at 4:01 PM, Martijn Scheffer wrote:
Hi,
I wrote a simple loop in javascript:
for(var index = 0; index 1000; index++) {
if(myobject.color == 'red') {
myobject.color = 'blue'
} else {
myobject.color = 'red'
}
}
after 4 or 5 iterations i noticed that my JSObjectSetPropertyCallback
is not called anymore, but the JSObjectGetPropertyCallback still is.
is this the result of some kind of optimization ?
or am i just too tired ? :)
i really need my setters and getters to be called every time.
Martin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
