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