1706121 - Netflix videos do not play in private browsing mode

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, defect, P1)

Description

[Neha Kochar [:neha]]

Netflix does not play videos in Firefox private browsing mode. They work fine in Chrome private browsing windows. Attached is the screenshot of the error page.
Previous related bug: bug 1267582

Some more context from slack conversations:
[jld] I don't know how much this helps, and I haven't tested it, but it should work normally in containers (for example, with Temporary Containers).

[bryce] Bug 1334111 is the reason. Sounds like Chrome was doing similarly at the time (https://bugzilla.mozilla.org/show_bug.cgi?id=1334111#c6). We could revert those changes, but would want to have an internal discussion first. I wouldn't mind us using volatile storage to persist and based on those bugs the engineering changes wouldn't be huge. However, we'd want to make sure various stakeholders are on board. https://help.netflix.com/en/node/51007 suggests this was at least once an issue in chrome too, https://bugs.chromium.org/p/chromium/issues/detail?id=997282#c4 mentions this was fixed in crbug 902021 M77, but that bug is hidden. So it sounds like Chrome changed behaviour here in M77 during 2019. The specifics are not available, but I guess they do something similar to what we used to do.

[arthur] Thanks, Bryce! There seems to be a key problem (from https://hg.mozilla.org/mozreview/gecko/rev/ad4e22629acfdd82aff8ead764949939726adbf4#index_header):“We want requests for MediaKeySystemAccess with persistentState to be rejected if the window is in Private Browsing mode. This is primarily so that users in Private Browsing mode don't unknowningly use up their "device limits"; some DRM
streamers have limits on the numbers of unique devices that can be provisioned/used in a given time period, and the device ID is persisted in the persistent state. So if we're flushing that state, the user will use up one of
their device quota on every new session, and quickly hit their limit, and be unable to continue watching DRM video.”

[bryce] We currently reject one of the EME promises, which is why this fails. Sadly the rejection doesn't provide very rich information which is why we get a generic error

Comment 1

[Daniel Bodea [:danibodea]]

Confirmed on all channels and platforms.

Comment 2

[Neha Kochar [:neha]]

This is still broken and the dependent bug is fixed. Does this depend on bug 1639542 because Netflix needs IndexedDB which doesn't work in Private Browsing mode?

Comment 3

[Jim Mathies [:jimm]]

(In reply to Neha Kochar [:neha] from comment #2)

This is still broken and the dependent bug is fixed. Does this depend on bug 1639542 because Netflix needs IndexedDB which doesn't work in Private Browsing mode?

Seems likely, we can ask on our discussion list with them.

Comment 5

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

No video playback can be observed on Netflix in private browsing, Netflix error code displayed: F7701-1003. Tested on Firefox 120.0a1 with Widevine CDM version 4.10.2710.0.

Comment 6

[Neha Kochar [:neha]]

Jim, this bug was closed as a dup of Bug 1267582 and that in turn, was resolved as Invalid, while the problem continues to exist i.e. Netflix videos do not play in Private windows. Where is this issue tracked if not in these 2 bugs? Does the team know what is the underlying cause of this?
Netflix videos work fine in Chrome and Safari private windows.

Comment 7

[Jens Stutte [:jstutte]]

(In reply to Jim Mathies [:jimm] from comment #3)

(In reply to Neha Kochar [:neha] from comment #2)

This is still broken and the dependent bug is fixed. Does this depend on bug 1639542 because Netflix needs IndexedDB which doesn't work in Private Browsing mode?

Seems likely, we can ask on our discussion list with them.

Bug 1831058 did enable IndexedDB and that rode to release in Fx 115, so either there is a bug with that implementation or it is simply something else.

(In reply to Timea Zsoldos [:zstimi/tzsoldos], Desktop QA from comment #5)

No video playback can be observed on Netflix in private browsing, Netflix error code displayed: F7701-1003. Tested on Firefox 120.0a1 with Widevine CDM version 4.10.2710.0.

Other APIs we are working on to make them available in PBM are Cache API (bug 1714354, close to be enabled) and service workers (bug 1320796, needs a few months, still). It would be good if we could see some logging from the console when this happens to confirm those are related or not.

Comment 8

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Jens Stutte [:jstutte] from comment #7)

Other APIs we are working on to make them available in PBM are Cache API (bug 1714354, close to be enabled) and service workers (bug 1320796, needs a few months, still). It would be good if we could see some logging from the console when this happens to confirm those are related or not.

This is the error message:

Uncaught (in promise) 
Object { code: 7701, ec: 1003, Vc: undefined, Pm: undefined, Ky: undefined, message: "Unable to create media keys system access. Key system configuration is not supported", details: "Key system configuration is not supported", data: DOMException, wj: undefined, VWb: undefined, … }

Looks like navigator.requestMediaKeySystemAccess is failing on private browsing mode. The call being made is:

navigator.requestMediaKeySystemAccess("com.widevine.alpha", [
  {
    "initDataTypes": [
      "cenc"
    ],
    "videoCapabilities": [
      {
        "contentType": "video/mp4;codecs=avc1.4d0028",
        "robustness": "SW_SECURE_DECODE"
      }
    ],
    "sessionTypes": [
      "temporary"
    ],
    "persistentState": "required"
  }
]);

And this indeed fails only on private browsing mode with DOMException: Key system configuration is not supported. As comment #0 already noted, bug 1334111 limited the access on PBM.

Comment 9

[Kagami Rosylight [:saschanaz] (they/them)]

Can persistentState: required be implicitly treated as optional on PBM? 🤔 (like we implicitly provide SessionStorage for window.localStorage?)

Comment 10

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

(In reply to Jens Stutte [:jstutte] from comment #7)

(In reply to Jim Mathies [:jimm] from comment #3)

(In reply to Neha Kochar [:neha] from comment #2)

This is still broken and the dependent bug is fixed. Does this depend on bug 1639542 because Netflix needs IndexedDB which doesn't work in Private Browsing mode?

Seems likely, we can ask on our discussion list with them.

Bug 1831058 did enable IndexedDB and that rode to release in Fx 115, so either there is a bug with that implementation or it is simply something else.

(In reply to Timea Zsoldos [:zstimi/tzsoldos], Desktop QA from comment #5)

No video playback can be observed on Netflix in private browsing, Netflix error code displayed: F7701-1003. Tested on Firefox 120.0a1 with Widevine CDM version 4.10.2710.0.

Other APIs we are working on to make them available in PBM are Cache API (bug 1714354, close to be enabled) and service workers (bug 1320796, needs a few months, still). It would be good if we could see some logging from the console when this happens to confirm those are related or not.

Tested Netflix videos with Firefox 115 in PBM, Widevine plugin version is 4.10.2710.0, encountered the same error: F7701-1003.

Comment 11

[Jim Mathies [:jimm]]

This is still generating the same error that's been reported -

Uncaught (in promise)
Object { code: 7701, ec: 1003, Vc: undefined, Pm: undefined, Ky: undefined, message: "Unable to create media keys system access. Key system configuration is not supported", details: "Key system configuration is not supported", data: DOMException, wj: undefined, XWb: undefined, … }

Comment 12

[Jim Mathies [:jimm]]

Jens, any idea what's going on here? This is filed in gmp, but it seems more pbm related. I'm not an expert in what we do in pbm, but it seems pretty obvious netflix needs something that isn't working.

Comment 13

[Kagami Rosylight [:saschanaz] (they/them)]

See comment #8, BTW.

Comment 14

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jim Mathies [:jimm] from comment #12)

Jens, any idea what's going on here? This is filed in gmp, but it seems more pbm related. I'm not an expert in what we do in pbm, but it seems pretty obvious netflix needs something that isn't working.

(In reply to Kagami [:saschanaz] (they/them) from comment #8)

As comment #0 already noted, bug 1334111 limited the access on PBM.

From https://hg.mozilla.org/mozilla-central/rev/411fa6abd4f3 from bug 1334111:

We want requests for MediaKeySystemAccess with persistentState to be rejected
if the window is in Private Browsing mode. This is primarily so that users in
Private Browsing mode don't unknowningly use up their "device limits"; some DRM
streamers have limits on the numbers of unique devices that can be
provisioned/used in a given time period, and the device ID is persisted in the
persistent state. So if we're flushing that state, the user will use up one of
their device quota on every new session, and quickly hit their limit, and be
unable to continue watching DRM video.

I understand this to be a policy decision. If the policy is changed, it would be necessary to ensure that data is cleared on the last-pb-context-exited observer notification, with dom/media having 3 existing hookups, but not dom/media/eme. I do see the ClearDataService EMECleaner and the API it uses for clearing defined in mozIGeckoMediaPluginChromeService.idl which could presumably be hooked up the notification.

Comment 15

[Romain Testard [:RT]]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #14)

(In reply to Jim Mathies [:jimm] from comment #12)

Jens, any idea what's going on here? This is filed in gmp, but it seems more pbm related. I'm not an expert in what we do in pbm, but it seems pretty obvious netflix needs something that isn't working.

(In reply to Kagami [:saschanaz] (they/them) from comment #8)

As comment #0 already noted, bug 1334111 limited the access on PBM.

From https://hg.mozilla.org/mozilla-central/rev/411fa6abd4f3 from bug 1334111:

We want requests for MediaKeySystemAccess with persistentState to be rejected
if the window is in Private Browsing mode. This is primarily so that users in
Private Browsing mode don't unknowningly use up their "device limits"; some DRM
streamers have limits on the numbers of unique devices that can be
provisioned/used in a given time period, and the device ID is persisted in the
persistent state. So if we're flushing that state, the user will use up one of
their device quota on every new session, and quickly hit their limit, and be
unable to continue watching DRM video.

I understand this to be a policy decision. If the policy is changed, it would be necessary to ensure that data is cleared on the last-pb-context-exited observer notification, with dom/media having 3 existing hookups, but not dom/media/eme. I do see the ClearDataService EMECleaner and the API it uses for clearing defined in mozIGeckoMediaPluginChromeService.idl which could presumably be hooked up the notification.

Do we know how frequent of a use case this is ("DRM streamers have limits on the numbers of unique devices that can be provisioned/used in a given time period")? It seems we prevent Netflix playback as a consequence of trying to avoid users from being blocked from streaming on websites using DRM with specific limits but maybe this use case is marginal VS Netflix playback and user impact is worst as a consequence?

Comment 16

[Alastor Wu [:alwu]]

This bug is caused by us intendedly blocking the persist state [1]. At the time it was implemented, Chrome seems blocking that as well [2].

I tested the latest Chrome and Edge, they no longer restrict that, so Netflix can be played on their PB mode.

Per [3], there are two reasons we chose to do that,

• That's how other browsers do it.
• Sites witness lots more apparent device registrations.

The first reason is no longer true. The second reason doesn't make much sense to me. Per [4], websites have ways to detect if a user is in a PB or not. So if watching DRM playback causes the device limitation which seems the website's responsibility to handle the issue.

In addition, we didn't even sure if users suffer from the device limit problem at all, because we have never verify that (also don't have a way to do that, unless asking those stream providers if they have such data and be willing to share it to us)

But considering (1) compatibility problem (other browsers can do) (2) breaking the website by preventing a problem, which is actually a website's responsibility, I would prefer backout the restriction to make persist state work on the PB as well.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1706121#c14
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1334111#c6
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1775019#c3
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1334111#c9

Comment 17

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Alastor Wu [:alwu] from comment #16)

Per [4], websites have ways to detect if a user is in a PB or not.

AFAIK there's no standardized way for that, and any trial includes hacky way to check whether a given API doesn't work (that is known to be broken only in PBM, just like in this bug). So,

So if watching DRM playback causes the device limitation which seems the website's responsibility to handle the issue.

I don't think this is true. We don't want websites to handle PBM and are trying hard to make things seamless as possible in PBM.

Comment 18

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Alastor Wu [:alwu] from comment #16)

I would prefer backout the restriction to make persist state work on the PB as well.

At the risk of being pedantic about the phrasing of the term "backout" here, it's also essential to ensure that the requirements around data storage (no storage of data or the origin name in the clear; in memory or encrypted only) and data clearing (clear on "last-pb-exited" observer notification) related to Private Browsing Mode are met here and (marionette[1]) tests exist. I agree that conceptually the policy change is just a backout; I just want to make sure no one forgets about the fundamentally coupled work that's necessary to implement such a change in policy. (And maybe that work is somehow already still around and the backout just needs comments explaining where those implementation details a commit message explaining where the tests are?)

1: Because of the complexity of browser shutdown and in particular, the lack of any tight bounds or ratchets on content global lifecycles for browser shutdown, it's essential to validate what data is visible on disk after shutdown and/or a crash from outside the browser process (although in general things have been improving in this space). This also helps ensure that checks reflect the reality (the file in the profile directory or temp directory) as opposed to what internal in-memory state says, which can commonly converge to the same state, but which may not get that chance at shutdown, etc.

Comment 19

[Tom Ritter [:tjr]]

I concur with the above - it's fine to enable it, just ensure the data isn't persisted to disk and is wiped at the end.

Comment 20

[Jim Mathies [:jimm]]

offtopic

Comment 21

[Jim Mathies [:jimm]]

Moving back to S2 now that the dependent work is complete.

Comment 22

[Alastor Wu [:alwu]]

When we use GMP plugin under the private browsing window, we won't use the persistent storage for the plugin. When persistent state is required by EME, the underlying storage created will be a memory storage, not a disk storage. When Widevine File IO requests a GMPRecord, we would use a correct storage type so that Widevine won't create any real file on the disk.

However, the memory storage currently would only be clear after closing Firefox, but it should be clear when the private browsing window is close. That means we probably need to observe last-pb-context-exited event to do a proper clean up. In the conclusion, we shouldn't and won't leak anything when using EME on the private browsing window. I will do more testing later and see if the result is as my expectation.

Comment 23

[Alastor Wu [:alwu]]

Attachment: Bug 1706121 - part1 : add gmp logs.

Comment 24

[Alastor Wu [:alwu]]

Attachment: Bug 1706121 - part2 : allow using the persistent state for EME in private browsing window.

Depends on D210066

Comment 25

[Alastor Wu [:alwu]]

Attachment: Bug 1706121 - part3 : clear temporary storage when PB session ends.

Currently when PB session ends, we only clear the node Id, but leave the
storage unclear until Firefox is close.

We should clear temporary storage immediately when the PB sessions ends
in order to prevent any unexpected memory data leak.

Depends on D210067

Comment 26

[Alastor Wu [:alwu]]

Attachment: Bug 1706121 - part4 : modify test.

Depends on D210068

Comment 27

[Alastor Wu [:alwu]]

Attachment: Bug 1706121 - part5 : prevent using MFCDM under the private browsing mode.

For GMP CDM, we will use memory storage for it under the private
browsing mode, but we can't do that for MFCDM.

Therefore, we should disable it under the private browsing mode to
prevent any user data leak.

Depends on D210069

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/01cb0ac1a71d
part1 : add gmp logs. r=media-playback-reviewers,padenot
https://hg.mozilla.org/integration/autoland/rev/a2ecfc4a721f
part2 : allow using the persistent state for EME in private browsing window. r=media-playback-reviewers,padenot
https://hg.mozilla.org/integration/autoland/rev/ddcecf1fbcfb
part3 : clear temporary storage when PB session ends. r=media-playback-reviewers,padenot
https://hg.mozilla.org/integration/autoland/rev/2a2d1200d511
part4 : modify test. r=media-playback-reviewers,padenot
https://hg.mozilla.org/integration/autoland/rev/ad0fa931d9e8
part5 : prevent using MFCDM under the private browsing mode. r=media-playback-reviewers,padenot

Comment 29

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/01cb0ac1a71d
https://hg.mozilla.org/mozilla-central/rev/a2ecfc4a721f
https://hg.mozilla.org/mozilla-central/rev/ddcecf1fbcfb
https://hg.mozilla.org/mozilla-central/rev/2a2d1200d511
https://hg.mozilla.org/mozilla-central/rev/ad0fa931d9e8

Comment 30

[Ryan VanderMeulen [:RyanVM]]

Should we add this to the Fx128 relnotes? Please nominate if yes.

Comment 31

[Alastor Wu [:alwu]]

Release Note Request (optional, but appreciated)
[Why is this notable]: It allows using persistent state for EME request in the private browsing mode, making some DRM playback playable.
[Affects Firefox for Android]: Yes
[Suggested wording]: Allows users to watch DRM playback, eg. Netflix, in the private browsing mode.
[Links (documentation, blog post, etc)]:

Comment 32

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx128 relnotes.

Firefox now supports playback of protected content from streaming sites like Netflix while in Private Browsing mode.

Comment 33

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Issue is reproducible on a 2024-05-13 Nightly build on Windows 10.
Verified as fixed on Firefox 128.0b2 and Firefox Nightly 129.0a1 on Windows 10, Ubuntu 22, macOS 12.
Netflix videos are properly loaded and played in private browsing mode.