On Wed, Oct 12, 2011 at 12:56 PM, Cedric Sodhi <[email protected]> wrote: > 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)?
If I could prevent that from happen, I would. However, the only ways I know of preventing that from happening also cause many people to become unhappy with my browser and to choose to use a different browser. Given that I want folks to use my browser, I have to keep that security hole open. By contrast, in the local file case, the evidence is that I can both close the security hole and have my browser be popular. Given that I value security over consistency in this case, my choice is clear. Adam > 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 <[email protected]> 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 >> > [email protected] >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
