Re: Comment on minutes ## With Credentials flag etc

On Thursday 2016-03-31 16:51 +0100, Tim Berners-Lee wrote:
> Q: Why was reflecting the incoming origin in the header the thing which was picked
> as the way of saying “yes this really is public”?  Why not “access-control-allow-origin **” or something
>  It is a pain to code, needs two or three lines of not-newbie-obvious .htaccess in Apache, etc. 
> Result? the recipe for fixing it is sent around to do the origin reflection, and new server code does it by default for everything.
> Because CORS is such a pain for developers to deal with on the client side, with no error codes, etc
> that servers who want stuff to just work, and slap in the strongest CORS medicine they find on the net.

One important point here that I failed to realize during the meeting
is that origin reflection is required only in a particularly unusual
case:  for a resource that both:

 (a) requires credentials (e.g., cookies, HTTP auth) to access

 (b) is public.

I think this case ought to be unusual since public resources
generally shouldn't require credentials to access.

A far easier solution for the server administrator in this case
should be allowing access to the resource without credentials.
(This is what doing origin reflection would do anyway, through
browser-based attacks on the people who do have credentials.)

> I think the top three issues the TAG had were basically
> 
> a) Having the withCredentials flag as a parameter to fetch() is broken.  In general the middleware which calls fetch() will not have magic application-level knowledge of which resources it is going to fetch are public, which are private.   So a general the fetch has to work without that hint, and do the right thing. (opinions vary here)

I disagree (as I said), since I think the two options the flag has
today should exist.  They represent behaviors that exist in the Web
platform and that ought to be exposed.  That doesn't necessarily
mean that there shouldn't be other options if such options are also
needed.

> b) For a webapp which needs to load stuff from the net, the lack of clear error conditions makes it hard to understand what is going on.

I agree this is a problem.

(There may be security risk in reporting particular error details to
the calling script, although I don't know if that's the case here.
But even if it is, it should be possible to report clear errors to
the console.)

> c) Asking server writers to do the origin reflection thing is unreasonable

Given my comments above (unless I'm mistaken), I think I now
disagree with this point as well.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)