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 10000 visited links vs. 10000 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
