[webkit-dev] Distinction between local and non-local URIs

[Adam Barth]

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 <manday at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>