1775019 - Podcast can not be played due to DRM error at podcasts.apple.com when navigating in PRIVATE BROWSING mode

Status: NEW

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Raul Bucata]

Attachment: Screenshot_34.jpg

"Environment:
Operating system: Android 11/ Android 12
Firefox version: Firefox Nightly 103.0a1 (2015887275-🦎103.0a1-20220618093037🦎)

Preconditions:
PRIVATE BROWSING mode enabled
Clean profile

Steps to reproduce:

1. Navigate to: https://podcasts.apple.com/us/podcast/blue-58-a-packers-podcast/id1137313181
2. Tap the "Play" button from one of the podcasts.
3. Observe the result.

Expected Behavior:
The podcast plays.

Actual Behavior:
An error message is received.

Notes:

• Not reproducible when navigating in Normal mode.
• Works as expected using Chrome.
• Screenshot is attached.
• Using Firefox Nightly, DRM permission is asked.

Comment 1

[Thomas Wisniewski [:twisniewski]]

This is failing because this call fails in private browsing mode:

navigator.requestMediaKeySystemAccess(
   "com.widevine.alpha", 
   [{
    initDataTypes:["keyids","cenc"],
    distinctiveIdentifier:"optional",
    persistentState:"required",
    videoCapabilities:[{
       contentType:"video/mp4;codecs=\"avc1.42E01E\"",
       robustness":"SW_SECURE_CRYPTO"
    }],
    audioCapabilities:[{
      contentType:"audio/mp4;codecs=\"mp4a.40.2\""
    }]
 }])

The promise rejects with DOMException: Key system configuration is not supported`

This is because they're requesting persistent state, which is not supported in Private Browsing mode due to this check: https://searchfox.org/mozilla-central/source/dom/media/eme/MediaKeySystemAccess.cpp#1008-1015

If I disable that check, then it seems to work fine.

:alwu, is failing like this a hard requirement, or do we have any flexibility to ignore it for private browsing mode (making sure we use a temporary in-RAM-only store in that case)?

Comment 2

[Alastor Wu [:alwu]]

Sorry, I don't know much about EME and our EME expert left a month ago :( By checking this, it seems more about PB team's decision. If they decide to enable it again and I will follow their decision because I don't have any strong preference.

Comment 3

[Martin Thomson [:mt:]]

Comment 1 correctly identified the proximate cause. According to Bug 1334111, Comment 6 the behaviour was adequately private (no leakage from PBM to non-PBM, proper clearing of state, etc...) prior to the check being added. The change was made because of the effect on sites.

I'm inclined to suggest that we back out the changes in Bug 1334111. Ehsan's comment about not being concerned about leaking PBM state is fine, but that's not motivation for a change. The real reasons for PBM being different are (source):

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

I don't see any real merit to the first argument here. Creating a difference between Firefox PBM and Firefox non-PBM is a worse problem than a difference between Firefox PBM and Chrome PBM. Sites not doing the full matrix of feature detection and testing for their CDM interactions is understandable. This bug is evidence of the difference creating problems for our users.

The second reason is worth examining. Deciding this way, at least in my view, biases toward sites not users. There are many reasons that a user might choose to use PBM, but an ephemeral session is the primary guarantee that provides. Sites that subsequently witness an apparent increase in registrations only do so because users asked us to do that for them.

Refusing to "persist" state for EME achieves our private browsing goals, but if it does so by making some sites break that's not a good trade-off for our users. We can at least pretend to persist that state, giving sites as much persistence as our users are willing to give them, which seems like the right answer.

A note of caution however. This check landed a long while ago. It would be good to do a little diligence here to ensure that nothing has changed to depend on that check being run. My understanding is that the CDM is unable to write to persistent storage directly by the sandbox, but double-checking the glue code would be sensible.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1334111

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1334111