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

RESOLVED FIXED

Status

()

Core
Audio/Video
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: cpearce, Assigned: cpearce)

Tracking

(Blocks: 2 bugs)

unspecified
x86_64
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox37 fixed, firefox38 fixed, firefox39 fixed)

Details

(Assignee)

Description

3 years ago
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.

Comment 1

3 years ago
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.
(Assignee)

Updated

3 years ago
Blocks: 1032660
(Assignee)

Comment 2

3 years ago
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)
(Assignee)

Updated

3 years ago
Blocks: 1060179
(Assignee)

Comment 3

3 years ago
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)

Updated

3 years ago
Assignee: nobody → cpearce
(Assignee)

Comment 6

3 years ago
(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.
(Assignee)

Comment 7

3 years ago
Fixed by bug 1060179.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

3 years ago
Mass update firefox-status to track EME uplift.
status-firefox37: --- → fixed
status-firefox38: --- → fixed
status-firefox39: --- → fixed
You need to log in before you can comment on or make changes to this bug.