905867 - [music] support scanning and playback of locked music

Status: RESOLVED DUPLICATE of bug 905856

(Firefox OS Graveyard :: Gaia::Music, defect)

Comment 1

[David Flanagan [:djf]]

As part of supporting forward lock DRM in bug 887071, we need to modify the music app to be able to decrypt encrypted music files before scanning their metadata and before playing them.  We also need to modify the music app so that it does not allow locked content to be picked or shared.

Comment 2

[David Flanagan [:djf]]

Here are some details from https://bugzilla.mozilla.org/show_bug.cgi?id=887071#c45:

(Note, though that we're probably using ".lcka" as the extension instead of ".flm". (See https://bugzilla.mozilla.org/show_bug.cgi?id=903682)

Step 3) Modify the music app to handle locked music files.

3a) If the music app discovers new music with a ".flm" extension, then it queries the settings database to get the secret key and uses IAC to ask the locked content app to decrypt the music. (Or decrypts it itself if IAC isn't ready or is too slow).  Then it parses the music metadata and stores the metadata in indexeddb it as it does for unlocked content along with a flag indicating that this is locked content.

3b) If the user plays locked content in the music app, the app uses IAC to request that the song be decrypted (or decrypts it itself, if necessary) before playing it.

3c) While playing or displaying locked music, the app must make the Share button display a message that explains that the music cannot be shared.

3d) When the music app handles a pick activity, if the activity request does not include the secret key, it must not allow locked content to be shared.

Comment 3

[Andreas Gal :gal]

I recommend mp3x and aacx and oggx etc. There are multiple formats that FL can be applied to.

Comment 4

[David Flanagan [:djf]]

Unchecking the confidential box. We can implement this in the open. If we need to discuss anything confidential, we can do that in the parent bug 877071.

Comment 5

[David Flanagan [:djf]]

Ack.  The parent bug is 887071

Comment 6

[David Flanagan [:djf]]

(In reply to Andreas Gal :gal from comment #3)
> I recommend mp3x and aacx and oggx etc. There are multiple formats that FL
> can be applied to.

See also bug 903682. I proposed a single extension so we don't have to support a full set of parallel extensions.  The music app determines the type of music based on metadata and doesn't actually use the extension.  I was thinking we could just append .lcka ("locked audio") to the end of the original filename to get .mp3.lcka, .m4a.lcka, etc.

Comment 7

[David Flanagan [:djf]]

(In reply to Andreas Gal :gal from comment #3)
> I recommend mp3x and aacx and oggx etc. There are multiple formats that FL
> can be applied to.

Also, the reason I didn't just propose a generic ".locked" extension to create .mp3.locked, etc., is that if we ever have to deal with locked images, I want device storage to be able to distinguish locked music from locked images with separate extensions.

Comment 8

[Dietrich Ayala (:dietrich)]

Need definitive answer from Product about whether this is required for 1.2. NI?Sri

Comment 9

[Sri Kasetti]

Yes, we need this for V1.2

Comment 10

[David Flanagan [:djf]]

I've implemented this as part of my work-in-progress patch in bug 905856.

Comment 11

[David Flanagan [:djf]]

Closing this bug as a dupe of bug 905856 because that bug has the patch.