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

[Cedric Sodhi]

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 <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
> >