- From: Stefan Zager <szager@google.com>
- Date: Wed, 11 Oct 2017 15:48:16 -0700
- To: "Jack (Zhan, Hua Ping)" <jackiszhp@gmail.com>
- Cc: Florian Bösch <pyalot@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <CAHOQ7J_-fv2sXasdOPG-XTPPf5tY2Ba9XBQuxkgXjm5RsqC0Gw@mail.gmail.com>
If all of the other experts on this thread have not convinced you, then I doubt that I will either. But I'll try... You seem to assume that the web developers at bankA.com will be very smart and careful, and never serve private data in response to a cross-origin request. But the truth is that not all developers are so careful, and not all domains are so secure. In a world of imperfect web sites, same-origin policy is a huge improvement for the security of the end user, even if it causes some minor inconvenience to developers. One of the first things I learned about computer security was this: prefer white lists over black lists. A black list means: "I have a list of resources that should NOT be sent in response to cross-origin requests; anything that's not on my list should be allowed." A white list means: "I have a list of resources that CAN be sent in response to a cross-origin request; anything that's not on my list should NOT be allowed." White lists are safer, because if you make a mistake in the list, then the worst that happens is that you fail to send safe data; but you will never accidentally send unsafe data. CORS implements a white list. I do hope you take the time to read the document about CORS headers that Travis mentioned: https://w3c.github.io/webappsec-cors-for-developers/. If nothing else, it will clarify that the main point of concern here is to protect the embedded content (the iframe) from a hostile/evil embedder. Your earlier example about a government agency trying to scan evil third-party websites is not relevant, and has nothing to do with CORS. Indeed, if you were the government employee given the job of implementing such a scanning tool, there are certainly many other (better) ways to implement it, besides a web page making cross-origin requests. On Wed, Oct 11, 2017 at 3:00 PM, Jack (Zhan, Hua Ping) <jackiszhp@gmail.com> wrote: > >> I have already responded this to Tab Atkins as follows: > > You have not. And I ask again. How do you instruct a browser which > resource > > is ok to request from another origin? > When I said "as follows:", the answer text followed. And I elaborated > a bit more than asked, and at the end I challenge you to defeat me. > Please read that or here: > http://lists.w3.org/Archives/Public/public-webapps/2017OctDec/0024.html > There is no point for me to copy it here again. > > But in one sentence: I do not need the browser to do the authorization > check for me, I do the authorization check myself at server > https://bankA.com/. > > with best regards > Jack (Zhan, Hua Ping詹华平) > +86-153-9230-9232 > QQ: 94544458 欢迎加我,欢迎访问QQ空间 > twitter: https://twitter.com/jackzhp/with_replies > >
Received on Wednesday, 11 October 2017 22:48:41 UTC