1057100 - GMP storage must respect private browsing mode

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

GMPStorage implementation added in bug 1034368 does respect private browsing mode. It needs to.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

It looks like we can detect if we're in a PB window with:

  nsCOMPtr<nsILoadContext> loadContext = OwnerDoc()->GetLoadContext();
  return loadContext && loadContext->UsePrivateBrowsing();

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

Ehsan: We provide an API for EME plugins (called GMPs; Gecko Media Plugins) to store stuff on disk. Implementation is in content/media/gmp/. What do I need to do to make GMP storage respect Private Browsing mode?

I can detect PB mode with nsILoadContext::UsePrivateBrowsing() mode? How do I detect when I must purge PB mode data? Is that all that's required? Thanks!

Comment 3

[(no longer active)]

(In reply to Chris Pearce (:cpearce) from comment #2)
> Ehsan: We provide an API for EME plugins (called GMPs; Gecko Media Plugins)
> to store stuff on disk. Implementation is in content/media/gmp/. What do I
> need to do to make GMP storage respect Private Browsing mode?

What kind of data is the stuff that we write to the disk?  Does the data include information about the websites that the user has visited?

> I can detect PB mode with nsILoadContext::UsePrivateBrowsing() mode?

Yep.

> How do I detect when I must purge PB mode data? Is that all that's required? Thanks!

We usually try to decide not to write the privacy sensitive data to the disk in the first place to avoid being unable to cleanup if we crash, etc.  For example, we may want to keep this data in memory if the request is coming from a page in PB mode.  But it's hard to say exactly what the right solution is without knowing more about the data in question.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #3)
> What kind of data is the stuff that we write to the disk?  Does the data
> include information about the websites that the user has visited?

License info, and individualization info. We partition plugin instances and storage by the ("url bar origin", <video> origin) pair. We generate a random number to use as this "node id". We store the node id, so that subsequent EME sessions using the same on the ("url bar origin", <video> origin) pair will have the same node id, but when the user clears private data the "node id" and storage will be cleared too. So the node id will have to be re-generated next after private data is cleared.

In terms of what's being stored, on first startup on a new node id, the EME plugin will have to phone home to receive an "Individualization Black Box" from the license server which is some sort of token to authenticate that the EME plugin is authorized to receive licenses from that server. That needs to be stored. Also when the EME Plugin negotiates licenses it may receive a "persistent" license, which is valid across multiple sessions, so the EME Plugin needs a way to store that. The EME Plugin may also have other bookkeeping info to store.

We don't anticipate that EME plugins will need to store a lot of data.

We mitigate the chance of EME Plugins being used for user tracking by exposing a different node id to each (url-bar origin, <video> origin) pair, and by making storage for one node-id not accessible to other node-ids.

Make sense?

> > How do I detect when I must purge PB mode data? Is that all that's required? Thanks!
> 
> We usually try to decide not to write the privacy sensitive data to the disk
> in the first place to avoid being unable to cleanup if we crash, etc.

Doing that seems like a good idea here to me.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

Note the "node id" is exposed to the EME Plugin, as well as being used in the Gecko process(es) to distinguish origin pairs.

Comment 6

[(no longer active)]

(In reply to Chris Pearce (:cpearce) from comment #4)
> (In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from
> comment #3)
> > What kind of data is the stuff that we write to the disk?  Does the data
> > include information about the websites that the user has visited?
> 
> License info, and individualization info. We partition plugin instances and
> storage by the ("url bar origin", <video> origin) pair. We generate a random
> number to use as this "node id". We store the node id, so that subsequent
> EME sessions using the same on the ("url bar origin", <video> origin) pair
> will have the same node id, but when the user clears private data the "node
> id" and storage will be cleared too. So the node id will have to be
> re-generated next after private data is cleared.

I think for PB, we can store the ("urlbar origin", "video origin") pair in memory, and clean up the memory storage when we receive a "last-pb-context-exited" notification, which is dispatched when the user closes their last PB window.  This means that if you load the EME webpage in PB mode, close the window (and other open PB windows) and reload the site in a new window (PB or not), the EME plugin will get a new node ID (is that OK?)

> In terms of what's being stored, on first startup on a new node id, the EME
> plugin will have to phone home to receive an "Individualization Black Box"
> from the license server which is some sort of token to authenticate that the
> EME plugin is authorized to receive licenses from that server. That needs to
> be stored. Also when the EME Plugin negotiates licenses it may receive a
> "persistent" license, which is valid across multiple sessions, so the EME
> Plugin needs a way to store that. The EME Plugin may also have other
> bookkeeping info to store.

Is either the video origin or the urlbar origin identifiable from the individualization black box token that the EME plugin needs to store?

> We don't anticipate that EME plugins will need to store a lot of data.

FWIW, the amount of data doesn't matter much.

> We mitigate the chance of EME Plugins being used for user tracking by
> exposing a different node id to each (url-bar origin, <video> origin) pair,
> and by making storage for one node-id not accessible to other node-ids.

Sounds good.  But PB doesn't attempt to solve the network privacy problem.  The only issue we try to protect against is persisting data that can reveal the websites that the user has browsed locally.  I think if the answer to my question about the individualization black box token is no, then we have a solution!

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #6)
> (In reply to Chris Pearce (:cpearce) from comment #4)
> > (In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from
> > comment #3)

> I think for PB, we can store the ("urlbar origin", "video origin") pair in
> memory, and clean up the memory storage when we receive a
> "last-pb-context-exited" notification, which is dispatched when the user
> closes their last PB window.  This means that if you load the EME webpage in
> PB mode, close the window (and other open PB windows) and reload the site in
> a new window (PB or not), the EME plugin will get a new node ID (is that OK?)

Cool, this was what I suspected. Thanks!


> Is either the video origin or the urlbar origin identifiable from the
> individualization black box token that the EME plugin needs to store?

The indiv token is to enable the DRM license server to distinguish between multiple clients running decryption concurrently.

So it should not include data that identifies the origin-pair, but its typically encrypted, so we can't verify that.

But, we will delete the indiv token (and all other EME plugin storage) once PB mode exits, so I think we should be OK regardless.

Comment 8

[(no longer active)]

(In reply to Chris Pearce (:cpearce) from comment #7)
> > Is either the video origin or the urlbar origin identifiable from the
> > individualization black box token that the EME plugin needs to store?
> 
> The indiv token is to enable the DRM license server to distinguish between
> multiple clients running decryption concurrently.
> 
> So it should not include data that identifies the origin-pair, but its
> typically encrypted, so we can't verify that.
> 
> But, we will delete the indiv token (and all other EME plugin storage) once
> PB mode exits, so I think we should be OK regardless.

You mean we write them to the disk and delete them once the PB session has exited?  If yes, can we instead keep that in memory similar to the other data?

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

Yes, I meant to say that we will write to memory instead of disk in PB mode. I already have a patch, but it's broken in e10s mochitests. :(

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

Fixed by bug 1060179.

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

Mass update firefox-status to track EME uplift.