Re: CORS

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.

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

> #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 http://evil.com/a.html
> to access https://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 http://evil.com/a.html.
> #3. As I know there is no browser prevents a.html to load
> https://bankA.com/somejavascriptcode.
> #4. In this example, what we care is the security of a.html not the bank.
>
>
> Jack
>