Comment on minutes ## With Credentials flag etc

> ## With Credentials flag
> https://github.com/w3ctag/spec-reviews/issues/76 <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

> Yves: .... is it to hide the fact that it's security through obscurity?
> alex: ???
> Yves: would it be possibe to have 2 different kinds of errors:  unknown not-transport-level error, vs. could reach server
> Travis: sounds like layering violation
> alex: if I'm trying to provide a UI, I'd like to say what might be going wrong
> travis: at that level, you know what you need
> alex: I mean Web site ui, not browser ui.
> Yves: Is it good to have didnt-reach-server vs. didnt-get-what-wanted exception?
> alex: to be clear, we're talking about special case of cross-origin non-CORS requests
> travis: Tim would say that with-credentials part not included ...
> Yves: If not able to figure out whether real network error, then libraries would ... having proper error miht avoid leaking that information
> travis: scenario is I request resource and get denied -- then maybe I need to do a CORS request?
> Yves: You don't need to know if it was denied or not found -- just reach server and there was an error.

If you hide from the script what is going on

- You prevent fishing I suppose

but

- you make it really hard for people to get systems working, with the user just hanging typically when th script sees readyState = 4 and  a status of zero which is not in the spec

- -you make it impossible for the script writer to tell the user what is going on, “Your data source needs to upgrade their apache CORS module to version 87"

> Yves: You have a core interaction that failed -- at fetch level coul djust report that getting what you wanted failed
> mnot: would anything but CORS produce this kind of error?
> Yves: you don't need to know if it's a CORS error to hide the fact that it was really denied,   Goal of fetch is to hide that info; everything is a network error.

“Network error” - like a TCP timeout of an ethernet interface turned off?
I imagine that a malware script could tell the difference between these, just hard for the user or a safe app to.
Fetch should be able to return nested errors like

HTTP Error: TCP error opening TCP connection:
 TCP Error: could not start new connection because of;
  Ethernet problem: you have no  ethernet interfaces powered up

Really important to distinguish for example between the DNS knowing the name you asked for is not in it, and the DNS not being reachable.

> alex: XHR has same behavior.  Scenario:  trying to cross-origin request, with with-credentials flag.  Even if sets allow-access...: *, still won't get response or know what happened.

Yes - I get these problems with XHR

> travis: not what I understood
> alex: that's what Tim says in the issue
> mnot: I wonder if tim knows it's not an end-user-facing flag

Clearly.
The problem is there is no party is happy to faced by that flag.

> alex: it's exposed through XHR and fetch
> alex: that's how this came up.
> travis: XHR was not a networking-level problem, ... application layer policy that said you're only allowed to talk to your origin
> travis: so application layer created other thing that says unless you provide exception and handshake and right headers...
> alex: a couple oddities here.  Starts at which requests get CORS and which don't.
> alex: some implicitly or explicitly invoke CORS, some don't.  It's defined, but may not be reasonable if you're trying to programmatically access things.
> alex: I think issues bottoms out at:  some requests can be made to use CORS, some use by default, some can't be made to use CORS, even if you want them to.  And that is probably the original sin here, but it's fallen off the stack for me which is which.

Are you saying the CORS design is really a kludge of rather arbitrary decisions, rather than a system with well-defined goals and properties?

> travis: example of something that needs CORS and will implicitly have CORS enabled is module loading.
> Alex: fonts always use CORS
> alex: images never use CORS
> travis: script is configurable
> alex: how?
> travis: user can supply the attribute that says to use CORS?  Or maybe not?  Maybe only DOM and not markup.
> alex: crossorigin attribute
> alex: do images have crossorigin attribute?

So what information is used to set that attribute?
What does the coder of it have to know that the script and the browser code do not know?

> travis: link, script, media, import
> plinss: crossorigin images and tainted canvases
> alex: possible to invoke for images
> alex: always for fonts, possible to invoke for script
> travis: sounds like we're retrofitting most things that use resources to have the option of using CORS

Maybe we should use a new URI scheme. <- reductio ad absurdum
So this information can be held in bookmarks and caches and histories etc etc

> alex: can't tell from issue whether CORS values Access-control-allow-credentials vs. access-control-allow-origin are part of the debate
> alex: would love to see network trace and code snippet that's not working for tim
> mnot: as I understand it, he just doesn't want to have to send the with-credentials flag when he'se requesting data from a different site
> mnot: I think he wants to not have to know.

yes.

> alex: I think what's going on here -- if he sets credentials for every request, some will be automatically denied -- don't recall which is which.
> alex: maybe we should ask annevk
> plinss: get tim and anne on a call at the same time??
> alex: would be nice to have an enumeration somelpace of the states, and odd to me that this fetch spec doesn't have anything like that

A flow chart would be peachy, or a machine-readable

> mnot: spaghetti

In that case, maybe the whole things needs to be rethought from scratch.

> travis: cross-origin for anchors?
> mnot: we need a fetch explainer doc
> alex: I don't think it exists.
> mnot: I've thought about it, but worry it'll change on me.
> dbaron: what does crossorigin on script do
> travis: lets you get script error messages