Closed Bug 1280626 Opened 4 years ago Closed 4 years ago
Update NPAPI to allow plugins to be container-aware
Plugins will want to know what container a piece of their content is loaded into, in order to follow this new Firefox convention. A specific example is Flash and local shared objects. Without providing them container information, their content will keep their on-disk LSOs scoped by domain/protocol etc. but will not respect our container model. Giving them access to this information should enable them to properly isolate LSOs and keep our containers separated.
If we do this, it would be Flash-only. Although the flapper work may make this irrelevant, which would probably be better.
Priority: -- → P5
I know updated versions of flash are not click to play by default. What other NPAPI plugins will load without requiring a click and accepting via the lego block doorhanger? Should we force click to play for NPAPI in containers? We could update the doorhanger in containers to say that plugins can bypass container separation. What does the flapper work refer to?
What is the NPAPI deprecation timeline?
(In reply to Tanvi Vyas[:tanvi] from comment #2) > I know updated versions of flash are not click to play by default. What > other NPAPI plugins will load without requiring a click and accepting via > the lego block doorhanger? All plugins (other than Flash) are click-to-play starting in Firefox 47 (bug 1263630). > Should we force click to play for NPAPI in containers? We could update the > doorhanger in containers to say that plugins can bypass container separation. If we expect users to use containers for everyday browsing, then making Flash click-to-play may break quite a few websites. ddurst's team is working to improve the Flash click-to-play experience, but I would not recommend making Flash click-to-play in containers yet. > What does the flapper work refer to? Flapper will give us more control of Flash sandboxing. It won't affect other plugins. (In reply to Tanvi Vyas[:tanvi] from comment #3) > What is the NPAPI deprecation timeline? We plan to drop support for NPAPI plugins (other than Flash) in Firefox 53 (the release following the next ESR, Firefox 52). There is no timeline for dropping support for Flash yet.
Thanks Chris! Sounds like we need to find a solution for flash only. Since the other NPAPI plugins are click to play now and will be deprecated soon, we won't worry about that. (In reply to Benjamin Smedberg [:bsmedberg] from comment #1) > If we do this, it would be Flash-only. Although the flapper work may make > this irrelevant, which would probably be better. How might flash sandboxing make this irrelevant? If we sandbox flash, will it no longer be able to read/write flash cookies or other data to the users computer? Are flash cookies stored by the computer or the browser? If I use both IE and Firefox on my mac, will they both access the same flash storage?
(In reply to Tanvi Vyas[:tanvi] from comment #5) > Are flash cookies stored by the computer or the browser? If I use both IE > and Firefox on my mac, will they both access the same flash storage? From what I've heard, flash cookies are shared across all browsers and all browser profiles on a computer. If this is true, then segregation of flash cookies by container is just a fraction of the bigger problem. Ben, can you confirm that the above?
I don't know the details of how/whether Flash cookies (LSOs) interact across browsers. If we're talking in terms of the NPAPI Flash, it might be possible to do something like this: * launch a separate Flash instance for plugins from each container * use our sandbox to redirect Flash LSO storage to a separate per-container directory (by intercepting the I/O) I don't know what the API surface looks like for the Mortar/PPAPI version.
(In reply to Tanvi Vyas - behind on reviews [:tanvi] from comment #6) > From what I've heard, flash cookies are shared across all browsers and all > browser profiles on a computer. If this is true, then segregation of flash > cookies by container is just a fraction of the bigger problem. https://en.wikipedia.org/wiki/Local_shared_object "By default LSO data is shared across browsers on the same machine." This is technically correct - since LSOs were created in 2000 - with the following exceptions: * Both IE and Chrome have their own LSO storage. * LSOs created during private browsing are not shared across any browser. Therefore, Firefox will share LSOs with other versions of Firefox, plus Safari on the same machine... or more specifically, user-level profile on the same machine. Also, browser profile boundaries - for Firefox at least - are not respected by the Flash LSO store. I don't know if that is because LSOs pre-date profiles, or if profile data is not part of NPAPI, or if they just never got around to supporting it. The goal of filing this bug was to create a non-zero percent chance that plugins could support this feature. If the work to enhance NPAPI for that purpose is not worthwhile, please mark this as WONTFIX and/or prioritize appropriately. Discussions about container-specific workarounds and details not pertaining to NPAPI would be better captured in new bugs.
There is no chance that we will get an NPAPI change for this use-case. I'd like to explore workarounds: for instance telling Flash loaded from a container that is is in private browsing, or using sandboxing tricks, but you can put those in a separate bug as you see fit. Or we can wait for project Mortar which will also almost certainly solve this automatically.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.