Closed Bug 1035637 Opened 10 years ago Closed 10 years ago

[EME] Ensure EME GMPs are segregated by origin and "url bar" origin

Categories

(Core :: Audio/Video, defect)

x86_64
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox37 --- fixed
firefox38 --- fixed
firefox39 --- fixed

People

(Reporter: cpearce, Assigned: cpearce)

References

(Blocks 1 open bug)

Details

bug 1024300 comment 18:

(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.
We have developed the API to get the first party URL bar origin for documents and channels (bug 962326) which might help here. The current plan is to rebase that code to ESR 31 soon and try again to get it into mozilla-central.
Henri: Do you think we should use the "third party urlbar API" patch that the Tor project guys created in bug 962326, or should we roll something else here?
Flags: needinfo?(hsivonen)
I think what we need to do here is concatenate the origin string of the document containing the MediaKeys object + origin of the "URL bar"/top level document. Then for this origin-pair we need to generate some salt and concatenate that to the origin-pair. We need to store the salt for the origin-pair, and look it up next time, so that the origin-id is consistent between sessions, unless the user clears private data.

We may need to use the hash of the origin-id we generate as the actual origin id, as if we don't it may be longer than the maximum allowable filesystem path when we include the origin in the path to GMP origin specific storage on disk.

For private browsing mode we always generate the salt, and I guess GMP storage also needs to go in a segregated storage location, so we can blow it all away when PB mode exits.

It looks like we can detect if we're in a PB window with:
  nsCOMPtr<nsILoadContext> loadContext = OwnerDoc()->GetLoadContext();
  return loadContext && loadContext->UsePrivateBrowsing();

What tool can we use to generate the salt? I see PK11_GenerateRandom() used elsewhere.

We will send this string GMP child process, which will hash it with some machine specific data in a deterministic way before clearing raw data and activating the sandbox (Bug 1060179).

Henri: how does that sound?
OS: Windows 8.1 → All
(In reply to [PTO until 15 Sep] Chris Pearce (:cpearce) from comment #2)
> Henri: Do you think we should use the "third party urlbar API" patch that
> the Tor project guys created in bug 962326, or should we roll something else
> here?

That patch assumes that you are starting with an nsIChannel. Here, you'll have an easier way to find the nsIDOMWindow of the JS context that creates MediaKeys. Once you have that, you should be able to call GetTop() to get the top-level nsIDOMWindow.

So I think it doesn't make sense to use the patch from bug 962326 here.

(In reply to [PTO until 15 Sep] Chris Pearce (:cpearce) from comment #3)
> I think what we need to do here is concatenate the origin string of the
> document containing the MediaKeys object + origin of the "URL bar"/top level
> document. Then for this origin-pair we need to generate some salt and
> concatenate that to the origin-pair.

Why would we concatenate the salt with the origin pair?

> We need to store the salt for the
> origin-pair, and look it up next time, so that the origin-id is consistent
> between sessions, unless the user clears private data.

Yes.

Where is the mapping from origin pair to the salt stored?

> We may need to use the hash of the origin-id we generate as the actual
> origin id, as if we don't it may be longer than the maximum allowable
> filesystem path when we include the origin in the path to GMP origin
> specific storage on disk.

Can't we use the salt for the paths used for GMP storage? Surely if one is worried about accidental collisions in sufficiently long CS-randomly-generated salt, one should be an epsilon *more* worried about hash collisions.

If you want to check for collisions, however improbable, you need to store the original origin pair string anyway.

> For private browsing mode we always generate the salt, and I guess GMP
> storage also needs to go in a segregated storage location, so we can blow it
> all away when PB mode exits.
> 
> It looks like we can detect if we're in a PB window with:
>   nsCOMPtr<nsILoadContext> loadContext = OwnerDoc()->GetLoadContext();
>   return loadContext && loadContext->UsePrivateBrowsing();
> 
> What tool can we use to generate the salt? I see PK11_GenerateRandom() used
> elsewhere.

nsIRandomGenerator::GenerateRandomBytes() seems to be the right thing to use within Gecko instead of calling PK11* stuff directly. (do_GetService("@mozilla.org/security/random-generator;1");)
Flags: needinfo?(hsivonen)
(In reply to Henri Sivonen (:hsivonen) from comment #4)
> If you want to check for collisions, however improbable, you need to store
> the original origin pair string anyway.

Which is a good idea anyway if we want to provide UI that enumerates items in the GMP storage and explains what origins they belong to.
Assignee: nobody → cpearce
(In reply to Henri Sivonen (:hsivonen) from comment #4)

Thanks!

> (In reply to [PTO until 15 Sep] Chris Pearce (:cpearce) from comment #2)
> So I think it doesn't make sense to use the patch from bug 962326 here.

OK.

> (In reply to [PTO until 15 Sep] Chris Pearce (:cpearce) from comment #3)
> Why would we concatenate the salt with the origin pair?

OK, we can just map origin pair to salt. Easy.

> Where is the mapping from origin pair to the salt stored?

I was thinking I would just create a directory structure on disk, something like:
$ProfileDir/gmp/Hash($UrlBarOrigin+$MediaKeysOrigin)/nodeid
$ProfileDir/gmp/Hash($UrlBarOrigin+$MediaKeysOrigin)/origins
$ProfileDir/gmp/Hash($UrlBarOrigin+$MediaKeysOrigin)/storage/

Where "nodeid" is a file containing the salt, "origins" is a file containing the origin pair, and "storage/" is where we store the GMPStorage records.

We'd want to cache the mapping in memory so that we don't need to block the main thread waiting for I/O to get the origin, and populate the cache when we load the GMPs at startup.

> Can't we use the salt for the paths used for GMP storage?

Yep.
Fixed by bug 1060179.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Mass update firefox-status to track EME uplift.
You need to log in before you can comment on or make changes to this bug.