Re: CORS

Hi Jack

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: https://developer.chrome.com/apps/xhr
Firefox:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions
Safari:
https://developer.apple.com/library/content/documentation/Tools/Conceptual/SafariExtensionGuide/ExtensionPermissions/ExtensionPermissions.html
Opera: https://dev.opera.com/extensions/match-patterns/
Edge:
https://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:

> When you said in
> #0015(
> http://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:
> http://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 https://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. http://evil.com/a.html can inject string into
> https://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 regards
> Jack (Zhan, Hua Ping詹华平)
>
>