CORS

# Jack (Zhan, Hua Ping) (6 days ago)

Subject: CORS

Hi, Finally, I decided to write this letter.

It was said that the aim of CORS is to get around or extend the same site/origin policy which does not allow 1st.com/abc.html to post data to (or get data from) 2nd.com/somewhere.

Adobe's solution to this was invented long ago, and I would say it is elegant. As for the above example, what is needed is simply for abc.html to add a piece of meta data:

<meta name="sameOrigin" content="[http://2nd.com/](http://2nd.com/)"/>

or with an HTTP header when serving abc.html: SameOrigin: 2nd.com

Since 2005, I do not understand why you guys from W3C went crazy to add meta data (W3C's first version) or http header (the 3rd version) for 2nd.com/somewhere. At that time, I thought overtime, you guys would get it right since you guys are smart. I am just a free rider, I did not have to participate. But over time, I was disappointed: the reality is not what I expected, and even browsers implemented the stupid design by you guys. If your design is not stupid then I am just simply and totally wrong on what I think is simple.

Let's take producer-consumer relationship here: 1st.com/abc.html is a consumer. 2nd.com is a producer. 2nd.com/somewhere is the product.

The old same origin/site policy of web browsers requires the consumer only consumes resources from 1st.com, and does not allow it to consume resources from other sites. For a consumer wants to consume products from other sites, what is need is that the 1st consumer tells the browser to deem the 2nd producer as from the same origin.

Why you guys went crazy? Went to "print" some information on the product to be consumed saying who is allowed to consume it ("access control")?

Frankly speaking with simple language, I feel that either I am simply & totally wrong/stupid, or you guys are really stupid. Or maybe you guys are not wrong as the aim of CORS is not to extend the same origin policy. In that case, the first sentence of CORS "This document defines a mechanism to enable client-side cross-origin requests" shoud be changed to "This document defines an HTTP mechanism on web resources authorization: what can access the resource and how".

I am looking forward to some explanation why I am wrong. Any respond is appreciated.

with best regards Jack (Zhan, Hua Ping詹华平) +86-153-9230-9232 QQ: 94544458 欢迎加我,欢迎访问QQ空间 twitter: twitter.com/jackzhp/with_replies 腾讯微博:t.qq.com/jackiszhp 福建詹华平 新浪微博:weibo.com/u/2478246631 福建詹华平 搜狐微博:t.sohu.com/people?uid=354178954 詹华平 GPG/openPGP key: 1070307AE69B6BB861AF4E9FDB61E01A3DF5687D

Contact us to advertise here
# Travis Leithead (6 days ago)

While the Adobe solution you mention below seems OK at first, note that the requestor for permissions is self-granting the permission. In other words, it would be just as easy for: evil.com to add <meta name="sameOrigin" content="[https://popularbank.com](https://popularbank.com)" /> and grant permission to itself to access your bank. A self-granting permission model just isn't secure--the permission grant must come from the resource being requested.

-----Original Message----- From: Jack (Zhan, Hua Ping) [mailto:jackiszhp@gmail.com] Sent: Tuesday, October 10, 2017 8:07 AM To: public-webapps@w3.org; Anne van Kesteren annevk@annevk.nl Subject: CORS

Subject: CORS

Hi, Finally, I decided to write this letter.

It was said that the aim of CORS is to get around or extend the same site/origin policy which does not allow 1st.com/abc.html to post data to (or get data from) 2nd.com/somewhere.

Adobe's solution to this was invented long ago, and I would say it is elegant. As for the above example, what is needed is simply for abc.html to add a piece of meta data:

<meta name="sameOrigin" content="[http://2nd.com/](http://2nd.com/)"/> or with an HTTP header when serving abc.html: SameOrigin: 2nd.com/

Since 2005, I do not understand why you guys from W3C went crazy to add meta data (W3C's first version) or http header (the 3rd version) for 2nd.com/somewhere. At that time, I thought overtime, you guys would get it right since you guys are smart. I am just a free rider, I did not have to participate. But over time, I was disappointed: the reality is not what I expected, and even browsers implemented the stupid design by you guys. If your design is not stupid then I am just simply and totally wrong on what I think is simple.

Let's take producer-consumer relationship here: 1st.com/abc.html is a consumer. 2nd.com is a producer. 2nd.com/somewhere is the product.

The old same origin/site policy of web browsers requires the consumer only consumes resources from 1st.com, and does not allow it to consume resources from other sites. For a consumer wants to consume products from other sites, what is need is that the 1st consumer tells the browser to deem the 2nd producer as from the same origin.

Why you guys went crazy? Went to "print" some information on the product to be consumed saying who is allowed to consume it ("access control")?

Frankly speaking with simple language, I feel that either I am simply & totally wrong/stupid, or you guys are really stupid. Or maybe you guys are not wrong as the aim of CORS is not to extend the same origin policy. In that case, the first sentence of CORS "This document defines a mechanism to enable client-side cross-origin requests" shoud be changed to "This document defines an HTTP mechanism on web resources authorization: what can access the resource and how".

I am looking forward to some explanation why I am wrong. Any respond is appreciated.

with best regards Jack (Zhan, Hua Ping詹华平) +86-153-9230-9232 QQ: 94544458 欢迎加我,欢迎访问QQ空间 twitter: twitter.com/jackzhp/with_replies 腾讯微博:t.qq.com/jackiszhp 福建詹华平 新浪微博:weibo.com/u/2478246631 福建詹华平 搜狐微博:t.sohu.com/people?uid=354178954 詹华平 GPG/openPGP key: 1070307AE69B6BB861AF4E9FDB61E01A3DF5687D

# Florian Bösch (6 days ago)

On Tue, Oct 10, 2017 at 5:33 PM, Travis Leithead travis.leithead@microsoft.com wrote:

While the Adobe solution you mention below seems OK at first, note that the requestor for permissions is self-granting the permission. In other words, it would be just as easy for: evil.com to add <meta name="sameOrigin" content="[https://popularbank.com](https://popularbank.com)" /> and grant permission to itself to access your bank. A self-granting permission model just isn't secure--the permission grant must come from the resource being requested.

Was about to point that out. Never heard about Adobes approach, but you'd think that overtime Adobe would get security right. Apparently not.

# Jake Archibald (6 days ago)

I can't find any reference to this "Adobe" behaviour.

Flash relied on crossdomain.xml, but that had to be on the origin containing the requested resource, so 2nd.com in this case.

Adobe's solution is pretty similar to CORS but sets an origin-wide policy, whereas CORS can be per resource.

# Jack (Zhan, Hua Ping) (6 days ago)

Travis Leithead travis.leithead@microsoft.com wrote:

While the Adobe solution you mention below seems OK at first, note that the requestor for permissions is self-granting the permission. In other words, it would be just as easy for: evil.com to add <meta name="sameOrigin" content="[https://popularbank.com](https://popularbank.com)" /> and grant permission to itself to access your bank. A self-granting permission model just isn't secure--the permission grant must come from the resource being requested.

Florian Bösch pyalot@gmail.com wrote:

Was about to point that out. Never heard about Adobes approach, but you'd think that overtime Adobe would get security right. Apparently not.

At first, thank you for responding to what I wrote.

Clearly you two messed up the extension of the same site/origin policy with the resource access authorization. You even got your purpose wrong. As for your example, your sole purpose on extending same site/origin policy is to extend the capability of evil.com/a.html while keeping the evil from being poisoned. As for your example, your purpose is "not to protect the bank", but to extend the capacity of the evil to guarantee the evil can do its evil thing. How to protect the resource at bankA.com is another issue. Its protection should not rely on how to extend the capability of evil.com while keep the evil from being poisoned.

Travis is working for Microsoft, what you said surprised me. For many times, I felt powerless to clarify some simple things. This is one incident of it, let me try to put it this way: Suppose you are working as a CIA field data analyst(evil.com/agentA.html) within US government(browser). In the old days the same site/origin policy allows you to analyze only files from CIA(evil.com). We all know that you should be allowed to analyze files from any where as long as you need it, such as files from a terrorist office(bankA.com a terrorist disguises as a banker), so we have to extend the same site/origin policy to allow you (agentA.html) to access any file as you needed after the government assigns you the job(browser load the page agentA.html).

Here, the security issue is how the US government(browser) should protect you (agentA.html) from being poisoned/killed by files from any terrorist's office. The script element approach(JSONP) would give a terrorist the opportunity to poison you through the files. So a dedicated approach for CORS data fetch is indeed needed.

The wrong of W3C CORS/fetch is to design a system which puts a note on every file folder saying that who with what kind of method can access it. And the US government(browser) imposes the rules stated by the note when it(government) fetches the file for you(agentA.html). Isn't this US government and the W3C's recommendation stupid?

And what you two said is that permission for you(agentA.html) to analyze files from terrorist's office should be granted by the note on the file folder, isn't it totally nonsense? I guess you two are not working on computer security.

I am looking forward to responses from people who think they really understand the issue. If you do, please comment.

with best regards Jack (Zhan, Hua Ping詹华平) +85-153-9230-9232 QQ: 94544458 欢迎加我,欢迎访问QQ空间 twitter: twitter.com/jackzhp/with_replies

# Florian Bösch (6 days ago)

CORS solves a problem (how to let other sites access resources on your site) that exists because browsers implement the same-origin policy on data requests. The same origin policy exists because some data ( mysite.com/balance) might be sensitive or because some handler ( mysite.com/delete-user) might have side effects, and because any form of authentication (cookies, http-auth, etc.) is attached to a request to that origin.

CORS does this by marking up resources with permissions. This is an effective solution because an attacker has an interest in gaining the credentials of a logged in user residing in their UA and using them to perform malicious acts. The attacker does not control the users UA. It is a precise mechanism because the site that implements those resources has the knowledge about which are sensitive and which have side effects, and which it wants to share.

On Tue, Oct 10, 2017 at 5:06 PM, Jack (Zhan, Hua Ping) jackiszhp@gmail.com wrote: >

Adobe's solution to this was invented long ago, and I would say it is elegant. As for the above example, what is needed is simply for abc.html to add a piece of meta data:

<meta name="sameOrigin" content="[http://2nd.com/](http://2nd.com/)"/> or with an HTTP header when serving abc.html: SameOrigin: 2nd.com

This self-grants permission of 2nd.com to resources from 1st.com. That circumvents the intent of the same origin policy which aims to protect users from malicious sites.

Frankly speaking with simple language, I feel that either I am simply & totally wrong/stupid

Correct.

Any respond is appreciated.

I come to doubt that.

On Tue, Oct 10, 2017 at 9:48 PM, Jack (Zhan, Hua Ping) jackiszhp@gmail.com

wrote: >

Clearly you two messed up the extension of the same site/origin policy with the resource access authorization. You even got your purpose wrong. As for your example, your sole purpose on extending same site/origin policy is to extend the capability of evil.com/a.html while keeping the evil from being poisoned. As for your example, your purpose is "not to protect the bank", but to extend the capacity of the evil to guarantee the evil can do its evil thing. How to protect the resource at bankA.com is another issue. Its protection should not rely on how to extend the capability of evil.com while keep the evil from being poisoned.

This made no sense whatsoever. The same origin policy exists to protect resources of one site, from access by another site, because those resources might sensitive or have side effects. CORS exists to allow sites to share resources for use by other sites. CORS achieves that by tagging resources with permissions of use by the originating site, and in that, perfectly achieves its aim.

Suppose you are working as a CIA field data

analyst(evil.com/agentA.html) within US government(browser). In the old days the same site/origin policy allows you to analyze only files from CIA(evil.com). We all know that you should be allowed to analyze files from any where as long as you need it, such as files from a terrorist office(bankA.com a terrorist disguises as a banker), so we have to extend the same site/origin policy to allow you (agentA.html) to access any file as you needed after the government assigns you the job(browser load the page agentA.html).

Here, the security issue is how the US government(browser) should protect you (agentA.html) from being poisoned/killed by files from any terrorist's office. The script element approach(JSONP) would give a terrorist the opportunity to poison you through the files. So a dedicated approach for CORS data fetch is indeed needed.

This again made no sense at all.

The wrong of W3C CORS/fetch is to design a system which puts a note on every file folder saying that who with what kind of method can access it. And the US government(browser) imposes the rules stated by the note when it(government) fetches the file for you(agentA.html). Isn't this US government and the W3C's recommendation stupid?

Apart from this making no sense at all either, it seems to suggest marking up permissions for resources that need permissions is supposed to be stupid. Somehow that seems a flawed kind of "logic".

And what you two said is that permission for you(agentA.html) to analyze files from terrorist's office should be granted by the note on the file folder, isn't it totally nonsense? I guess you two are not working on computer security.

It's amazing that somebody who exhibits this little understanding of the issue at hand insinuates stupidity and incompetence in everybody who responds and then has the gall to...

I am looking forward to responses from people who think they really

understand the issue. If you do, please comment.

Claim to look forward to more responses.

# Jack (Zhan, Hua Ping) (6 days ago)

On Wed, Oct 11, 2017 at 12:57 AM, Jake Archibald jakearchibald@google.com wrote:

I can't find any reference to this "Adobe" behaviour.

Flash relied on crossdomain.xml, but that had to be on the origin containing the requested resource, so 2nd.com in this case.

Adobe's solution is pretty similar to CORS but sets an origin-wide policy, whereas CORS can be per resource.

After read your comment, I checked what you said. And what you said is true according to the material I can find at present day, though they are all after 2008 (version 0.2 Cross Domain Policy File Specification). When I got the impression in 2003/2004, I did not know there is any published specification on relaxing the same origin policy. At that time, it seemed to be its proprietary use. Either Adobe has changed their design after W3C published its stupid design in 2005 or I misunderstood Adobe's way which is possible though I do not think it is probable.

I mentioned "Adobe" because I think I should give credit to what I saw long time ago. I do not mind we refer what I proposed with any other term such as "JMBW(Jack Might Be Wrong) way of specifying the same origin".

Please comment on "JMBW way of specifying the same origin", why those smart people do not implement it this way, why it is not good? Enlight me.

with best regards Jack (Zhan, Hua Ping詹华平) +85-153-9230-9232 twitter: twitter.com/jackzhp/with_replies

# Florian Bösch (6 days ago)

On Tue, Oct 10, 2017 at 10:25 PM, Jack (Zhan, Hua Ping) <jackiszhp@gmail.com

wrote:

Please comment on "JMBW way of specifying the same origin", why those smart people do not implement it this way, why it is not good? Enlight me.

You mean why is your original self-grant description bad (because it's self-grant) or why is a sitewide crossdomain.xml not good (because it's sitewide). To satisfy all use-cases CORS is fine-grained. If you want something as easy as crossdomain.xml, just add this to your apache config:

Header set Access-Control-Allow-Origin "*"

# Travis Leithead (6 days ago)

Let me point you to Brad Hill's write-up on CORS, which is an excellent explanation of the "how" and "why" of its design: w3c.github.io/webappsec-cors-for-developers/

-----Original Message----- From: Jack (Zhan, Hua Ping) [mailto:jackiszhp@gmail.com] Sent: Tuesday, October 10, 2017 12:48 PM To: Travis Leithead travis.leithead@microsoft.com; pyalot@gmail.com; public-webapps@w3.org; Anne van Kesteren annevk@annevk.nl Subject: Re: CORS

Travis Leithead travis.leithead@microsoft.com wrote:

While the Adobe solution you mention below seems OK at first, note that the requestor for permissions is self-granting the permission. In other words, it would be just as easy for: evil.com to add <meta name="sameOrigin" content="[https://popularbank.com](https://popularbank.com)" /> and grant permission to itself to access your bank. A self-granting permission model just isn't secure--the permission grant must come from the resource being requested.

Florian Bösch pyalot@gmail.com wrote:

Was about to point that out. Never heard about Adobes approach, but you'd think that overtime Adobe would get security right. Apparently not.

At first, thank you for responding to what I wrote.

Clearly you two messed up the extension of the same site/origin policy with the resource access authorization. You even got your purpose wrong. As for your example, your sole purpose on extending same site/origin policy is to extend the capability of evil.com/a.html while keeping the evil from being poisoned. As for your example, your purpose is "not to protect the bank", but to extend the capacity of the evil to guarantee the evil can do its evil thing. How to protect the resource at bankA.com is another issue. Its protection should not rely on how to extend the capability of evil.com while keep the evil from being poisoned.

Travis is working for Microsoft, what you said surprised me. For many times, I felt powerless to clarify some simple things. This is one incident of it, let me try to put it this way: Suppose you are working as a CIA field data analyst(evil.com/agentA.html) within US government(browser). In the old days the same site/origin policy allows you to analyze only files from CIA(evil.com). We all know that you should be allowed to analyze files from any where as long as you need it, such as files from a terrorist office(bankA.com a terrorist disguises as a banker), so we have to extend the same site/origin policy to allow you (agentA.html) to access any file as you needed after the government assigns you the job(browser load the page agentA.html).

Here, the security issue is how the US government(browser) should protect you (agentA.html) from being poisoned/killed by files from any terrorist's office. The script element approach(JSONP) would give a terrorist the opportunity to poison you through the files. So a dedicated approach for CORS data fetch is indeed needed.

The wrong of W3C CORS/fetch is to design a system which puts a note on every file folder saying that who with what kind of method can access it. And the US government(browser) imposes the rules stated by the note when it(government) fetches the file for you(agentA.html). Isn't this US government and the W3C's recommendation stupid?

And what you two said is that permission for you(agentA.html) to analyze files from terrorist's office should be granted by the note on the file folder, isn't it totally nonsense? I guess you two are not working on computer security.

I am looking forward to responses from people who think they really understand the issue. If you do, please comment.

with best regards Jack (Zhan, Hua Ping詹华平) +85-153-9230-9232 QQ: 94544458 欢迎加我,欢迎访问QQ空间 twitter: twitter.com/jackzhp/with_replies

# Jack (Zhan, Hua Ping) (6 days ago)

#1, really appreciate your discussion. .#2. I know "just add this to your apache config: Header set Access-Control-Allow-Origin "*"" .#3. Most of what your wrote, I agree. Only a few sentences I do not agree. Since my purpose is not to make each of your sentences perfect right, and even if I do that we might go nowhere, so let me use a specific example to ask a question:

As for Travis's example, should a browser allow evil.com/a.html to access bankA.com/somedata? Be noted .#1. somedata is not any data, let me be more specific, the data is the ticker info of MSFT and this kind of data does not require user authentication. (It seems that you are in trade business). .#2. web browser is just a UI (your UA), as web OS, so browser should not restrict a program here a.html to do whatever the user wants to do. It is the user who loads evil.com/a.html. .#3. As I know there is no browser prevents a.html to load bankA.com/somejavascriptcode. .#4. In this example, what we care is the security of a.html not the bank.

Jack

# Jake Archibald (6 days ago)

On Tue, 10 Oct 2017, 21:25 Jack (Zhan, Hua Ping), jackiszhp@gmail.com

wrote:

Either Adobe has changed their design after W3C published its stupid design in 2005 or I misunderstood Adobe's way which is possible though I do not think it is probable.

I think it's probable you misunderstood. Maybe you made the same mistake as this person? stackoverflow.com/a/2653708

Please comment on "JMBW way of specifying the same origin", why those

smart people do not implement it this way, why it is not good? Enlight me.

Your proposal would expose users' personal data, such as emails, to any attacker that wants them. Users, including myself, wouldn't be too happy about this. Thankfully, smart people realised that.

# Florian Bösch (6 days ago)

You don't control evil.com, you control bankA.com. You don't want evil.com access bankA.com/mybalance with a data request because it is private information. evil.com could XHR get bankA.com/mybalance and then XHR post it to evil.com/save. The same origin policy that restricts data requests to the same origin solves that problem. But it creates a new problem, how does somesite.com offer resources to use by othersite.com, such as, for instance, twitter. The answer is for somesite.com to offer a permission on a resource, that's what CORS is. evil.com does not control the users computer or UA. If the user chooses to use a browser that does not implement the same-origin policy, that's his choice, it's not a smart choice, because then this bankA.com/mybalance will end up on evil.com/save.

# Jack (Zhan, Hua Ping) (6 days ago)

As for Travis's example, should a browser allow evil.com/a.html to access bankA.com/somedata?

On Wed, Oct 11, 2017 at 6:12 AM, Florian Bösch pyalot@gmail.com wrote:

You don't control evil.com, you control bankA.com. You don't want evil.com access bankA.com/mybalance with a data request because it is private information. evil.com could XHR get bankA.com/mybalance and then XHR post it to evil.com/save. The same origin policy that restricts data requests to the same origin solves that problem. But it creates a new problem, how does somesite.com offer resources to use by othersite.com, such as, for instance, twitter. The answer is for somesite.com to offer a permission on a resource, that's what CORS is. evil.com does not control the users computer or UA. If the user chooses to use a browser that does not implement the same-origin policy, that's his choice, it's not a smart choice, because then this bankA.com/mybalance will end up on evil.com/save.

That's exactly what I said "you guys messed up your purpose". If I am wrong, please enlight me a little bit more.

You are a web programmer, and your team are working on evil.com/a.html. Your task is to get the ticker data of MSFT from bankA.com/ticker/MSFT and show it to the user who loads a.html provided by you. Why the browser should deny a.html to load the ticker data?

And I am working for the bankA.com, it is my job to prevent you from access protected resources, while you are welcome to use public data such as MSFT's ticker data. It is not your job to make sure sensitive data on bankA.com is protected. By the way I deem CORS is stupid, so I will not serve you the header "Access-Control-Allow-Origin "*"". It is your browser stopped you from access the public available data from bankA.com, not me. Since you did not ask how I prevent you from access confidential data on bankA.com, I omit this.

Jack (Zhan, Hua Ping詹华平)

# Tab Atkins Jr. (6 days ago)

On Tue, Oct 10, 2017 at 3:58 PM, Jack (Zhan, Hua Ping) jackiszhp@gmail.com wrote:

As for Travis's example, should a browser allow evil.com/a.html to access bankA.com/somedata?

On Wed, Oct 11, 2017 at 6:12 AM, Florian Bösch pyalot@gmail.com wrote:

You don't control evil.com, you control bankA.com. You don't want evil.com access bankA.com/mybalance with a data request because it is private information. evil.com could XHR get bankA.com/mybalance and then XHR post it to evil.com/save. The same origin policy that restricts data requests to the same origin solves that problem. But it creates a new problem, how does somesite.com offer resources to use by othersite.com, such as, for instance, twitter. The answer is for somesite.com to offer a permission on a resource, that's what CORS is. evil.com does not control the users computer or UA. If the user chooses to use a browser that does not implement the same-origin policy, that's his choice, it's not a smart choice, because then this bankA.com/mybalance will end up on evil.com/save.

You are a web programmer, and your team are working on evil.com/a.html. Your task is to get the ticker data of MSFT from bankA.com/ticker/MSFT and show it to the user who loads a.html provided by you. Why the browser should deny a.html to load the ticker data?

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

And I am working for the bankA.com, it is my job to prevent you from access protected resources, while you are welcome to use public data such as MSFT's ticker data. It is not your job to make sure sensitive data on bankA.com is protected.

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.

By the way I deem CORS is stupid, so I will not serve you the header "Access-Control-Allow-Origin "*"". It is your browser stopped you from access the public available data from bankA.com, not me. Since you did not ask how I prevent you from access confidential data on bankA.com, I omit this.

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

# Jack (Zhan, Hua Ping) (6 days ago)

You work on browsers? I am very glad to know you!

I can protect sensitive data on 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 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 evil.com/a.html designed by Florian Bösch pyalot@gmail.com wants to load 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 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

# Florian Bösch (6 days ago)

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:

# Jake Archibald (6 days ago)

On Wed, 11 Oct 2017, 01:02 Jack (Zhan, Hua Ping),jackiszhp@gmail.com

wrote:

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.

Some resources can be fetched without CORS (the spec calls these no-cors requests), and some APIs can consume them under certain conditions, such as img, media, CSS and script.

In many ways, this was a mistake, and they're a vector in a lot of privacy attacks. Eg goo.gl/UPV32Q (pdf) which resulted in restrictions being applied to CSS.

Although, it's worth noting that when site A executes a script from site B, it is giving site B full control over the page and storage on its origin.

# Florian Bösch (6 days ago)

On Wed, Oct 11, 2017 at 9:41 AM, Jake Archibald jakearchibald@google.com

wrote: >

Although, it's worth noting that when site A executes a script from site B, it is giving site B full control over the page and storage on its origin.

On a tangent it's a pity there doesn't exist a way for a page to load in a script from another source but have it executed securely in a sandbox with limited access to some of the pages context. It sure would be nice not to give twitter, google, discus, etc. "root" privileges on your site just because you want some functionality from them.

# Maciej Stachowiak (6 days ago)

Sent from my iPad

On Oct 11, 2017, at 12:54 AM, Florian Bösch pyalot@gmail.com wrote:

On Wed, Oct 11, 2017 at 9:41 AM, Jake Archibald jakearchibald@google.com wrote: Although, it's worth noting that when site A executes a script from site B, it is giving site B full control over the page and storage on its origin.

On a tangent it's a pity there doesn't exist a way for a page to load in a script from another source but have it executed securely in a sandbox with limited access to some of the pages context. It sure would be nice not to give twitter, google, discus, etc. "root" privileges on your site just because you want some functionality from them.

iframes can work for this. They even give the off-site script a sanboxed area to present content and have a safe way to interact with embedding page script via postMessage.

# Jack (Zhan, Hua Ping) (5 days ago)

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 evil.com/a.html , you want to load 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 bankA.com. And as what I proposed, a.html has already told the browser to deem bankA.com as same origin. (Tab Atkins has not respond on this by now)

Suppose now your evil.com/a.html want to get 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 bankA.com. But now, I, the person who is responsible for the security of bankA.com will deny you from accessing this. You are designing 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 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 anyEvil.com from requests referred by bankA.com/entrypoint, let me omit this.

By now, I guess you are convinced that browser should serve your evil.com/a.html with bankA.com/ticker/GOOG as long as a.html tells browser to deem bankA.com as same origin while bankA.com does not send the header (Access-Control-Allow-Origin "*").

By the way, when bankA.com/entrypoint is loaded, I do not tell browser to deem evil.com as the same origin.

And I hope you stop dreaming about how browser and I should take care of the security of bankA.com. Please just focus on your own job: use evil.com/a.html to access 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 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: twitter.com/jackzhp/with_replies

# Florian Bösch (5 days ago)

On Wed, Oct 11, 2017 at 10:52 PM, Jack (Zhan, Hua Ping) <jackiszhp@gmail.com

wrote:

Since everything and everyone is stupid, messed up and incompetent according to you, It seems that you want everybody to be my enemy.

You don't need my help for that.

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.

I didn't presume on your qualification, I told you that I don't understand your incoherent writing.

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:

You have not. And I ask again. How do you instruct a browser which resource is ok to request from another origin?

# Jack (Zhan, Hua Ping) (5 days ago)

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: 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 bankA.com.

with best regards Jack (Zhan, Hua Ping詹华平) +86-153-9230-9232 QQ: 94544458 欢迎加我,欢迎访问QQ空间 twitter: twitter.com/jackzhp/with_replies

# Florian Bösch (5 days ago)

On Thu, Oct 12, 2017 at 12:00 AM, Jack (Zhan, Hua Ping) <jackiszhp@gmail.com

wrote:

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 bankA.com.

Effectively you want to get rid of the same-origin policy. This isn't going to happen because everybody else relies on it working. CORS exists because the same-origin policy exists. And the same-origin policy exists to avoid exposing side effects and data to third parties for data requests which where introduced to the web at a later stage when there was already a large volume of existing sites which couldn't all be changed.

In essence it seems you're not happy with how history went, and you'd like the entire world to change all at once so that you can avoid adding a perfectly functional http header...

# Tab Atkins Jr. (5 days ago)

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: 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 bankA.com.

And that's the thing. You might do that, and be safe from evil websites grabbing your customer's personal information. Long, painful experience shows us that most websites do not do that.

So, we have two choices:

  1. Make websites default to being "open" cross-origin, and depend on website owners to lock down pages with private info on their own. Pro: good websites can share information cross-origin really easily. Con: a lot of people get their private information stolen, and the web as a whole has sucky security.
  2. Make websites default to being "closed" cross-origin, and let website owners explicitly open them up if they're safe to share. Pro: most pages are safe from evil websites by default. Con: slightly more work for websites to share public information.

The web went with #2, and as a result you have good security by default. (As Jake has said, some resources that were linkable in the early web, like images, are stuck with #1. Changing them at this point would break too much of the web, but as a result we have regular security issues.)

This is a result of pretty basic security practices that are now common on the web. It's not going to change. You've had the reasoning behind CORS explained to you several times, and why your suggestions for an alternate system would be bad for security and won't be accepted by browsers today.

Unless you have further actual questions, continuing in this thread will not be productive. You will not change anyone's minds, because we've thought about the security implications quite a bit before settling on the current CORS design. It's a compromise, and has some downsides, but overall it results in a much safer web with relatively little pain.

~TJ

# Jack (Zhan, Hua Ping) (5 days ago)

Effectively you want to get rid of the same-origin policy. This isn't going to happen because everybody else relies on it working. CORS exists because the same-origin policy exists. And the same-origin policy exists to avoid exposing side effects and data to third parties for data requests which where introduced to the web at a later stage when there was already a large volume of existing sites which couldn't all be changed.

In essence it seems you're not happy with how history went, and you'd like the entire world to change all at once so that you can avoid adding a perfectly functional http header...

No. I want the old style same origin policy almost unchanged, just relax a bit Did you read lists.w3.org/Archives/Public/public-webapps/2017OctDec/0024.html?

Seems to me you do not get my point, I do not know what is missing for you not to understand me. That browser allows evil.com/a.html to load bankA.com/ticker/MSFT with the same origin policy does not compromise the security of bankA.com. If you think the security of bankA.com/LastTransactionOfISISaccount is compromised, then defeat me please.

Why do I want the browser to serve you a.html? Because many sites they just did not serve the header you are eager for! There is no point for me, the manager of bankA.com, to delegate authorization check to a remote browser.

Jack (Zhan, Hua Ping詹华平)

# Stefan Zager (5 days ago)

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

# Jack (Zhan, Hua Ping) (5 days ago)

Your black list vs. white list is the best reasoning for CORS I have ever seen.

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.

You misunderstood me. Please read lists.w3.org/Archives/Public/public-webapps/2017OctDec/0024.html or #0014 post again.

What I said is that the government is evil, the government is trying to use evil.com/a.html to access data from my website: bankA.com/ticker/MSFT (which is public data) and bankA.com/LastTransactionOfISISaccount (which is confidential data). The bank is not an evil.

Since you are not saying my way has a flow in it, so I do not have to challenge you. But I really hope Florian and Tab Atkins can accept my challenge to defeat me.

I want the configurable same origin policy at the browser side(Florian said I do not want same origin policy which is not right), what I do not need is the CORS which is the authorization thing. And I, as the manager of bankA.com, do not need to delegate the authorization checking procedure to a remote browser and I believe no server should trust and delegate the authorization check to the remote browser. Any server's security relies on that should be defeated easily, that's a real security hole.

And I believe with my proposal to extend the same origin policy, CORS thing can retire since it is redundant so useless.

Your black & white list thing is nice. But the link you gave is not from that perspective, instead saying something that is not really relevant. Florian Bosch & Tab Atkins seems to suggest with what I proposed (see the #24 post & #2 post), there is a security issue. Hence, I hope they can tell me how to stole the confidential data from my site.

with best

# Jack (Zhan, Hua Ping) (5 days ago)

When you said in

#0015(lists.w3.org/Archives/Public/public-webapps/2017OctDec/0015.html):

Because the browser cannot automatically tell what page data contains sensitive information and what doesn't.

seemed to me you suggested there is a flaw in my proposal. By the way I responded in # 0016 that I do not expect a browser to do that.

Now you said

You might do that, and be safe from evil websites grabbing your customer's personal information.

seems to me that you no longer suggest there is a flaw in my proposal. May I say that you admit there is no flaw in my proposal?

If you still think what I proposed is flawed, then please try to defeat me. For your convenience: Please #24: lists.w3.org/Archives/Public/public-webapps/2017OctDec/0024.html or # 0014 not the beginning, but the rear part.

(As Jake has said, some resources that were linkable in the early web, like images, are stuck with #1. Changing them at this point would break too much of the web, but as a result we have regular security issues.)

According to www.linshunghuang.com/papers/css.pdf, The success of it relies on: .#1. the server did not do authorization check for its "secrete data". .#2. evil.com/a.html can inject string into bankA.com/LastTransactionOfISISaccount after the latter is loaded.

By the way, my point is that CORS should not be adopted from beginning while the approach I proposed should be adopted.

why your suggestions for an alternate system would be bad for security and won't be accepted by browsers today.

I still did not see why "bad for security", and for adoption, I would say no web server relies on CORS for authorization check, so there is no point to assume the importance of the authorization mechanism defined by CORS.

As for the term "CORS", I think we had better call it delegation of resource authorization from web server to web browser.

Since the "close" cross origin approach is adopted, then Mozilla's web OS concept will be defeated.

with best

# sirdarckcat.work (5 days ago)

I finally decided to respond to your email.

I think your proposal makes sense. In fact, it makes so much sense it's already implemented in most browsers under the Extensions API. It's technically not a web API, but who cares, right?

Chrome: developer.chrome.com/apps/xhr Firefox: developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions Safari: developer.apple.com/library/content/documentation/Tools/Conceptual/SafariExtensionGuide/ExtensionPermissions/ExtensionPermissions.html Opera: dev.opera.com/extensions/match-patterns Edge: docs.microsoft.com/en-us/microsoft-edge/extensions/api-support/supported-manifest-keys

They protect you against the government and the CIA and the banks and the terrorists and everything. The way this will work is by having the CIA open the extension and then the government will allow the extension to access the product of the bank. You will be able to access the MSFT stock ticket from a.html and b.html.

It works, it's glorious, it's awesome, and it has nothing to do with CORS.

Regards

On Thu, Oct 12, 2017, 08:33 Jack (Zhan, Hua Ping) jackiszhp@gmail.com

wrote:

# Jack (Zhan, Hua Ping) (4 days ago)

I can see that sirdarckcat.work is very angry at me, browser extension API he mentioned is not a uniform & ubiquitous approach for wide web applications since browser plug ins can do anything if not in a integrated way. I thought web OS means any regular web app can do any job as long as it do not interfere other apps running in the same browser. I would prefer he could say the approach proposed by me is stupid because #1… #2….

jack

# Jack (Zhan, Hua Ping) (4 days ago)

Concerning "CORS", its original purpose is to relax the same site(origin) policy to meets web developers’ need:

When 1st.com/a.html is being loaded in a browser, a.html requires a piece of data from

2nd.com/tickerMSFT or secreteData. Let me stop use Travis' evil.com & popularbank.com, I am afraid that some people stop thinking clearly when they see the word “evil”. It seems the word stir up their emotions.

In the old days, browsers do not allow a.html from 1st.com to load any data from 2nd.com because of the same site policy imposed by browsers. Though code is allowed, so web developers got around it to load data by embedding the data into javascript code. Illustrated as follows.

if 2nd.com/tickerMSFT contains

{timestamp:1234234,bid=70,ask=80}

we change its content to

var vname={timestamp:1234234,bid=70,ask=80};

then when it is loaded with a script element in a.html, a.html can access vname, that’s the data it needs. This is the script element approach.

or we change its content of tickerMSFT to

functionName('{timestamp:1234234,bid=70,ask=80}');

where functionName is a function defined in a.html, when the above code is loaded, the function is executed, and a.html have access to the data. This is called jsonp approach since the functionName is padded to the request made to 2nd.com/tickerMSFT.

Either approach works, but they brought security issues, since whatever is loaded is executed. While the original needs of a.html is to load data, not code, especially a.html does not want whatever loaded from other sites to be utilized before examined. So we need browsers to relax the same site policy to allow a.html to load anything from other sites in a secure manner: we hoped there is a mechanism for a.html to instruct the browser to deem other sites as same origin, so data can be loaded as needed. Concerning codes from other sites, I will discuss it in other threads.

Without browser support, to ensure a.html to get what it needs in a secure manner, the only way is to load 2nd.com/tickerMSFT at server 1st.com then, after being checked, serve a.html the data conform the same site policy imposed by browsers.

The above is the situation before the first version of CORS is released. The context is that 1st.com needs the public resources on other sites such as 2nd.com, but do not trust them completely. Please focus on this, and do not act like many people to mess around and to dream about the securities of those other sites. If you really care, I will talk about it later.

People like Florian Bosh & Tab Atkins were thinking how should they instruct browsers to distinguish

requests for public data such as tickerMSFT from requests for secreteData. They thought if a.html is allowed to load tickerMSFT from 2nd.com, then it can also load secreteData from 2nd.com. I guess the authors of CORS(Matt Oshry, Brad Porter, J Auburn, and Anne Van Kesteren) must think in same way, so those people devised a domain based referrer authorization check mechanism (CORS) to be imposed by browsers.

The mechanism requires authorization rules (access control) to be defined for all resources and the authorization rules are mainly imposed by browsers. For example, the authorization rules on secreteData is declared for browsers to allow access from some sites with some specific methods (1st.com might not be in the list), and rules (access control) on publicData such as tickerMSFT is declared for browsers to allow access from all domain (Access-Control-Allow-Origin "*") with any method.

I think they went too far and off road(while I can only see 1 step ahead) from what we are looking for. Clearly, here, the authorization check is the responsibility of 2nd.com, not of browsers. Florian Bosh(post #0015) & Tab Atkins(post #0017 and #0025) thought it is the responsibility of browsers. Florian Bosh & Tab Atkins never asked how the manager of 2nd.com can distinguish requests referred by 1st.com from requests referred by 2nd.com/entrypoints. I would guess they know, and I guess we all know, so let me omit this. Since the designer of 2nd.com can and must do authorization check (referrer based, user or role based, time base, etc) on resource access, at least on access to secreteData, there is no need for 2nd.com to delegate authorization check from their own web server to browsers. And no security wary manager will allow the authorization check of their protected resources to be dependent on browsers.

To meet the cross origin needs of web developers for then and now, the simplest solution is for 1st.com/a.html to instruct browsers to deem 2nd.com as same origin either with <meta name="sameOrigin" content="[http://2nd.com](http://2nd.com)"/> or with a http header.

This directive mechanism is asymmetric since this directive does not imply 2nd.com also deems 1st.com as same origin.

As long as browsers can take this into same origin (I use term “origin” since it is not just one site) check procedure, then our original purpose is fulfilled, web developers’ need is satisfied.

If this approach is taken, does it bring any new security issue? No, none. Since any request made to 2nd.com is what a.html needed and in a way prescribed by it: The responses from 2nd.com is treated as data, either json objects or text, or html. a.html has control on the use of it, and any security check could be done before make use of it. If you think it brings any new security issue, please enlight me!

If this approach is taken, does it solve some security issues? Yes, at first, the approach with script element or with jsonp can be avoided. As explained earlier, they are not secure since they are javascript code, and executed before being examined by its user – a.html. Furthermore, cross site attack can be avoided even an attacker from 3rd.com (I do not like the term evil here either) can inject any strings (codes) into a.html. Since a.html did not tell browsers to deem 3rd.com as same origin, so browser will not allow any request to be made to 3rd.com. By the way, with CORS, for the same situation, confidential data can be sent to 3rd.com/receiver without any obstacle. If you think I am wrong, please enlight me.

As for our original purpose, from web developers’ point of view, this approach is the best solution. This approach meets the cross site needs of web developers by supporting data access to other sites in a secure manner while not bringing any new security issue.

Be noted a.html has access to 2nd.com/publicData does not mean it has access to 2nd.com/secreteData as 2nd.com has authorization check procedure for its secreteData. Don’t tell me that manager at 2nd.com do not do authorization check for its protected data at server side, and solely rely browsers to do the authorization check. Stefan Zager is a nice reminder: at server side the white list approach should be taken, only resources in the white list can bypass some authorization check. Don’t tell me that the manager forgot to do so, and so browsers step forward and nicely take the responsibility for the protection of his confidential data. Don’t tell me you think the referrer based authorization check can be safely delegated from server side to browsers. With CORS, the referrer based authorization check reduced to domain based check. Any way, if you do, I would say that’s stupid.

All the respondents to my post murmurs about cross site security issue. But no one really gets to the substantial point: the simple approach I proposed brings what extra security issues. I would say none. If you think there is any, please enlight me!

Of course, you can always say: CORS – the domain based referrer authorization check at browser side – as an extra layer of security does no harm. I would say if you utilize CORS to do domain based referrer authorization checking done by browsers, you know it is redundant since you must have done so at server side, and If you rely on that, you are encouraged by those incompetent professionals to build a cranky security system! I would guess in reality when CORS is used, most of them is the header that Florian Bosch is eager for. Overall for parsimony reason, CORS should retire.

If we look at the problem from browser designers’ point of view, as I promised before: “I will talk about later”, the same site/origin policy is a derived term from the sandbox structure utilized in browsers to prevent different web applications from interfering each other. Each of different websites is put into different sandboxes. It is the sandbox structure that obstructs cross site data access.

There might be some websites, since they do not have any real confidential data to protect so they do not do authorization check at server side, instead they rely on browsers to do the domain based referrer authorization check (I have to admit that this sentence is logically flawed) or websites do have authorization check at server side, but still they want to utilize an extra layer of authorization, is there any way for resources to instruct browsers that the resources should only be put into some specific sandboxes? We can say to this aim, CORS is devised, clearly this is against the parsimony principle since domain base referrer authorization check if needed should be done at server side.

Some people like Tab Atkins (post #0028) and Stefan Zager(post #0030) said it would be better that by default all resources should only be allowed to be put into the sandbox for its website, and should not be put into any other sandboxes unless stated otherwise. Let’s call this as “mandatory directive”. Tab Atkins acknowledged in post #0028 that “(As Jake has said, some resources that were linkable in the early web, like images, are stuck with #1. Changing them at this point would break too much of the web, but as a result we have regular security issues.)” I hope nobody misunderstood the last sentence which says if we impose the “mandatory directive”, then “too much of the web” is broken. In fact, not only “the early web”, many new websites do not conform to the mandatory directive by serving the header that Tab Atkins suggested and Florian Bosch is eager for(Access-Control-Allow-Origin: *). The language ability of Tab Atkins is the height that I am not able to achieve. When he said that, he gave people the impression that he is opposing the change in order not to “break too much of the web”, isn’t it? In fact, it is he who insisted “the mandatory directive” which “breaks too much of the web”. Did you misunderstood him as a result of his misleading sentence?

If the mandatory directive of CORS can be removed and add the approach I proposed above, then we achieve the seamless extension of the same origin policy. It is OK to remove the mandatory directive as no web server’s confidential data is dependent on it. By the way, when browsers found any resource cross site referred does not conform to the mandatory directive, browsers, if Tab Atkins likes, can make an extra request to notify the server such as 2nd.com/CORSmandatoryViolation/theReferredResouce. Although this request will not have a response, when the manager of 2nd.com look at the log, they will notice it.

In a word, even to keep the CORS, there is no point to impose the mandatory directive. And I really hope the approach I proposed can be added to avoid “breaking too much of the early web” and the web that does not conform to CORS’ mandatory directive and to prevent cross site attacks even the attacker got the opportunities to inject strings!

As Jake Archibald mentioned, semantics of Adobe “allowOrigin” in a.html(if) is to allow code from 2nd.com to be executed in 1st.com/a.html. In web, this is implicit as code can always be loaded and executed from anywhere. Given our original purpose on extending the same origin policy is for data access, so “allowOrigin” should have the semantics of instructing browsers to allow a.html to make request to 2nd.com for data.

I feel the point I want to make is simple, but I found that people can not understand me. Is it because the words such as “stupid” drag people off the road to point I want to make? Originally, I thought as long as I raised the question, you smart guys could right the wrong, and I do not have to spend time on this. Unfortunately, it did not go well, so I write this long post. If you find any mistake in this post, please let me know where I am wrong, but please do not utter/murmur some general statements while not getting to any substantial point.

Thank you for reading this post. Hope you can contribute to the needed change as I proposed.

Best

# Anne van Kesteren (4 days ago)

On Thu, Oct 12, 2017 at 7:03 PM, Jack (Zhan, Hua Ping) jackiszhp@gmail.com wrote:

I feel the point I want to make is simple, but I found that people can not understand me. Is it because the words such as “stupid” drag people off the road to point I want to make? Originally, I thought as long as I raised the question, you smart guys could right the wrong, and I do not have to spend time on this.

It certainly doesn't help that you repeatedly violated www.w3.org/Consortium/cepc and continue to use sexist language: notapattern.net/2014/10/14/ways-men-in-tech-are-unintentionally-sexist. Furthermore, despite multiple people having given you helpful references as to why you're wrong about the same-origin policy you continue to insist that instead everyone else is wrong, as well as a standard adopted by four independent browsers engines and many many websites. You ask everyone else to go in depth, but you haven't really refuted any of the points and articles brought forward.

I'll try one more time, pointing you to annevankesteren.nl/2015/02/same-origin-policy, which hopefully illustrates to you why 1st should not be allowed to access 2nd beyond the extend that it can for legacy reasons.

# Mike Samuel (4 days ago)

On Thu, Oct 12, 2017 at 1:03 PM, Jack (Zhan, Hua Ping) jackiszhp@gmail.com wrote:

2nd.com/tickerMSFT or secreteData. Let me stop use Travis' evil.com & popularbank.com, I am afraid that some people stop thinking clearly when they see the word “evil”. It seems the word stir up their emotions.

I agree. All this talk about evil.com is out of scope and better handled by reference to other standards. CORS should adopt a permissive model within the bounds set by RFC 3514.

# Léonie Watson (4 days ago)

Chaals already posted a reminder about politeness and acceptable behaviour [1]. The Web Platform chairs prefer not to remove people from public-webapps unless it's necessary, but we will if we have to.

Words like "stupid", and phrases like "incompetant professional", are not acceptable when referring to other people. Please be respectful, even if you disagree with someone's technical position.

Léonie, on behalf of the WebPlat co-chairs [1] lists.w3.org/Archives/Public/public-webapps/2017OctDec/0022.html

# Jack (Zhan, Hua Ping) (4 days ago)

Chaals already posted a reminder about politeness and acceptable behaviour [1]. The Web Platform chairs prefer not to remove people from public-webapps unless it's necessary, but we will if we have to.

Words like "stupid", and phrases like "incompetant professional", are not acceptable when referring to other people. Please be respectful, even if you disagree with someone's technical position.

Léonie, on behalf of the WebPlat co-chairs [1] lists.w3.org/Archives/Public/public-webapps/2017OctDec/0022.html

You are telling me people are very weak, can be hurt very easily. I am sorry since I am from low society so I did not pay much attention to the words. Let's focus on the issue itself.

If anyone think the approach I proposed is stupid, I am expecting she/he can tell me straight forward: what you proposed is stupid because of #1...., #2...... And I will appreciate the feedback to the point. I would not get hurt since I do not assign much value or power to those words.

with best regards Jack (Zhan, Hua Ping詹华平) twitter: twitter.com/jackzhp/with_replies

# Mike Samuel (4 days ago)

On Thu, Oct 12, 2017 at 3:03 PM, Jack (Zhan, Hua Ping) jackiszhp@gmail.com wrote:

Chaals already posted a reminder about politeness and acceptable behaviour [1]. The Web Platform chairs prefer not to remove people from public-webapps unless it's necessary, but we will if we have to.

Words like "stupid", and phrases like "incompetant professional", are not acceptable when referring to other people. Please be respectful, even if you disagree with someone's technical position.

Léonie, on behalf of the WebPlat co-chairs [1] lists.w3.org/Archives/Public/public-webapps/2017OctDec/0022.html You are telling me people are very weak, can be hurt very easily. I am sorry since I am from low society so I did not pay much attention to the words. Let's focus on the issue itself.

If anyone think the approach I proposed is stupid, I am expecting she/he can tell me straight forward: what you proposed is stupid because of #1...., #2...... And I will appreciate the feedback to the point. I would not get hurt since I do not assign much value or power to those words.

.#1 To quote Travis, "A self-granting permission model just isn't secure--the permission grant must come from the resource being requested."

.#2 Most distributed systems use both public and non-public APIs. The public APIs are carefully vetted, but the non-public APIs often make assumptions about their inputs because those inputs come from a smaller, more tightly controlled set of endpoints.

CORS isn't for public APIs. CORS makes it easier for components of a distributed system to collaborate via non-public APIs.

When you suggest adding your site to bank.com's list, you are effectively saying "I should have access to non-public APIs because I am an integral part of that distributed system and the implementation of those non-public APIs took my service into account." That is simply not true.

If you dislike the fact that bank.com's public APIs don't suffice, ask them to extend their public APIs.

If you notice that bank.com has a non-public API that does what you want but is CORS restricted, you're out of luck. Even if CORS changed, the API is not public and they may change or remove it at any time.

# Jack (Zhan, Hua Ping) (3 days ago)

Chaals already posted a reminder about politeness and acceptable behaviour [1]. The Web Platform chairs prefer not to remove people from public-webapps unless it's necessary, but we will if we have to. Words like "stupid", and phrases like "incompetant professional", are not acceptable when referring to other people. Please be respectful, even if you disagree with someone's technical position. Léonie, on behalf of the WebPlat co-chairs [1] lists.w3.org/Archives/Public/public-webapps/2017OctDec/0022.html

Do we have something called "freedom of speech"? I think president Trump is incompetent and stupid, am I allowed to say that? I think you are incompetent, you want me not to speak it out, you want me to baby you?

I came from China, Communist Party of China shut me out from politics. You gave me the impression that you want shut me out from this discussion. I would say everyone have to the right to choose their own language. While your responsibility might be to remind people the purpose of this mail list. I do not think your responsibility is to remove me though you have the right. I guess you are a professional in communication, so may I suggest you to put this way:

Ladies & Guys, let's focus on the tech issue, and please ignore any subjective terms.

When I say you are professionally incompetent, I would hope you can beat me professionally on the tech issue, rather than shut me out. Anne seemed to be very proud of the wide adoption of CORS, if it is a real good thing, that's good. If it is a stupid thing, it is almost a tragedy since lots of unnecessary spending wasted, why is so? I would guess shutting people out might be one of the reasons, then Anne could publish her stupid recommendation, then the whole world followed. If this is what you are looking for, you and Anne are very competent. If what you are looking for is to ensure real and good tech to emerge and to lead the world, you and Anne are incompetent(I judge from what I have seen).

You are welcome to refute me on what I wrote, #0035. or better formatted version here blog.sina.com.cn/s/blog_93b70ae70102wxe8.html or jackzhp/CORS-should-retire

By the way, you know that it seems that if you remove me out of public-webapps, I guess I am going to die.

with best

# Florian Bösch (3 days ago)

On Fri, Oct 13, 2017 at 4:50 PM, Jack (Zhan, Hua Ping) jackiszhp@gmail.com

wrote:

Do we have something called "freedom of speech"?

Freedom of speech prevents the government of infringing yours. It does not grant you a right of participation in a private forum. You are not in a public place, you are in a private place as a guest, and this place has the prerogative to throw you out and not hear you. If you visit someones home and do all kinds of things they disapprove of at their home, you can expect to be shown out the door, no difference here.

# Jack (Zhan, Hua Ping) (3 days ago)

Freedom of speech prevents the government of infringing yours. It does not grant you a right of participation in a private forum. You are not in a public place, you are in a private place as a guest, and this place has the prerogative to throw you out and not hear you. If you visit someones home and do all kinds of things they disapprove of at their home, you can expect to be shown out the door, no difference here.

Oh. then I am very sorry, accidentally I got into this private place. I really thought it is a public place. According to you, I am wondering where I can find a public place on line. Government's website directly owned by government?

By the way, since this is a private place, then do I have to pay for the discussion service?

It is easy to throw me out, it is not easy for you ladies and guys to figure out CORS is stupid garbage. (my personal point, you can insist I am wrong and I am stupid. You can see how different our views are. You ladies and guys vs me, either one party must be incompetent, we have to admit this.) I would hope you can refute me on my post

#0042(almost exactly same as #0035).

I guess this forum is not a place to talk about what freedom of speech is. I am still expecting you to refute me on what I wrote in #0042 (almost same as #0035). Please focus on the tech issue. By the way, after I told you I do not require browsers to distinguish requests for sensitive data from requests for protected data, you stopped discussing the issue with me. Why is so? You still think what I wrote in #0042 made no sense at all, am I right?

with best

# Florian Bösch (3 days ago)

On Fri, Oct 13, 2017 at 5:50 PM, Jack (Zhan, Hua Ping) jackiszhp@gmail.com

wrote:

Freedom of speech prevents the government of infringing yours. It does not grant you a right of participation in a private forum. You are not in a public place, you are in a private place as a guest, and this place has the prerogative to throw you out and not hear you. If you visit someones home and do all kinds of things they disapprove of at their home, you can expect to be shown out the door, no difference here. Oh. then I am very sorry, accidentally I got into this private place. I really thought it is a public place.

Everything not owned or operated by the government is a private place. This place is owned and run by W3C (not a government organization). Public here means that the public can view it and participate (rather than a select group of people). Participation is contingent on you obeying the rules set forth by your host. You have shown no inclination to do so.

# Jack (Zhan, Hua Ping) (3 days ago)

Anne is a male, not female, just FYI ;)

You really surprised me. Now, I know this mail list is not to talk about tech issue, but focusing on something else, such as to teach other people not to be sexist, to be polite, etc.

Previously Anne sent me this:

It certainly doesn't help that you repeatedly violated www.w3.org/Consortium/cepc and continue to use sexist language: notapattern.net/2014/10/14/ways-men-in-tech-are-unintentionally-sexist.

and I apologized for what is being accused as follows: Oh. For this, I do apologize I do not know "guys" means anything. As previously, I noticed a female called other girls "you guys", so I thought it is just the language. I had several female programmers as colleague. Please believe me I am not a sexist and please let's focus on the tech issue at hand.

And previously Chaals & leonie watson, they did not respond on tech issue, but on something else. Clearly, their behaviour reflected that they are incompetent professionals, so what they are able to do is not tech itself.

Jack (Zhan, Hua Ping詹华平)

# Jack (Zhan, Hua Ping) (3 days ago)

Everything not owned or operated by the government is a private place. This place is owned and run by W3C (not a government organization). Public here means that the public can view it and participate (rather than a select group of people). Participation is contingent on you obeying the rules set forth by your host. You have shown no inclination to do so.

If you have the right to remove me out, do so. I am expecting you to respond on tech issue, anything else, I will stop respond to you.

If you are not able to participate tech issue, but only be interested in enforcing the rules. What can I say? It's your call. Remember if you think you are tech professional, please refute me on .#0042 post, focus on tech issue, and to the substantial point.

Jack

# Jack (Zhan, Hua Ping) (3 days ago)

I am saying that 1st.com is not trustworthy to the end user.

what 1st.com does is that it shows your all kinds ticker data. 1st.com gets them from many places. what 1st.com does just like googel finance, yahoo finance. You can just check some information. Because google got data from NewYork exchange, then you think google is not trustworthy?

I am not worried about 1st.com being hacked. I am primarily worried about two things:

  • 1st.com is malicious
  • 2nd.com is insecure

You as an end user, you are using the service provided by 1st.com, it does ask your personal information. Why do you care? It will not eat you. Don't be afraid. 2nd.com is just a partner of 1st.com. 1st.com gets its data from NewYork exchange, Nasdaq, BATS exchange, etc.

I am sorry, maybe I did not state clear enough for you to understand the context. I thought everybody knows this. Encounter any problem when reading post #0042, you can still ask me to elaborate it.

Or maybe you are just a student, if you do not have time, then please give up on this. I think this mail list is for real professional to discuss tech issue to set "standard" as recommendation for the world to follow. So if you are not able to understand the issue at hand, there is no point to participate.

Though I have not seen any real professionals in this mail list.

Jack.

# Jack (Zhan, Hua Ping) (3 days ago)

sorry, It does not ask any of your personal information. I missed the "not".

Jack

# Michaela Merz (3 days ago)

Can we please stop the nonsense? There's plenty to b*tch about (did I mention indexddb ?) - but CORS is not.

Y'all have a great weekend.

m.

# Chaals McCathie Nevile (2 days ago)

On Fri, 13 Oct 2017 18:25:40 +0200, Michaela Merz

michaela.merz@rollofone.com wrote:

Can we please stop the nonsense?

"Jack" has been blocked from the list, for failing to behave appropriately.

Want more features?

Request early access to our private beta of readable email premium.