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
