W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2017


From: Jack (Zhan, Hua Ping) <jackiszhp@gmail.com>
Date: Wed, 11 Oct 2017 07:59:32 +0800
Message-ID: <CAKRyGxtG1KWw3ri3O2H8eFU0ePHBJYkOH3hj3-HWEJu6vV1nYw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
You work on browsers? I am very glad to know you!

I can protect sensitive data on https://bankA.com/ since I am working
for it, its security is my responsibility. Whether the requested
resources contains sensitive data is known by me since I design
everything on https://bankA.com/, and I never ask the browser designed
by you to know which one is sensitive, which one is not.

If I need any feature from you for me to get my job done, I will make
a request. But I never ask your browser not to serve Florian's a.html.
Please tell me why you deny to serve his a.html?

when http://evil.com/a.html designed by Florian Bösch
<pyalot@gmail.com> wants to load https://bankA.com/ticker/GOOG, Why do
you deny a.html to load GOOG ticker data with fetch or XMLHttpRequest?
As I think, you just have to check by the rule -- is same origin -- if
yes, then serve the web page as requested. And as what I proposed,
a.html has already told your browser to deem https://bankA.com/ as
same origin, so serve him. Why not?

Be aware that I do not serve his a.html GOOG ticker data with the CORS
header. And the ticker data I will serve him is "{}".  If I serve him
with a piece of JS: var objname={}. Then his a.html can always get the
data as needed with a script element.

looking forward to your answer.

with best regards
Jack (Zhan, Hua Ping詹华平)

> Because the browser cannot automatically tell what page data contains
> sensitive information and what doesn't.  Just because the user visits
> evil.com, that does not automatically mean they grant evil.com
> permission to access all of their private data on other websites.  (Or
> worse - visiting good.com, and an ad from evil.com runs in an iframe
> and wants to slurp up all their private information.)
> As someone who works on browsers, it *is* my responsibility to make
> sure that, when it's possible to do so, I protect the user's
> information on bankA.com from evil people on evil.com.  There's a lot
> of stuff I *can't* do, either because I don't know it's bad, or
> "fixing" it will hurt too many other things, but there are some
> actions I can take (like applying the same-origin policy, preventing
> cross-origin scripts from accessing arbitrary stuff) that help a lot
> and hurt fairly little.
> This is you shooting yourself in the foot, then. Browsers block
> cross-origin data by default, to protect their users; you can unblock
> it with CORS.  If you refuse to use CORS, you can't unblock things.
> It's your problem that you're intentionally avoiding the tool that
> does what you ask.
> ~TJ
Received on Tuesday, 10 October 2017 23:59:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:15:08 UTC