Re: Comment on minutes ## With Credentials flag etc

On Mon, Jan 18, 2016 at 4:36 PM, Tim Berners-Lee <timbl@w3.org> wrote:

> ## With Credentials flag
> https://github.com/w3ctag/spec-reviews/issues/76
> mnot: TimBL's issue, he discussed a bit with annevk; I discussed with
> annevk as well.
> mnot: Tim needs to justify a little more
>
>
> Sad, I wasn’t in Australia.  But I did describe it in Berlin face-face.
>
> Yves: If you can't figure out whether it's ??? then you can't figure out
> whether the server is .... then you have to link to not just URI but URI
> plus credentials.
> mnot: ... saying not consistent with Web architecture to have fetch have a
> flag (with credentials) for whether it's cross-origin; wants it to be
> calculated automatically
> Yves: ... a bit like an API
> mnot: you didn't have to do that
> mnot: so why is this architecturally bad?  Strength of URI is that stick
> URI into application.  But application does know context.  Maybe Tim
> misunderstands nature of fetch; not really and end-user-facing API.
>
>
> I do not think I misunderstand the nature of fetch().
> The nature of fetch is to look up a URI given the URI and nothing else.
> Fetch (or XHR)  is called by many many pieces of code, sometimes developer
> code, sometime library code.
> Never the user.
>
> Fetch just asks for a URI to be fetched.
> Everything is handled by the browser code, the developer goes not have to
> deal with
> - authentication — the developer does not have to give the passwords etc
> So in general the called of fetch() does NOT know whether authentication
> will be needed, and does not care.
> So the caller of fetch does not, in the general case, know whether to set
> any withCredentials flag.
>
>
> Yves: different from regular web page, running in specific .??? context
> plinss: the with credentials flag is about how the url is used
>
>
> All the information about how the URL is used is in the specs, and in the
> URL.
> That is web architecture 101.
>
> mnot: legitimate to have something about how URL is being used
>
>
> Nope, not legitimate.
> Every time someone adds something like this, like “force content-type”
> flags, it means everywhere the URI is stored throughout the system
>
> mnot: but we can't resolve this without Tim in the room
>
>
> Sad
>
>
I'm hesitant to add noise to this conversation but I'm very confused by it
and I think, from conversations, that I am not alone so I am going to
anyway...

Let's assume for a moment, just for the sake of argument, (I'm not sure if
this is what Tim is really saying or not but let's just start there) that
CORS was a very bad idea and that there is something fundamentally better
which didn't require setting this flag and therefore wouldn't be need to be
exposed via script API - it'd just "work" (I actually can't imagine how
this would be possible but very possibly I am just not being creative
enough, in any case, /me waves hand and we assume it is so for purposes
here).

Given this assumption, it seems to me that it would not change the fact
that millions of websites today function safely because of and rely on this
in the real, shipped Web of today.  It is exposed through XHR today and
necessary - I don't think you can take that 'out' without breaking
significant bits of the Web (importantly to me personally as it would break
dozens and dozens of things we've spent years getting deployed for my
employer).  The challenge, as I understand it, that Anne took up was to
explain "what's down there" underneath all that stuff, including XHR that
does all the network browser magic.  I don't think Tim disagrees that this
is a laudable goal but if so, that'd be interesting to hear and take the
conversation in a very different direction I think.

Thus - if you have to write something at the very low level that has to
respect XHR's flag, needs to provide explanation for all of the rest of it
(like the fact that some tags request things always with CORS or without)
and should (IMO at least) provide enough power that if we wanted to add a
new element like image, video or audio tomorrow it would be possible to
make that work as a custom element and demonstrate its properties... How
else could you do all those things?

I guess this is where my confusion lies.  CORS seems, for good or for bad,
to be unexplained and currently necessary magic in the platform that can't
just be removed.  As Anne said, once it's there it can be hidden it at
higher layers - you can provide better additive abstractions for future use
(all the tags do this already and it's possible that some higher level
imperative API could too if you could come up with some rationale as to
how), but it doesn't seem like there's an option to do much else regardless
of its quality?

-- 
Brian Kardell :: @briankardell