Dan: can we close it?

Alex: Can you say "please fetch, if you can do it, just do it".

Travis: We still believe there's an issue to be addressed :) So much for Tim's on Sabattical, close the issue...

Peter: Come back to it in... 2 weeks?

Travis: Where are we on this?

David: I need to talk to Yves about this.

Travis: Any other feedback on this since January 31?

David: To some extent.

Yves: I'll contact you about this.

ACTION: Revisit during F2F.

Dan: can we close it?

Yves: I'm not sure Tim would agree on closing it...

... there was a proposal on the WHATWG issue - it didn't get traction. It was closed by Anne because of lack of interest.

Amy: there is another proposal - 878 on Fetch - which is also part of this.

[discussion on issue]...

Yves: no way to figure out whether resource exists or not.. security feature hiding everything behind... needs extra context besides URL to access something.

Amy: if the server says "allow origin" - then you can't send credentials...

David: depends what the values are... Browsers can have access to stuff on another site that they can't share with the first site. Intranets and ambient authority. Access-Control-Allow-Origin: * - simple value that tells the browser it can do anything that's safe for things on the public internet... relatively safe thing for server operator to do - but then you have the problem that if you use cookies to get that resource then you can't share it with another site. So you need to tell the browser "don't send cookies to get this resource" - but some sites require a cookie to get a resource - and those need special headers to mark that these resources are safe to use...

Yves: access control allow origin * has been misleading to many developers. This is what bothers people who say it's a "free for use" resource even though it may be accessed publicly with or without cookies.

David: I think some of these use cases in 878 are suspicious. When you dig into it - you have to ask what is the data for. If Tim has access to use the data then I can write a web app that accesses the data with tim's credentials and get a copy of it. That's why I find some of these use cases suspicious.

Amy: that's the whole model of how the SOLID stuff works - the webapp doesn't care about the data but the webapp accesses the user's data with the user's credentials but in theory it's not sending it somewhere else.

David: but a browser can't trust any webapp to be acting on behalf of the user.

Amy: Maybe that's the fundamental issue that the SOLID stack is having?

Amy: the assumption with SOLID is that you are using a webapp then you trust it. edit: may be wrong about this these days, related and something about users pre-approving trusted apps

Dan: but if I follow a link it must be safe - so could be my bank or evil bank...

Amy: client-side cert is one answer.... In theory if you didn't trust that app (like if it's a phishing attempt) then you could deny access at that point.

Dan: what about the response doc we wrote?

Yves: that was the first proposal we wrote...

Dan: so out of date effectively...

Dan: If there are no open issues on this in WHATWG then maybe we should close this issue here?

Yves: pretty sure we won't make progress unless there is buy-in from vendors and if clients don't give feedback in that way there's not much we can do to fix it.

Can we make this go away? https://github.com/w3ctag/design-reviews/issues/76#issuecomment-767710822 proposed closing it 3 years ago.

Peter: we've had a proposed close on it for 3 years. I think we can close it.

Martin: I think we can just close it.

we agree to close