Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Put policies in the blob URL store #142

Open
annevk opened this issue Sep 23, 2019 · 4 comments
Open

Put policies in the blob URL store #142

annevk opened this issue Sep 23, 2019 · 4 comments
Labels
TPAC2024 Topic for discussion at TPAC 2024

Comments

@annevk
Copy link
Member

annevk commented Sep 23, 2019

It would be ideal that when URL.createObjectURL() is invoked all policies (CSP, referrer policy, etc.) are cloned and stored in the blob URL store so that they can be used when the blob URL is used to create a document.

This might have to be somewhat hand-wavy initially, but can hopefully be formalized over time as we document how to create, store, and inherit policies.

(In particular this approach helps ensure that however the user decides to open the blob URL, relevant policies will be there and there's not some escalation of privilege possible relative to the document that minted the URL.)

cc @mikewest @hiroshige-g

@mikewest
Copy link
Member

I like it, but I'm completely disconnected from the implementation details. :) @mkruisselbrink and @inexorabletash will know who might have (hopefully positive!) opinions about this in Chromium.

@mikewest
Copy link
Member

mikewest commented Mar 11, 2020

This (and whatwg/html#4926) cropped up again in an conversation around some things that Google Docs/Drive wants to do with blobs; tl;dr: Google's security team is unhappy with blobs as they exist today, and is uncomfortable approving blob-based flows for dynamically generated content. They'd be much happier if either: a) Blobs inherited the security policies associated with the context that created them, and/or b) Blobs could be constructed in a way that didn't inherit the origin of its creator (a la #74 (comment)).

I haven't had time to look into this set of work since TPAC. I'm hoping we can find time in Q2. Is that something Mozilla folks would be interested in collaborating on, Anne?

@koto
Copy link
Member

koto commented Mar 11, 2020

For our use cases I think b) is a more useful primitive than a), but we should have both. a) seems like a bugfix, but b) allows you to isolate user-generated content from the application code more easily. The use cases are usually generating user content for previewing in iframe, downloading or printing.

@annevk
Copy link
Member Author

annevk commented Mar 11, 2020

Yes, though I'd be primarily interested in addressing a) as adding more primitives to rather shaky foundations doesn't inspire confidence. (#135 is another problematic bit with fetching blobs.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TPAC2024 Topic for discussion at TPAC 2024
Projects
None yet
Development

No branches or pull requests

4 participants