Closed Bug 1024300 Opened 10 years ago Closed 10 years ago

GMPs need to be optionally segregated by origin

Categories

(Core :: Audio/Video, defect)

29 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla33

People

(Reporter: cpearce, Assigned: cpearce)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

We need to be able to segregate GMPs from different origins. This is necessary to prevent EME plugins sharing information between domains. This should be optional; I don't think we need this for OpenH264 for example, since we can inspect its code.
bz: I'd like some guidance here... I need to hash the origin of the JS object representing the EME/CDM (dom::MediaKeys) to the plugin instance that services EME for that origin. I'm thinking that it's fine for separate webpages with the same origin to share the same plugin instance.

So is it sufficient to use the nsIPrincipal::hashValue of the MediaKeys' owner document's node principal as a hash key?
Flags: needinfo?(bzbarsky)
We also need to have a "Keysystem" record in the GMP .info file, so we can tell different EME plugins apart.
Actually we can embed the keysystem as a tag in the decode-video APIs record, e.g.:

APIs: decode-video[org.w3c.clearkey:h264:vp8], decode-audio[org.w3c.clearkey:aac:vorbis]

Then we'll need GeckoMediaPluginService::SelectPluginFromListForAPI() to be able to select plugins based on multiple tags, rather than just one.
Actually, I don't think we need a hash table...
Flags: needinfo?(bzbarsky)
Attached patch Patch v1 (obsolete) — Splinter Review
* Enable passing a codec string to mozIGeckoMediaPluginService.getGMPVideo{Decoder,Encoder}().
* Add mozIGeckoMediaPluginService.getGMPEMEVideoDecoder(), which requires a principal to be passed in, plus a keysystem.
* Make GeckoMediaPluginService::SelectPluginFromListForAPI() accept an array of tags, all of which have to be present in a candidate GMP before it's selected and returned.
* When constructing an EME capable video decoder, pass in the keysystem as a tag. So EME GMPs will have to put their keysystem string in their .info file, as in my example in comment 3.
* GMPParent now tracks the principal it's being used with, or nullptr if the plugin is to be shared across all origins (like in the OpenH264 case). We need a flag to denote that the GMP is shared to distinguish between the case where the principal is null because the GMP is shared across origins, and when it has not yet been loaded and had a principal associated with it.
Attachment #8439666 - Flags: review?(joshmoz)
(In reply to Chris Pearce (:cpearce) from comment #5)
> * GMPParent now tracks the principal it's being used with, or nullptr if the
> plugin is to be shared across all origins (like in the OpenH264 case). We
> need a flag to denote that the GMP is shared to distinguish between the case
> where the principal is null because the GMP is shared across origins, and
> when it has not yet been loaded and had a principal associated with it.

"origin" means here standard SOP, right? There was a thread on dev-privacy some weeks ago (https://groups.google.com/forum/#!topic/mozilla.dev.privacy/3jA9zt1pXVo) covering this topic. To quote the relevant part:

[quote]
> Also, what does "origin" mean in this context? Is a third party iframe
> considered to have the URL bar domain as its "origin", or is the
> "origin" here the one used by the same-origin policy (ie the iframe
> source url domain)?

To be decided.
[/quote]

So, could you please reconsider the decision that seems to have been made and take the URL bar domain as origin? That would be much more preferable form a privacy standpoint. And you don't have the "But-the-other-browser-vendors-do-it-the-same-way"-pressure this time preventing a good solution. Apart from that I don't understand the OpenH264 argumentation in the description. Being able to look at the source is orthogonal to binding things to the same domain.

And, oh, there is the code in bug 962326 which gives you the means to actually bind things to the URL bar domain.
(In reply to Georg Koppen from comment #6)

> preventing a good solution. Apart from that I don't understand the OpenH264
> argumentation in the description. Being able to look at the source is
> orthogonal to binding things to the same domain.

Process per origin can take up more resources than process per plugin, so the latter is preferable unless there are particularly strong concerns about processing data from multiple origins in the same process. What Chris is saying (and I agree) is that in the plain (non-EME) h264 case, there is little downside to encoding/decoding data from multiple origins in the same process.
Comment on attachment 8439666 [details] [diff] [review]
Patch v1

Review of attachment 8439666 [details] [diff] [review]:
-----------------------------------------------------------------

I think things are going to fail if you try to start using multiple origins because we create one GMPParent object for each plugin when scanning plugin directories, and there is a 1:1 relationship between GMPParent objects and processes. Something is going to have to create additional GMPParent objects if we want to have multiple processes per plugin. Did you only test this with a single process?

::: content/media/gmp/GMPParent.cpp
@@ +439,5 @@
> +      // principal.
> +      MOZ_ASSERT(!mIsSharedCrossOrigin);
> +      return false;
> +    }
> +    // This plugin can service any orign.

"origin"

@@ +458,5 @@
> +    // designated to serve all origins. Assign it to work with aPrincipal.
> +    return true;
> +  }
> +
> +  return false;

I didn't work out every possible code path, just looked for cases where we'd make the wrong decision, but my gut tells me the logic structure in this method could be more cleanly organized.

::: content/media/gmp/GMPParent.h
@@ +92,4 @@
>  #ifdef DEBUG
>    nsCOMPtr<nsIThread> mGMPThread;
>  #endif
> +  bool mIsSharedCrossOrigin;

Is it not enough to check mPrincipal? Is there some reason we can't assume it's a shared cross origin plugin prior to mPrincipal being set? I don't think there is any possibility of a race condition causing problems here.

::: content/media/gmp/GMPService.cpp
@@ +333,2 @@
>  {
>    MOZ_ASSERT(NS_GetCurrentThread() == mGMPThread);

We might also want to assert that there is at least one tag. It's theoretically possible that we could have an API that didn't need any tags to make sense, but practically speaking it's probably a mistake if there are no tags, and we might as well help catch it.

::: content/media/gmp/mozIGeckoMediaPluginService.idl
@@ +37,5 @@
> +  // content, with a specified codec and EME keysystem.
> +  // Callable only on GMP thread.
> +  GMPVideoDecoder getGMPEMEVideoDecoder(in nsIPrincipal principal,
> +                                        in ACString codec,
> +                                        in ACString keySystem,

We're eventually definitely going to have to support more tags. e.g. Right now we can just say h264 or vp8 but then it's going to be h264 baseline vs. high profile... Lets just take care of this API issue now to avoid churn. It shouldn't change your patch very much - in fact it might reduce code.

How about we just have a method for each API (getGMPVideoDecoder and getGMPVideoEncoder), not an additional EME version, and each API can take a list of tags. Then callers specify a codec at a minimum, plus whatever else they want (EME, a profile, whatever).

Breaking out all of the possible tags into arguments in these interfaces is going to get painful, and we're not even getting the benefit of helping people avoid mistakes with literal strings in doing so.

@@ +39,5 @@
> +  GMPVideoDecoder getGMPEMEVideoDecoder(in nsIPrincipal principal,
> +                                        in ACString codec,
> +                                        in ACString keySystem,
> +                                        out GMPVideoHost outVideoHost);
> +  

Extra spaces/newline here.
Attachment #8439666 - Flags: review?(joshmoz)
(In reply to Georg Koppen from comment #6)
> (In reply to Chris Pearce (:cpearce) from comment #5)
> > * GMPParent now tracks the principal it's being used with, or nullptr if the
> > plugin is to be shared across all origins (like in the OpenH264 case). We
> > need a flag to denote that the GMP is shared to distinguish between the case
> > where the principal is null because the GMP is shared across origins, and
> > when it has not yet been loaded and had a principal associated with it.
> 
> "origin" means here standard SOP, right? There was a thread on dev-privacy
> some weeks ago
> (https://groups.google.com/forum/#!topic/mozilla.dev.privacy/3jA9zt1pXVo)
> covering this topic. To quote the relevant part:
> 
> [quote]
> > Also, what does "origin" mean in this context? Is a third party iframe
> > considered to have the URL bar domain as its "origin", or is the
> > "origin" here the one used by the same-origin policy (ie the iframe
> > source url domain)?
> 
> To be decided.
> [/quote]
> 
> So, could you please reconsider the decision that seems to have been made
> and take the URL bar domain as origin? That would be much more preferable
> form a privacy standpoint. 

Can you please explain why it is superior to have the URL bar domain
be the origin rather than the iframe? It seems like it's inferior from
a security perspective.



> And you don't have the
> "But-the-other-browser-vendors-do-it-the-same-way"-pressure this time
> preventing a good solution. Apart from that I don't understand the OpenH264
> argumentation in the description. Being able to look at the source is
> orthogonal to binding things to the same domain.
> 
> And, oh, there is the code in bug 962326 which gives you the means to
> actually bind things to the URL bar domain.
(In reply to Josh Aas (Mozilla Corporation) from comment #8)
> Comment on attachment 8439666 [details] [diff] [review]
> Patch v1
> 
> Review of attachment 8439666 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I think things are going to fail if you try to start using multiple origins
> because we create one GMPParent object for each plugin when scanning plugin
> directories, and there is a 1:1 relationship between GMPParent objects and
> processes. Something is going to have to create additional GMPParent objects
> if we want to have multiple processes per plugin. Did you only test this
> with a single process?


My reading of GeckoMediaPluginService::SelectPluginForAPI() was that if we didn't find a matching plugin on the first pass, RefreshPluginList() would blow away all the unloaded plugins, rescan the plugin dirs and append *every* possible plugin again into mPlugins. So we could end up with multiple GMPParent instances for the same plugin type. I didn't see any code to enforce that a plugin can only be instantiated once. Did I miss it?

I will test the multiple subprocess case today, I haven't actually hooked up the principal info in my GMP client code yet, I was just passing in the system principal to test this.


> ::: content/media/gmp/GMPParent.h
> @@ +92,4 @@
> >  #ifdef DEBUG
> >    nsCOMPtr<nsIThread> mGMPThread;
> >  #endif
> > +  bool mIsSharedCrossOrigin;
> 
> Is it not enough to check mPrincipal? Is there some reason we can't assume
> it's a shared cross origin plugin prior to mPrincipal being set? I don't
> think there is any possibility of a race condition causing problems here.

There's no race, but the problem here is we can't use mPrincipal==nullptr to mean we're shared and also mean we're not shared and not initialized... but I guess we can use (mPrincipal==nullptr && State() == GMPStateLoaded) to track that a plugin is being used shared. So yeah, mIsSharedCrossOrigin can probably go away.



> 
> ::: content/media/gmp/GMPService.cpp
> @@ +333,2 @@
> >  {
> >    MOZ_ASSERT(NS_GetCurrentThread() == mGMPThread);
> 
> We might also want to assert that there is at least one tag.

OK.


> ::: content/media/gmp/mozIGeckoMediaPluginService.idl
> @@ +37,5 @@
> > +  // content, with a specified codec and EME keysystem.
> > +  // Callable only on GMP thread.
> > +  GMPVideoDecoder getGMPEMEVideoDecoder(in nsIPrincipal principal,
> > +                                        in ACString codec,
> > +                                        in ACString keySystem,
> 
> We're eventually definitely going to have to support more tags. e.g. Right
> now we can just say h264 or vp8 but then it's going to be h264 baseline vs.
> high profile... Lets just take care of this API issue now to avoid churn. It
> shouldn't change your patch very much - in fact it might reduce code.
> 
> How about we just have a method for each API (getGMPVideoDecoder and
> getGMPVideoEncoder), not an additional EME version, and each API can take a
> list of tags. Then callers specify a codec at a minimum, plus whatever else
> they want (EME, a profile, whatever).

So, something like:

  [ptr] native TagArray(nsTArray<nsString>);

  GMPVideoDecoder getGMPVideoDecoder(in TagArray tags,
                                     [optional] in nsIPrincipal principal);

> Breaking out all of the possible tags into arguments in these interfaces is
> going to get painful, and we're not even getting the benefit of helping
> people avoid mistakes with literal strings in doing so.

We could:
1. allow regular expressions in the tags parser, or
2. write a tool that generates the list of tags for H.264/avc and AAC which plugin writers can use.

I suspect 2 is more reliable, and it can just be a JS web page.
Comment on attachment 8439666 [details] [diff] [review]
Patch v1

Review of attachment 8439666 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/media/gmp/GMPParent.cpp
@@ +470,5 @@
> +    MOZ_ASSERT(!mPrincipal);
> +  } else {
> +    MOZ_ASSERT(!mPrincipal || mPrincipal->Equals(aPrincipal));
> +    MOZ_ASSERT(!mIsSharedCrossOrigin);
> +    mPrincipal = aPrincipal;

Oops, this isn't safe; this will AddRef the principal on a non-main thread, and nsBasePrincipal's refcount is not threadsafe. We'll have to extract the origin string from the principal on the main thread and send that through instead.
(In reply to Chris Pearce (:cpearce) from comment #10)
> > I think things are going to fail if you try to start using multiple origins
> > because we create one GMPParent object for each plugin when scanning plugin
> > directories, and there is a 1:1 relationship between GMPParent objects and
> > processes. Something is going to have to create additional GMPParent objects
> > if we want to have multiple processes per plugin. Did you only test this
> > with a single process?
> 
> 
> My reading of GeckoMediaPluginService::SelectPluginForAPI() was that if we
> didn't find a matching plugin on the first pass, RefreshPluginList() would
> blow away all the unloaded plugins, rescan the plugin dirs and append
> *every* possible plugin again into mPlugins. So we could end up with
> multiple GMPParent instances for the same plugin type. I didn't see any code
> to enforce that a plugin can only be instantiated once. Did I miss it?

Ha, if that works it wasn't intentional on my part, it would just be a lucky side effect of how I wrote the code. We should be careful to audit around this because I wrote the code with the assumption in my mind that we'd only create one GMPParent per plugin on disk. I knew we might want to have multiple in the future, but I wasn't coding for that case initially.

> > Is it not enough to check mPrincipal? Is there some reason we can't assume
> > it's a shared cross origin plugin prior to mPrincipal being set? I don't
> > think there is any possibility of a race condition causing problems here.
> 
> There's no race, but the problem here is we can't use mPrincipal==nullptr to
> mean we're shared and also mean we're not shared and not initialized... but
> I guess we can use (mPrincipal==nullptr && State() == GMPStateLoaded) to
> track that a plugin is being used shared. So yeah, mIsSharedCrossOrigin can
> probably go away.

If the variable makes things significantly more clear then let's not remove it just to save a bool in a low-count object, but does it ever really matter in any of the code you wrote whether we're shared or simply uninitialized? I didn't look that hard for cases where it does, it may well matter, but I didn't notice anything where it would.

> So, something like:
> 
>   [ptr] native TagArray(nsTArray<nsString>);
> 
>   GMPVideoDecoder getGMPVideoDecoder(in TagArray tags,
>                                      [optional] in nsIPrincipal principal);

Yeah, though also with the out host.

> We could:
> 1. allow regular expressions in the tags parser, or
> 2. write a tool that generates the list of tags for H.264/avc and AAC which
> plugin writers can use.
> 
> I suspect 2 is more reliable, and it can just be a JS web page.

I'm not sure we really need to solve this problem, just noting that we weren't solving it despite doing more work in your initial API proposal. If we do want to solve it then I agree, #2 is better.
(In reply to Josh Aas (Mozilla Corporation) from comment #12)
> If the variable makes things significantly more clear then let's not remove
> it just to save a bool in a low-count object, but does it ever really matter
> in any of the code you wrote whether we're shared or simply uninitialized?

Yes. We use (mPrincipal == nullptr && mIsSharedCrossOrigin) to also denote that a GMPParent is shared across origins, and (mPrincipal == nullptr && !mIsSharedCrossOrigin) to also denote that a GMPParent is not yet initialized with an origin, so could be used for either shared or non shared decoding. Without this extra bit we can't distinguish these cases.

So in the event that we're using a GMP to decode video, we'll create a GMPParent and set it's mPrincipal to nullptr and if we then initiate EME decoding on the same plugin/tags we'll look through the plugin list, find a plugin (with mPrincipal == nullptr), and then assign it to the origin, even though it's already being used in shared mode on possibly some other origin.
(In reply to Eric Rescorla (:ekr) from comment #9)
> (In reply to Georg Koppen from comment #6)
> > (In reply to Chris Pearce (:cpearce) from comment #5)
> > > * GMPParent now tracks the principal it's being used with, or nullptr if the
> > > plugin is to be shared across all origins (like in the OpenH264 case). We
> > > need a flag to denote that the GMP is shared to distinguish between the case
> > > where the principal is null because the GMP is shared across origins, and
> > > when it has not yet been loaded and had a principal associated with it.
> > 
> > "origin" means here standard SOP, right? There was a thread on dev-privacy
> > some weeks ago
> > (https://groups.google.com/forum/#!topic/mozilla.dev.privacy/3jA9zt1pXVo)
> > covering this topic. To quote the relevant part:
> > 
> > [quote]
> > > Also, what does "origin" mean in this context? Is a third party iframe
> > > considered to have the URL bar domain as its "origin", or is the
> > > "origin" here the one used by the same-origin policy (ie the iframe
> > > source url domain)?
> > 
> > To be decided.
> > [/quote]
> > 
> > So, could you please reconsider the decision that seems to have been made
> > and take the URL bar domain as origin? That would be much more preferable
> > form a privacy standpoint. 
> 
> Can you please explain why it is superior to have the URL bar domain
> be the origin rather than the iframe?

See https://www.torproject.org/projects/torbrowser/design/#privacy for the idea and the whole design document for the broader argumentation. In short: binding resources/identifiers to the URL bar domain (as well) prevents cross-origin tracking.

> It seems like it's inferior from a security perspective.

Not sure what you have in mind here but if you have concerns wrt to EME the thread I linked to in comment 6 is a fine place to articulate them, I guess. If they are broader then I am happy to here them, too.
(In reply to Georg Koppen from comment #14)
> (In reply to Eric Rescorla (:ekr) from comment #9)
> > (In reply to Georg Koppen from comment #6)
> > > (In reply to Chris Pearce (:cpearce) from comment #5)
> > > > * GMPParent now tracks the principal it's being used with, or nullptr if the
> > > > plugin is to be shared across all origins (like in the OpenH264 case). We
> > > > need a flag to denote that the GMP is shared to distinguish between the case
> > > > where the principal is null because the GMP is shared across origins, and
> > > > when it has not yet been loaded and had a principal associated with it.
> > > 
> > > "origin" means here standard SOP, right? There was a thread on dev-privacy
> > > some weeks ago
> > > (https://groups.google.com/forum/#!topic/mozilla.dev.privacy/3jA9zt1pXVo)
> > > covering this topic. To quote the relevant part:
> > > 
> > > [quote]
> > > > Also, what does "origin" mean in this context? Is a third party iframe
> > > > considered to have the URL bar domain as its "origin", or is the
> > > > "origin" here the one used by the same-origin policy (ie the iframe
> > > > source url domain)?
> > > 
> > > To be decided.
> > > [/quote]
> > > 
> > > So, could you please reconsider the decision that seems to have been made
> > > and take the URL bar domain as origin? That would be much more preferable
> > > form a privacy standpoint. 
> > 
> > Can you please explain why it is superior to have the URL bar domain
> > be the origin rather than the iframe?
> 
> See https://www.torproject.org/projects/torbrowser/design/#privacy for the
> idea and the whole design document for the broader argumentation. In short:
> binding resources/identifiers to the URL bar domain (as well) prevents
> cross-origin tracking.

OK. Given the current state of fingerprinting, this seems like a fairly
second-order concern. I wouldn't object to giving you a setting which
would allow you to have a distinct process for each URL bar/hosting
domain pair, however.


> > It seems like it's inferior from a security perspective.
> 
> Not sure what you have in mind here but if you have concerns wrt to EME the
> thread I linked to in comment 6 is a fine place to articulate them, I guess.
> If they are broader then I am happy to here them, too.

It's not particularly complicated: consider the impact of a remote code
execution vulnerability in the codec module. If all codec modules for
a given top-level origin are hosted in the same process, then an attacker
who has an iframe on a calling site and knows of such a vulnerability
can monitory all calls going through that site. However, if modules are
segregated by origin, then they cannot.
Attached patch Patch v2Splinter Review
Changes from previous patch:
* Pass in an origin string instead of an nsIPrincipal, since we can't addref/release the nsIPrincipal off main thread.
* Pass in an array of tags tos GetGMPVideo{En,De}coder(), instead of having an explicit GetGMPEMEVideoDecoder.
* I tried to make the logic around specifying plugins shared/origin specific easier to follow. I removed the GMPParent::mIsSharedAcrossOrigins field, and have an accessor to determine this, and added more comments.
Attachment #8439666 - Attachment is obsolete: true
Attachment #8441145 - Flags: review?(joshmoz)
(In reply to Eric Rescorla (:ekr) from comment #15)
> (In reply to Georg Koppen from comment #14)
> > (In reply to Eric Rescorla (:ekr) from comment #9)
> > > (In reply to Georg Koppen from comment #6)
> > > > (In reply to Chris Pearce (:cpearce) from comment #5)
> > > > > * GMPParent now tracks the principal it's being used with, or nullptr if the
> > > > > plugin is to be shared across all origins (like in the OpenH264 case). We
> > > > > need a flag to denote that the GMP is shared to distinguish between the case
> > > > > where the principal is null because the GMP is shared across origins, and
> > > > > when it has not yet been loaded and had a principal associated with it.
> > > > 
> > > > "origin" means here standard SOP, right? There was a thread on dev-privacy
> > > > some weeks ago
> > > > (https://groups.google.com/forum/#!topic/mozilla.dev.privacy/3jA9zt1pXVo)
> > > > covering this topic. To quote the relevant part:
> > > > 
> > > > [quote]
> > > > > Also, what does "origin" mean in this context? Is a third party iframe
> > > > > considered to have the URL bar domain as its "origin", or is the
> > > > > "origin" here the one used by the same-origin policy (ie the iframe
> > > > > source url domain)?
> > > > 
> > > > To be decided.
> > > > [/quote]
> > > > 
> > > > So, could you please reconsider the decision that seems to have been made
> > > > and take the URL bar domain as origin? That would be much more preferable
> > > > form a privacy standpoint. 
> > > 
> > > Can you please explain why it is superior to have the URL bar domain
> > > be the origin rather than the iframe?
> > 
> > See https://www.torproject.org/projects/torbrowser/design/#privacy for the
> > idea and the whole design document for the broader argumentation. In short:
> > binding resources/identifiers to the URL bar domain (as well) prevents
> > cross-origin tracking.
> 
> OK. Given the current state of fingerprinting, this seems like a fairly
> second-order concern. I wouldn't object to giving you a setting which
> would allow you to have a distinct process for each URL bar/hosting
> domain pair, however.

Great!
FWIW, I think we should do the partitioning by the combination of the origin calling EME and the URL bar origin, unless we are faced with a specific pressing reason to partition only by the origin calling EME.

This won't matter to movie streaming sites either way, because they generally don't allow third parties to embed them anyway.
Comment on attachment 8441145 [details] [diff] [review]
Patch v2

Review of attachment 8441145 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/media/gmp/GMPService.cpp
@@ +254,5 @@
>    if (NS_FAILED(rv)) {
>      return rv;
>    }
> +  if (!aOrigin.IsEmpty()) {
> +    gmp->SetOrigin(aOrigin);

Is this call, and the decoder equivalent, duplicate given the SetOrigin call in SelectPluginFromListForAPI?
Attachment #8441145 - Flags: review?(joshmoz) → review+
I removed the SetOrigin() call in SelectPluginFromListForAPI(), as so that the state changes (origin assignment) happen once we've successfully retrieved the decoder we want.
(In reply to Chris Pearce (:cpearce) from comment #20)
> I removed the SetOrigin() call in SelectPluginFromListForAPI(), as so that
> the state changes (origin assignment) happen once we've successfully
> retrieved the decoder we want.

Sorry, I *meant* to remove the duplicate call in SelectPluginFromListForAPI(), but didn't. I will remove it before landing.
Ur, actually, that won't work, as the call sites in GetGMP.*coder() will have already loaded the plugin by the time they try to set the origin, so they their assertions will fail. We'll have to stick with the SetOrigin() call in SelectPluginFromListForAPI(), and not in GetGMP.*coder().
Fixed the build and landed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e453f32c9c75

Just needed a few extra headers #included. Thank you, Unified Builds.
https://hg.mozilla.org/mozilla-central/rev/e453f32c9c75
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
(In reply to Henri Sivonen (:hsivonen) from comment #18)
> FWIW, I think we should do the partitioning by the combination of the origin
> calling EME and the URL bar origin, unless we are faced with a specific
> pressing reason to partition only by the origin calling EME.

Looking at the result of this bug this seems to be for another bug. How are the plans in this regard? Is there at least already filed a new bug I am not aware of?
I filed bug 1035637 and CC'd you. The work may not happen in that bug, but you can track it from that bug.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: