905856 - Implement a "Locked Content" app for Forward Lock DRM

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Comment 1

[David Flanagan [:djf]]

This bug is for implementing the "Locked Content" app described in https://bugzilla.mozilla.org/show_bug.cgi?id=887071#c45

That app must:

 handle an Open activity to download locked media content
 handle a Pick activity to return locked wallpapers and ringtones
 generate a secret key and use it to encrypt locked music

Ideally, this app will also use the inter-app communcation API to offer a decryption service for the music it encrypted.

Making this confidential because the parent bug is.

Nominating for 1.2 because the parent bug needs to land in 1.2.

Also, adding some cc's from the parent bug.

Comment 2

[David Flanagan [:djf]]

More details copied from the parent bug:

Step 2) Write the Locked Content app. This is the app we've been calling the "Forward Lock" app. We could develop and host it outside of the Gaia tree, as a proof of concept only.  (Maybe we put it in Andreas's github repo to make it seem official without being official.) It is not part of the build, but carriers can add it to the build if they choose to. Like the Ringtone app, this Locked Content app will probably be iconless, and it will exist only to handle activity requests.

2a) The first time this app is invoked for any activity, it generates a random 32-bit integer and stores it in the settings database as the secret key.  Only certified apps can read the settings database, so only certified apps have access to the secret. ***This means, however, that any certified app can subvert the forward lock mechanism. This is implicit in Andreas's proposal as well.  Henri has pointed out that this means that the certification of certified apps will have to include DRM compliance. But maybe we can leave that to the carriers who choose to use the locked content app.***

2b) When invoked to handle the View activity for application/vnd.oma.drm.message, this app downloads the locked content. If it is a ringtone or wallpaper, it stores it unencrypted in an indexeddb. (For ringtones, it also has to store the name of the ringtone.) If the content is a song, it encrypts it by xoring the entire file with the secret key and saves the encrypted song to device storage in a directory such as /sdcard/music/locked/ with a filename extension like ".flm" (forward locked music).  (We would also need to modify Gecko so that the extension we use is recognized as music.  See bug 903682)  (If the app cannot distinguish the ringtone case from the music case, it asks the user what to do, or maybe just does both.)

2c) When the locked content app is invoked to handle the "Pick" activity for image/*, and when the activity request includes the secret key, it looks for all wallpapers stored in its database and displays them at reduced size to the user, much like the existing Wallpaper app does. (It also displays a message explaining that the images are locked by the vendor and cannot be transferred off the device.) When the user selects one, the app stores the unencrypted image blob in the settings database so that it becomes the current wallpaper.  (Note that this means that all certified apps can read the current wallpaper, even if it is locked). The app manifest should be written so that if the Pick activity does not include any secret key, the locked content app is not shown, and if it includes an incorrect secret key, the locked content app displays an error message. With this activity implemented, when the user tries to set the wallpaper from the homescreen or the settings app, they will be asked to choose from "Camera", "Gallery", "Locked Content", and "Wallpaper".

2d) When the locked content app is invoked to handle the "Pick" activity for audio/*, and when the activity request includes the secret key, it should find all ringtones (and ringtone names) in the database.  It displays a message about what "locked" means, and displays a list of ringtone names. It allows the user listen to them and pick one, much like the Ringtone app from step 1 does. When the user picks one, the app stores it in the settings database making it into the current ringtone. Basically, this is like case 2c, but for ringtones.  With this activity implemented, when the user uses the settings app to change ringtones, they will see choices: "Ringtones" and "Locked Content" (and possibly also Music).

2e) If the inter-app commnication API lands in time, this Locked Content app should also use it to listen for requests to decrypt locked content. If it is passed a locked content blob, along with the secret key, it should decrypt the content and return it to the calling app.  (If the IAC API is not ready in time, the the Music app will have to do its own decryption).

2f) The Locked Content app could optionally have an icon and, when invoked from the homescreen, could display wallpapers and ringtones and have a UX allowing the user to set them as the current wallpaper or ringtone or to delete them.  (Note that there is no other deletion UX, so this part is necessary if we think the user might ever want to do that.)  

2g) If carriers want to adopt and extend this app, there might also be some sort of UX here to purchase more locked content, but that would be up to the carrier.

Comment 3

[David Flanagan [:djf]]

Adding Rob to the cc list so he can advise on the UX issues.

Rob: given the aggressive timeline for landing this, we don't have time for full wireframes or anything. The primary goal here is to implement this feature so we can pass carrier certification.

Since we're implementing this for the carriers, however, we can try to finesse the situation and do our best to educate users about DRM.  When the user downloads locked content, we have the opportunity to warn them that they won't be able to transfer it off the device.  And when the user picks a locked wallpaper or ringtone, we have the opportunity to remind them that they don't own the contnet and that free alternatives are available.

I'm not sure what the right thing to do here is, but it seems like a potentially interesting UX question.  Any guidance you can offer would be welcome.

Comment 4

[Rob MacDonald [:robmac]]

Thanks, David - I've added Stephany and Jacqueline as I'll be away next week. Stephany, I'm also wondering if the Marketplace team has any thoughts on this.  - Rob

Comment 5

[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 887071.

Comment 6

[David Flanagan [:djf]]

I've begun working on an "lc" (locked content) app in gaia/apps/lc/. My work in progress is here: https://github.com/davidflanagan/gaia/tree/bug905856

I hadn't realized before that the OMA Download specification is independent of the OMA DRM specification and is more complex than I realized.  My work in progress so far is implementing the download piece of the app. I haven't gotten to any of the DRM parts yet.

The download spec is here: http://technical.openmobilealliance.org/Technical/release_program/docs/Download/V1_0-20040625-A/OMA-Download-OTA-V1_0-20040625-A.pdf

Comment 7

[David Flanagan [:djf]]

I've created a work-in-progress pull request here: https://github.com/mozilla-b2g/gaia/pull/11914

This is not ready to land to master, but is ready for preliminary testing and demos.

It does not do ringtones or wallpaper yet, but does allow locked music to be downloaded and played.

Comment 8

[David Flanagan [:djf]]

Attachment: work in progress patch

This is my work in progress in patch form instead of pull request form.

Comment 9

[David Flanagan [:djf]]

The "work in progress" pull request is now a "proof of concept" pull request. It is not ready to land, but it handles locked songs, ringtones and wallpapers.  See https://github.com/mozilla-b2g/gaia/pull/11914

In addition to fixing this bug, the patch also includes code for bug 905849 and bug 905867.

Comment 10

[David Flanagan [:djf]]

Attachment: link to github pull request

This is one big pull request for all of the Forward Lock stuff that carriers need from us.  It is not ready to land: I'm still working on the UX for the media download part.  But it is a big patch and substantial parts of it are ready for review, so I'm attaching it now in the hopes of getting the review going.

Kaze: would you review the changes to the settings app and the new ringtones app where most of the ringtone (and alert tone) code has moved to?

Dominic: would you review the changes to the Music app?  They are quite small, and rely on shared files in shared/js/omadrm/fl/ to unlock locked music files for scanning and playback.

Andreas: the locking scheme here is based pretty much on what you proposed. Do you have time to review the two files in shared/js/omadrm/fl/?  They handle the key management via settings database and the xor-based lock/unlock mechanism.  If you don't have time, is there anyone you'd suggest for this security-sensitive review?

Comment 11

[David Flanagan [:djf]]

Kaze: if you are familiar with how the wallpaper app works, I'd appreciate your review of the minor wallpaper-related changes to the wallpaper app, the homescreen app and the settings app in addition to your review of the ringtone-related changes.

Comment 12

[David Flanagan [:djf]]

Comment on attachment 802805 [details]
link to github pull request

Asking Rob for UX review of this patch based on the screenshots in the document I attached to the parent bug.

Comment 13

[David Flanagan [:djf]]

Comment on attachment 802805 [details]
link to github pull request

John,

I'm close to being finished with the "locked content" app portion of this patch, and am wondering if you will have time to review the parts of the patch in apps/lc/.

The lc app handles the download of locked content in apps/lc/js/download.js, and that is the only particularly complicated part of the patch.

The lc app also handles the display of locked wallpapers and ringtones in apps/lc/js/pick.js. That code is mostly based on existing code in the Wallpaper app and in the new Ringtones app (which is also part of this patch).

I'd like to get this reviewed and landed by the FC deadline, but I know you may be too busy before then. If you know of anyone in the Taipei office who could review this, please ask them!

Comment 14

[Dominic Kuo [:dkuo]]

Comment on attachment 802805 [details]
link to github pull request

David,

The part of music app looks good to me. Note that I have mentioned two minor issues on github, but the issues are related to some existed bugs, so you don't have to modify your patch on that part.

Comment 15

[John Hu [:johnhu][:johu][:醬糊小弟]]

Comment on attachment 802805 [details]
link to github pull request

I didn't try it by myself because I don't have the url and enough information to have a locked ringtone or wallpaper.

The apps/lc looks good to me. But I have 2 questions about the implementation:

1. We use memory buffer to parse multipart content. If the file is huge, we may get OOM. But we may not meet it in the cases of ringtone and wallpaper.

2. The encryption algorithm is XOR. That is so weak and easy to get the secret key with one XOR operation with plaintext and cipher. I know there is another weakness on saving secret key in mozSettings. So, I don't feel this is what we need to concern in this phase.

Comment 16

[David Flanagan [:djf]]

(In reply to John Hu [:johnhu] from comment #15)

> 
> 1. We use memory buffer to parse multipart content. If the file is huge, we
> may get OOM. But we may not meet it in the cases of ringtone and wallpaper.
> 

That's a good point. Maybe I should pick some maximum size and return an error for downloads that are too big.  That would be safer than risking an OOM. It might also be possible to save the download as a blob and then extract the content from it using my BlobView class.  But I might not have time to do that, so a maximum download size seems like a good idea.

Comment 17

[Punam Dahiya [:pdahiya]]

Hi David

To disable download button while downloading content

1. Please remove link <link rel="stylesheet" href="shared/style/buttons.css" type="text/css" /> from lc/download.html

2. Add below css in lc/style/download.css
#download-confirm[disabled] {
  background: #e7e7e7 !important;
  border-color: #c7c7c7 !important;
  color:#c7c7c7 !important; 
  text-shadow: none !important;
  pointer-events: none;
}

Thanks

Comment 18

[David Flanagan [:djf]]

I've done some refactoring to the key management and locking code so that it is all in a single file.  And relatedly, I've modified the apps that use activities to check whether a forward lock key exists before launching hte activity. This allows us to only show the Locked Content activity choice if the user has actually installed some locked content on their phone.  If you never use the feature, you'll never see the app in your activiites menus.

Comment 19

[David Flanagan [:djf]]

Comment on attachment 802805 [details]
link to github pull request

Adding Henri and Paul as reviewers since Andreas is pretty unlikely to have time for this.

Henri and Paul: the core key management and locking/unlocking code for the patch is in shared/js/omadrm/fl.js  Could one or both of you review that file, please?

Comment 22

[David Flanagan [:djf]]

Comment on attachment 802805 [details]
link to github pull request

John,

Thank you for your feedback+ on this.  I've made changes to the LC app and am now asking for a full review.  Since you've already looked at it once, I don't imagine it will take you very long.

There is now a check for the length of the download so we don't OOM.

I've also added a preview step so that the user can see the wallpaper and hear the ringtone before installing.

Comment 23

[John Hu [:johnhu][:johu][:醬糊小弟]]

Comment on attachment 802805 [details]
link to github pull request

Thanks. I had tried it by myself. That looks cool.

I had read the code again. It is more robust. I give it as r+.

Comment 24

[Henri Sivonen (:hsivonen)]

Comment on attachment 802805 [details]
link to github pull request

Looks like we have to use settings due to schedule constraints, so okay on that point with the caveats I've stated before. I suppose xor good enough, given the schedule constraints.

If you have the time before the deadline, I suggest putting a non-printable ASCII control character in the magic number (preferably as the first byte to distinguish from text as soon as possible).

r=hsivonen on fl.js either way.

Comment 25

[David Flanagan [:djf]]

Attachment: screenshot: margins around the progress bar, no crawling ants, black background

Comment 26

[David Flanagan [:djf]]

Attachment: screenshot: better error messages

Comment 27

[Andreas Gal :gal]

I will pass on reviewing this (I am not an expert on most of the underlying code, the basics look good). Please land!

Comment 28

[David Flanagan [:djf]]

Andreas: I got Henri's review of the locking and key management code that I had asked you to review. So this patch is not blocked on your review. I'm still waiting for Kaze's review of the parts that modify the Settings app. 

Is our feature deadline such that I really should land this without full review?

(Also still waiting on a couple of icons, but I'm willing to land without those)

Comment 29

[Fabien Cazenave [:kaze]]

Comment on attachment 802805 [details]
link to github pull request

Thanks for addressing the comments I left on github.

R=me for the Settings part, the Ringtones app and the wallpaper-related changes (in the wallpaper/homescreen/settings apps). Amazing work!

Comment 30

[David Flanagan [:djf]]

Landed to master: https://github.com/mozilla-b2g/gaia/commit/be94cd5f33609aa69fc86457c3ec316c1bfe20ea

Comment 31

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted be94cd5f33609aa69fc86457c3ec316c1bfe20ea to:
v1.2: 30b23de56d8b93bf203636e4b95329f199b4016c

Comment 32

[Rob MacDonald [:robmac]]

Comment on attachment 802805 [details]
link to github pull request

clearing flag