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

[Adam Barth]

On Wed, Oct 12, 2011 at 12:56 PM, Cedric Sodhi <manday at gmx.net> 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 <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
>> >
>