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

> I worry about using a "bag of parameters" here as it can lead to complications if more options are added & trying to figure out how they might combine.

That's easy.  They all apply.  If you have `{ origin: "https://example.com", site: "example.co.uk" }`, then it doesn't match.  But it leaves you the option of saying `{ origin: "https://example.com", scope: "/payments" }` or similar.

> this has definitely not been a request from partners

Your partners are not the only stakeholders here.  Or maybe they didn't think that this was a problem for them.

The concern here is that a manifest on a different site could cause content from a completely different site to be included in that app.  If a service accepts being part of an app, it loses granular control over which resources are included in that way.  Think about `X-Frame-Options` or CSP's `frame-ancestors` rules.  These can prevent content from being included as part of someone else's site in frames.  Those can be specified on a per-resource basis, so that you can protect specific resources as necessary.  Here, the choice is origin-wide, removing that option.  I have no doubt that providing a unique origin for each partner is an option that some services will choose to exercise, but forcing that choice seems unnecessary when the fix is so trivial.

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

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