- From: Jack (Zhan, Hua Ping) <jackiszhp@gmail.com>
- Date: Thu, 12 Oct 2017 04:52:40 +0800
- To: Florian Bösch <pyalot@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
>Since everything and everyone is stupid, messed up and incompetent according to you, It seems that you want everybody to be my enemy. >and your incoherent examples and explanations make no sense whatsoever, I feel sad every time when I see this. It suggests I have not even got the qualification to talk to you -- I am completely a layman. >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? I have already responded this to Tab Atkins as follows: >>I never ask the browser to know which one is sensitive, which one is not. >>Suppose when you design http://evil.com/a.html , you want to load >>https://bankA.com/ticker/GOOG ,the browser just have to check by the rule >> -- is same origin – if yes, then serve a.html by making the request to https://bankA.com/. >> And as what I proposed, a.html has already told the browser to deem >> https://bankA.com/ as same origin. (Tab Atkins has not respond on this by now) Suppose now your http://evil.com/a.html want to get https://bankA.com/LastTransactionOfISISaccount. While ticker data is public, last transaction data is confidential. Still, the browser just do the same thing, so the browser will also make the request to https://bankA.com/. But now, I, the person who is responsible for the security of https://bankA.com/ will deny you from accessing this. You are designing http://evil.com/a.html, please do not dream about the security of bankA. Since you did that all the time, so I said you got your purpose wrong since your goal is do your evil thing. The whole https://bankA.com/ is designed by me, so I know which one is confidential data and which one is public available data. I do not require a browser to know that. And since you did not ask me how I distinguish a request referred by http://anyEvil.com/ from requests referred by https://bankA.com/entrypoint, let me omit this. By now, I guess you are convinced that browser should serve your http://evil.com/a.html with https://bankA.com/ticker/GOOG as long as a.html tells browser to deem https://bankA.com/ as same origin while https://bankA.com does not send the header (Access-Control-Allow-Origin "*"). By the way, when https://bankA.com/entrypoint is loaded, I do not tell browser to deem http://evil.com/ as the same origin. And I hope you stop dreaming about how browser and I should take care of the security of https://bankA.com/. Please just focus on your own job: use http://evil.com/a.html to access https://bankA.com/LastTransactionOfISISaccount. With my simple proposal, public data could be served as in the old days without sending the header you are eager for, while not compromising any protected resource. I am the person to take care of the security of https://bankA.com/ and I do not need browser to do authorization check for me. As for the above example, any effort try to defeat me is appreciated! If indeed I am wrong, the reason is that I can only see 1 step ahead, and you guys can see 3 or 4 steps ahead, so "a precise mechanism" for you guys seems to me to be stupid. If that's the case, please just defeat me. If you guys can not defeat me, then CORS - "the precise mechanism" is indeed a stupid design. with best regards Jack (Zhan, Hua Ping詹华平) +86-153-9230-9232 twitter: https://twitter.com/jackzhp/with_replies
Received on Wednesday, 11 October 2017 20:53:20 UTC