blocking-b2g: --- → koi?
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.
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.
I recommend mp3x and aacx and oggx etc. There are multiple formats that FL can be applied to.
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.
Ack. The parent bug is 887071
(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.
(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.
Need definitive answer from Product about whether this is required for 1.2. NI?Sri
Yes, we need this for V1.2
I've implemented this as part of my work-in-progress patch in bug 905856.
Assignee: nobody → dflanagan
Closing this bug as a dupe of bug 905856 because that bug has the patch.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 905856
You need to log in before you can comment on or make changes to this bug.