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


From: Travis Leithead <travis.leithead@microsoft.com>
Date: Tue, 10 Oct 2017 15:33:26 +0000
To: "Jack (Zhan, Hua Ping)" <jackiszhp@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Anne van Kesteren <annevk@annevk.nl>
Message-ID: <CY4PR21MB01832EEDA9F5271790D43CA3F8750@CY4PR21MB0183.namprd21.prod.outlook.com>
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: https://evil.com/ to add <meta name="sameOrigin" content="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

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 http://1st.com/abc.html to post data to (or get data from) http://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/"/> or with an HTTP header when serving abc.html:
SameOrigin: http://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 http://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:
http://1st.com/abc.html is a consumer.
http://2nd.com/ is a producer.
http://2nd.com/somewhere is the product.

The old same origin/site policy of web browsers requires the consumer only consumes resources from http://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詹华平)
QQ: 94544458  欢迎加我,欢迎访问QQ空间
twitter: https://twitter.com/jackzhp/with_replies
腾讯微博:http://t.qq.com/jackiszhp 福建詹华平
新浪微博:http://weibo.com/u/2478246631 福建詹华平
搜狐微博:http://t.sohu.com/people?uid=354178954 詹华平
GPG/openPGP key: 1070307AE69B6BB861AF4E9FDB61E01A3DF5687D

Received on Tuesday, 10 October 2017 15:34:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:15:08 UTC