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