Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Hi Sam, Can you please look at https://bugs.webkit.org/show_bug.cgi?id=41617 where I'm making memory stats reporting controlled by a preference, and turning it off by default. You are in the CC list but for some reason Bugzilla excluded you from the notification list when I uploaded updated patches. On Sat, Jun 5, 2010 at 13:24, Mikhail Naganov mnaga...@chromium.org wrote: OK, no problem with rolling it back. My apologies for acting too fast, I strongly believe in RERO philosophy. Can you please provide more info on how native APIs can be used for reporting memory usage data? That is, how a web app can signal that a measurement is needed to be taken at a certain point in its code? On Fri, Jun 4, 2010 at 23:26, Sam Weinig sam.wei...@gmail.com wrote: On Fri, Jun 4, 2010 at 12:02 PM, Ojan Vafai o...@chromium.org wrote: On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig sam.wei...@gmail.com wrote: After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can. They both provide information to users that are not generally useful (beyond the continuous integration/buildbot use-case which I think is of limited utility) and therefore should not be exposed to the web. Why is the continuous integration/buildbot use-case of limited utility? Or are you saying that Console.memory doesn't really support that use-case well? I think we want to make it as easy as possible for complex apps (e.g. email apps, mapping apps, etc.) to care about and monitor memory use. I am not saying that this API doesn't support the continuous integration/buildbot use-case, or support it well, I am saying that I don't think this is a use case we should be supporting in a web facing API. While I'm not convinced by the utility argument, I do buy the security argument. How would you feel about leaving the code in, but disabling it by default? Then it could be enabled by command-line or via a preference. That said, I'm OK with rolling back for now given that the code was committed without this discussion actually coming to a conclusion. I would rather we didn't add more #ifdefs. Instead, this functionality should be available to native APIs (I believe it already is) -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
On 6/5/10 5:24 AM, Mikhail Naganov wrote: Can you please provide more info on how native APIs can be used for reporting memory usage data? That is, how a web app can signal that a measurement is needed to be taken at a certain point in its code? For a specific example, today, you can use console.markTimeline(message) to have an entry added to the debug time line. May not be the measurement you were looking for ... :-) But this raises a distinction - it's probably ok to allow functions like console.markTimeline(message) (and any other sort of diagnostic related function) as long as they don't actually do anything unless you are debugging. It's not clear to me that's the case today for markTimeline(), nor whether it's a problem if it actually does do something if you aren't debugging - all of the console APIs probably need to be looked at. On Fri, Jun 4, 2010 at 23:26, Sam Weinigsam.wei...@gmail.com wrote: On Fri, Jun 4, 2010 at 12:02 PM, Ojan Vafaio...@chromium.org wrote: On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinigsam.wei...@gmail.com wrote: After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can. They both provide information to users that are not generally useful (beyond the continuous integration/buildbot use-case which I think is of limited utility) and therefore should not be exposed to the web. I talked to a developer a few months ago that was building a system to collect profiling information in an 'as automated fashion as possible'. He wanted to collect the information over time for analysis. Makes sense to me. I believe he was using console.profiles() for this - across FireBug and WebKit. This was all user-land code; they were collecting the information and uploading it back to their site for later analysis. Use Case! You could argue this can be solved by tools, but as someone who has been in the tools vendor business for a long time, I can tell you if your answer is you just need tools, you're not going far enough. Smart developers prefer APIs so they can build their own tools. I agree we need to secure this stuff, it is obviously not of interest to 99.99% of the end users of WebKit, but it's invaluable to the 0.01% out there. If we found a way to secure this, could we use a pattern of adding APIs like console.profiles() secured by that mechanism? As for the use case above, the app collecting the information was a specially built application used only by developers. I suspect they'd be willing to deal with any extra overhead or ickiness in allowing this secured use, assuming it could eventually be automated. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
OK, no problem with rolling it back. My apologies for acting too fast, I strongly believe in RERO philosophy. Can you please provide more info on how native APIs can be used for reporting memory usage data? That is, how a web app can signal that a measurement is needed to be taken at a certain point in its code? On Fri, Jun 4, 2010 at 23:26, Sam Weinig sam.wei...@gmail.com wrote: On Fri, Jun 4, 2010 at 12:02 PM, Ojan Vafai o...@chromium.org wrote: On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig sam.wei...@gmail.com wrote: After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can. They both provide information to users that are not generally useful (beyond the continuous integration/buildbot use-case which I think is of limited utility) and therefore should not be exposed to the web. Why is the continuous integration/buildbot use-case of limited utility? Or are you saying that Console.memory doesn't really support that use-case well? I think we want to make it as easy as possible for complex apps (e.g. email apps, mapping apps, etc.) to care about and monitor memory use. I am not saying that this API doesn't support the continuous integration/buildbot use-case, or support it well, I am saying that I don't think this is a use case we should be supporting in a web facing API. While I'm not convinced by the utility argument, I do buy the security argument. How would you feel about leaving the code in, but disabling it by default? Then it could be enabled by command-line or via a preference. That said, I'm OK with rolling back for now given that the code was committed without this discussion actually coming to a conclusion. I would rather we didn't add more #ifdefs. Instead, this functionality should be available to native APIs (I believe it already is) -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Comments are inline. On Fri, Jun 4, 2010 at 05:57, Sam Weinig sam.wei...@gmail.com wrote: I should note, I don't think this is possible for JS objects, it certainly would not be possible for arbitrary WebCore/WebKit objects. I noticed the patch was re-landed, which surprises me since we are still discussing it, why was this? -Sam Well, I sent my last message 2 days ago, got no answer, and decided that the discussion is finished by a timeout. I haven't seen any serious concerns about this patch. On Thu, Jun 3, 2010 at 5:02 PM, Timothy Hatcher timo...@apple.com wrote: Even if that wont prevent Sam's proposed information leak, I think this would be good to do. That way developers only see what they are affecting. Otherwise a developer might chase a red herring if they have Gmail or something open in the background and keep seeing spikes of memory are not caused by their page. Let's elaborate this a bit more. How I'm seeing this potential attack: another page (or an iframe) retrieves memory size and somehow deduces something based on memory consumption (current or over time) by an engine. If we restrict reported counts to include only page's (iframe's) memory it could only deduce things about itself, or about engine specifics, like, e.g. how many bytes does it take to hold a particular object. And even this data isn't exact now, because in JSC, the memory consumption is counted using the number of allocated blocks, so it's pretty coarse-grained. I agree that we (me, personally) should implement this filtering of memory consumption counter. I think, this should be possible for JS objects, if we involve the same mechanism that is used for enforcing single origin policy. On Jun 2, 2010, at 2:45 PM, Mikhail Naganov wrote: Used memory count can be restricted to include only objects reachable from the caller execution context. In this case, an app could only see the amount of memory consumed by itself, not by the whole engine. — Timothy Hatcher ___ 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
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
On Fri, Jun 4, 2010 at 1:54 AM, Mikhail Naganov mnaga...@chromium.org wrote: On Fri, Jun 4, 2010 at 05:57, Sam Weinig sam.wei...@gmail.com wrote: I should note, I don't think this is possible for JS objects, it certainly would not be possible for arbitrary WebCore/WebKit objects. I noticed the patch was re-landed, which surprises me since we are still discussing it, why was this? Well, I sent my last message 2 days ago, got no answer, and decided that the discussion is finished by a timeout. I haven't seen any serious concerns about this patch. Hum... That seems a bit agressive. Sometimes interacting with this project requires a bit more patience. My guess is that you've alienated Sam and whoever else was interested in discussing this topic further. :( Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can. They both provide information to users that are not generally useful (beyond the continuous integration/buildbot use-case which I think is of limited utility) and therefore should not be exposed to the web. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig sam.wei...@gmail.com wrote: After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can. They both provide information to users that are not generally useful (beyond the continuous integration/buildbot use-case which I think is of limited utility) and therefore should not be exposed to the web. Why is the continuous integration/buildbot use-case of limited utility? Or are you saying that Console.memory doesn't really support that use-case well? I think we want to make it as easy as possible for complex apps (e.g. email apps, mapping apps, etc.) to care about and monitor memory use. While I'm not convinced by the utility argument, I do buy the security argument. How would you feel about leaving the code in, but disabling it by default? Then it could be enabled by command-line or via a preference. That said, I'm OK with rolling back for now given that the code was committed without this discussion actually coming to a conclusion. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
I'm fairly certain I could construct an attack on :visited history privacy using this object. dave On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote: On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig sam.wei...@gmail.com wrote: After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can. They both provide information to users that are not generally useful (beyond the continuous integration/buildbot use-case which I think is of limited utility) and therefore should not be exposed to the web. Why is the continuous integration/buildbot use-case of limited utility? Or are you saying that Console.memory doesn't really support that use-case well? I think we want to make it as easy as possible for complex apps (e.g. email apps, mapping apps, etc.) to care about and monitor memory use. While I'm not convinced by the utility argument, I do buy the security argument. How would you feel about leaving the code in, but disabling it by default? Then it could be enabled by command-line or via a preference. That said, I'm OK with rolling back for now given that the code was committed without this discussion actually coming to a conclusion. Ojan ___ 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
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
How? Visited state information is not stored in the javascript heap (which is what this object contains information about). - James On Fri, Jun 4, 2010 at 12:06 PM, David Hyatt hy...@apple.com wrote: I'm fairly certain I could construct an attack on :visited history privacy using this object. dave On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote: On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig sam.wei...@gmail.com wrote: After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can. They both provide information to users that are not generally useful (beyond the continuous integration/buildbot use-case which I think is of limited utility) and therefore should not be exposed to the web. Why is the continuous integration/buildbot use-case of limited utility? Or are you saying that Console.memory doesn't really support that use-case well? I think we want to make it as easy as possible for complex apps (e.g. email apps, mapping apps, etc.) to care about and monitor memory use. While I'm not convinced by the utility argument, I do buy the security argument. How would you feel about leaving the code in, but disabling it by default? Then it could be enabled by command-line or via a preference. That said, I'm OK with rolling back for now given that the code was committed without this discussion actually coming to a conclusion. Ojan ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
To get more specific, the style allocated for visited state is freed when you're an unvisited link to save memory (lots of memory), but it is not freed if you're visited. So there's a definite memory consumption difference. This memory difference would be magnified and obvious if you made 1 visited links vs. 1 unvisited links. We would have to deliberately consume megabytes more of memory just to prevent this attack if we keep this object in, and I just made the above fix to prevent a more than 4mb memory regression. Therefore I do not think memory use information is safe to expose, and this feature is not something we should be adding. dave (hy...@apple.com) On Jun 4, 2010, at 2:06 PM, David Hyatt wrote: I'm fairly certain I could construct an attack on :visited history privacy using this object. dave On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote: On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig sam.wei...@gmail.com wrote: After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can. They both provide information to users that are not generally useful (beyond the continuous integration/buildbot use-case which I think is of limited utility) and therefore should not be exposed to the web. Why is the continuous integration/buildbot use-case of limited utility? Or are you saying that Console.memory doesn't really support that use-case well? I think we want to make it as easy as possible for complex apps (e.g. email apps, mapping apps, etc.) to care about and monitor memory use. While I'm not convinced by the utility argument, I do buy the security argument. How would you feel about leaving the code in, but disabling it by default? Then it could be enabled by command-line or via a preference. That said, I'm OK with rolling back for now given that the code was committed without this discussion actually coming to a conclusion. Ojan ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
On Wed, Jun 2, 2010 at 2:45 PM, Mikhail Naganov mnaga...@chromium.orgwrote: Used memory count can be restricted to include only objects reachable from the caller execution context. In this case, an app could only see the amount of memory consumed by itself, not by the whole engine. I don't think this would change anything about my proposed problem. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Even if that wont prevent Sam's proposed information leak, I think this would be good to do. That way developers only see what they are affecting. Otherwise a developer might chase a red herring if they have Gmail or something open in the background and keep seeing spikes of memory are not caused by their page. On Jun 2, 2010, at 2:45 PM, Mikhail Naganov wrote: Used memory count can be restricted to include only objects reachable from the caller execution context. In this case, an app could only see the amount of memory consumed by itself, not by the whole engine. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
I should note, I don't think this is possible for JS objects, it certainly would not be possible for arbitrary WebCore/WebKit objects. I noticed the patch was re-landed, which surprises me since we are still discussing it, why was this? -Sam On Thu, Jun 3, 2010 at 5:02 PM, Timothy Hatcher timo...@apple.com wrote: Even if that wont prevent Sam's proposed information leak, I think this would be good to do. That way developers only see what they are affecting. Otherwise a developer might chase a red herring if they have Gmail or something open in the background and keep seeing spikes of memory are not caused by their page. On Jun 2, 2010, at 2:45 PM, Mikhail Naganov wrote: Used memory count can be restricted to include only objects reachable from the caller execution context. In this case, an app could only see the amount of memory consumed by itself, not by the whole engine. — Timothy Hatcher ___ 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
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Now that I have had a little time to think about it, I think my biggest concern with this type of API is the unintentional ability for an attacker to gain information from the engine consuming specifics amount of memory. Let's take the visited link history stealing attack as an example. Even though you can no longer use getComputedStyle() directly to gain information as to whether a link was visited or not, if the engine allocated subtly different amounts of memory depending on whether the link was visited or not, an attacker could detect this and gain that information. Adam (and other web security people), am I being overly paranoid about this? -Sam On Fri, May 28, 2010 at 10:56 AM, Mikhail Naganov mnaga...@chromium.orgwrote: Greetings, WebKit deveopers, As a response to requests from web apps developers, I was intended to add a simple API for accessing web app's memory consumption, see https://bugs.webkit.org/show_bug.cgi?id=39646 The scenario of using this API is as follows: - a builbot runs web app's common usage scenarios tests; - inside tests, memory usage is recorded via the API proposed; - the results are sent to a server (using XHR or a CGI request); - server plots nice graphs of memory usage status, bound to the changes made to the web app; - thus, if someone does a change that blows up memory usage, developers will notice. As Sam points out, this change may be fine, but he suggests to make it accessible only when a browser runs in a special developer mode. This can also be applied to the whole 'console' object. Please, share your thoughts on this. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
I haven't looked into the details, but, in general, side channel information is a rich area for unintentional disclosure. For example, timing information leaks a ton of information. Here's a recent paper that shows a bunch of stuff you can use from the sizes of things. In this case, they're looking at the size on the wire, but you could imagine something similar for in-memory size: http://oakland31.cs.virginia.edu/slides/sidechannel.pdf Adam On Wed, Jun 2, 2010 at 11:52 AM, Sam Weinig sam.wei...@gmail.com wrote: Now that I have had a little time to think about it, I think my biggest concern with this type of API is the unintentional ability for an attacker to gain information from the engine consuming specifics amount of memory. Let's take the visited link history stealing attack as an example. Even though you can no longer use getComputedStyle() directly to gain information as to whether a link was visited or not, if the engine allocated subtly different amounts of memory depending on whether the link was visited or not, an attacker could detect this and gain that information. Adam (and other web security people), am I being overly paranoid about this? -Sam On Fri, May 28, 2010 at 10:56 AM, Mikhail Naganov mnaga...@chromium.org wrote: Greetings, WebKit deveopers, As a response to requests from web apps developers, I was intended to add a simple API for accessing web app's memory consumption, see https://bugs.webkit.org/show_bug.cgi?id=39646 The scenario of using this API is as follows: - a builbot runs web app's common usage scenarios tests; - inside tests, memory usage is recorded via the API proposed; - the results are sent to a server (using XHR or a CGI request); - server plots nice graphs of memory usage status, bound to the changes made to the web app; - thus, if someone does a change that blows up memory usage, developers will notice. As Sam points out, this change may be fine, but he suggests to make it accessible only when a browser runs in a special developer mode. This can also be applied to the whole 'console' object. Please, share your thoughts on this. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Used memory count can be restricted to include only objects reachable from the caller execution context. In this case, an app could only see the amount of memory consumed by itself, not by the whole engine. Another option, as Sam proposed before, is to expose things like console.profiles and console.memory only when a browser is launched in developer mode. Although, this still opens the way to unintentional information disclosure when a developer forgets that she is running the browser in this mode. On Wed, Jun 2, 2010 at 23:06, Adam Barth aba...@webkit.org wrote: I haven't looked into the details, but, in general, side channel information is a rich area for unintentional disclosure. For example, timing information leaks a ton of information. Here's a recent paper that shows a bunch of stuff you can use from the sizes of things. In this case, they're looking at the size on the wire, but you could imagine something similar for in-memory size: http://oakland31.cs.virginia.edu/slides/sidechannel.pdf Adam On Wed, Jun 2, 2010 at 11:52 AM, Sam Weinig sam.wei...@gmail.com wrote: Now that I have had a little time to think about it, I think my biggest concern with this type of API is the unintentional ability for an attacker to gain information from the engine consuming specifics amount of memory. Let's take the visited link history stealing attack as an example. Even though you can no longer use getComputedStyle() directly to gain information as to whether a link was visited or not, if the engine allocated subtly different amounts of memory depending on whether the link was visited or not, an attacker could detect this and gain that information. Adam (and other web security people), am I being overly paranoid about this? -Sam On Fri, May 28, 2010 at 10:56 AM, Mikhail Naganov mnaga...@chromium.org wrote: Greetings, WebKit deveopers, As a response to requests from web apps developers, I was intended to add a simple API for accessing web app's memory consumption, see https://bugs.webkit.org/show_bug.cgi?id=39646 The scenario of using this API is as follows: - a builbot runs web app's common usage scenarios tests; - inside tests, memory usage is recorded via the API proposed; - the results are sent to a server (using XHR or a CGI request); - server plots nice graphs of memory usage status, bound to the changes made to the web app; - thus, if someone does a change that blows up memory usage, developers will notice. As Sam points out, this change may be fine, but he suggests to make it accessible only when a browser runs in a special developer mode. This can also be applied to the whole 'console' object. Please, share your thoughts on this. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
