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

Re: CORS

From: Jack (Zhan, Hua Ping) <jackiszhp@gmail.com>
Date: Thu, 12 Oct 2017 04:52:40 +0800
Message-ID: <CAKRyGxt6TAw5DkapGGV2SXdD+A=FWyT8zrL0uV65R=bDiC8YPg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 9 November 2017 09:59:04 UTC