Re: CORS

Since everything and everyone is stupid, messed up and incompetent
according to you, and your incoherent examples and explanations make no
sense whatsoever, let me ask this simple question.

You have some resource on the web, how do you instruct a browser on a per
resource basis which are ok to share with another site, and which are not?

On Wed, Oct 11, 2017 at 1:59 AM, Jack (Zhan, Hua Ping) <jackiszhp@gmail.com>
wrote:

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