Dear Adam, thank you for the the description. In line with my argument, that there is nothing intrinsically special with resources residing under file:// than there is with other resources let me ask coversely - very much because I understand exactly what you mean:
Why do you consider the possibility that a website can determine whether specific images are available on the users filesystem any more dangerous or intruding than the possibility to find out whether a user has cookie-authed to a remote image-resource (let us assume the particular server-side does not check for referers)? Before you answer that question though, which I'm sure you could, because it, at that stage, is merely a matter of "taste for what is appropriate", let me propose a different solution: Given the assumption that it would be indeed more inappropriate for a webpage to check for locally available images (or any sort of embedded resource) than it is for a webpage to for remotely available images, it would be sufficient to extend the same-origin restriction in the case of access to local resources to encompass preventing embedded content to be loaded. Other things, particularly anchors or iframes (though I in no sort approve of such ridiculous usage on a website whatsoever) pose absolutly no intrusion into the users privacy and therefore should be permitted. At this point I'm admittedly convinced that the use-case upon which my question and proposition is based, is indeed a most negligible corner-case and possibly not worth re-desiging the security feature or even just removing it alltogether. However, I'd still like to reach a conclusion, and if it be only for future prospect readers of this thread, on how far such a restricition is in fact needed. -- ManDay On Wed, Oct 12, 2011 at 12:40:23PM -0700, Adam Barth wrote: > As far as I know, every modern browser prevents non-local HTML > document (e.g., those with http or https schemes) from embedding > resources (e.g., images or iframes) from the local file system. > > This restriction prevents remote parties from probing the user's local > file system for information. For example, if we didn't implement this > restriction, a web page could detect whether you had a particular > piece of software installed on your computer by embedding images that > program stores at predictable locations on disk. If the software > package is installed, those images would load correct and their height > and width would affect layout. If not, the image load would error > out. > > You seem somewhat upset about this policy, but please understand that > we implement the restriction to improve the privacy and security of > our users. If you're embedding WebKit in your application, there is a > setting for disabling this protection if it's not appropriate for your > application. Hopefully this email will give you some context for why > we implement this restriction. > > Thanks for the feedback, and I hope you find WebKit useful. > > Adam > > > On Wed, Oct 12, 2011 at 12:25 PM, Cedric Sodhi <man...@gmx.net> wrote: > > I'm of the opinion that there is no need to distinguish between local > > and non-local schemes, such as it is in the case where a non-local (say, > > http) URI cannot load or embed a local (say, file) scheme. > > > > I've heard that there must have been reasons for such a restriction to > > be introduced. > > > > I hereby would like to reaccess those reasons and ask the people who > > originally drove the implementation to justify that restriction with > > regard to contemporary security issues. > > > > As a preclaimer to any argument I would like to cleary state that there > > > > IS NO INTRINSIC DIFFERENCE BETWEEN LOCAL AND NON-LOCAL RESOURCES. > > > > Both have equal rights to demand security. The only difference lies in > > the protocol being used to access them and what has to considered a > > distinct domain with regard to same-origin-policy. > > > > For reading, it's of no relevance, whether a file is at file:// , > > http:// , ftp:// , scp:// , or etc. > > > > Hence, limitations randomly imposed on either of the schemes are > > superflous and a wrong approach to whatever possible security > > considerations might have been made. > > -- > > regards, > > ManDay > > _______________________________________________ > > 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
