Re: [w3ctag/design-reviews] TAG review for web app `scope_extensions` (Issue #875)

So I think that the requirement needs to be that the browser needs to know whether something is in app scope *before* navigating.  Any solution that involves finding out at the time is going to introduce latency penalties that are undesirable.

For me, that rules out anything that is exclusively CORS-like.  Navigation is commonplace and adding an extra round trip to all navigations from an app isn't a great outcome, even if it is only for cross origin navigations (we don't need to add that barrier structurally, even if a lot of applications insist upon it).

However, it isn't quite that simple.  The app lists what it thinks is in scope, so the point of this design is to confirm.  We would start from an assumption that the app is making a correct representation, then confirm that with the app.  That isn't CORS-like, that's something new (-ish, the introduction of `Sec-Fetch-Dest` is somewhat of a confirmation stage, as are some of the other CORS headers that determine whether a response is readable).

So I'm of two minds here.  I hate the constant addition of stuff to HTTP requests.  It's really starting to get out of hand (especially with very long field names, the risk that requests exceed the size of a packet is real and that has serious performance implications).  But Reilly's suggestion has real merit.  I also see the advantages of following that model of confirmation.

@dmurph's concern about two fields is easy to answer, I think: the site likely needs to know who is asking before they answer.  Because the answer could depend.  Sites could have resources that are acceptably included in multiple apps.

The manifest-like approach is also reasonable.  A centralized location where you can interrogate an origin about the scopes that can extend to it is OK.  I find myself horrified at the complexity of the proposals though.  Please, if we go that way, can we focus on what is the minimum possible syntax that will achieve the desired outcome.  This works:

```json
{
   "https://example.com/this-is-an-app/": ["/payments", "/anti-fraud-stuff"],
}
```

(Yes, it is not extensible, but it is replaceable and that is enough.)

However, throwing out ideas is not what we need here.  What is needed is to ask one question: What is the form of this that site operators are best able to handle?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/875#issuecomment-2319288785
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/875/2319288785@github.com>