Closed
Bug 905867
Opened 11 years ago
Closed 11 years ago
[music] support scanning and playback of locked music
Categories
(Firefox OS Graveyard :: Gaia::Music, defect)
Tracking
(blocking-b2g:koi+)
RESOLVED
DUPLICATE
of bug 905856
blocking-b2g | koi+ |
People
(Reporter: djf, Assigned: djf)
Details
(Whiteboard: MEDIA_TRIAGED)
No description provided.
Assignee | ||
Updated•11 years ago
|
Group: mozilla-corporation-confidential
blocking-b2g: --- → koi?
Assignee | ||
Comment 1•11 years ago
|
||
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.
Assignee | ||
Comment 2•11 years ago
|
||
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•11 years ago
|
||
I recommend mp3x and aacx and oggx etc. There are multiple formats that FL can be applied to.
Assignee | ||
Comment 4•11 years ago
|
||
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.
Group: mozilla-corporation-confidential
Assignee | ||
Comment 5•11 years ago
|
||
Ack. The parent bug is 887071
Assignee | ||
Comment 6•11 years ago
|
||
(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.
Assignee | ||
Comment 7•11 years ago
|
||
(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•11 years ago
|
||
Need definitive answer from Product about whether this is required for 1.2. NI?Sri
Flags: needinfo?(skasetti)
Updated•11 years ago
|
blocking-b2g: koi? → koi+
Updated•11 years ago
|
Whiteboard: MEDIA_TRIAGED
Assignee | ||
Comment 10•11 years ago
|
||
I've implemented this as part of my work-in-progress patch in bug 905856.
Assignee: nobody → dflanagan
Assignee | ||
Comment 11•11 years ago
|
||
Closing this bug as a dupe of bug 905856 because that bug has the patch.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•