690143 - Update of watermarked add-ons

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: API, defect, P2)

Description

[Andy McKay]

In the addon update at https://versioncheck.addons.mozilla.org, if the add-on is premium, we serve back the appropriate watermarked add-on.

The Marketplace Docs from @fligtar say:

"When these add-ons check for updates, the purchase should be verified with that account. If the account is invalid or missing for a premium add-on, a 400 error should be returned, which will eventually be surfaced in Firefox as a guilty-sounding message."

To do that verification and to serve a watermarked addon, we need to have the user that purchased the addon on AMO. Is the assumption that update will assume that a request with purchaser=... we will check purchase status and watermark with that? Or is it that they will be logged in.

If they need to be logged in, what will happen when they aren't logged in, can I just send a redirect to the login page?

Comment 1

[Dave Townsend [:mossop]]

Not me as far as I can see

Comment 2

[Andy McKay]

I was assuming Add-on Manager would need to know how to cope with login requests from AMO.

Comment 3

[Dave Townsend [:mossop]]

Then there would need to be an add-ons manager bug filed for that

Comment 4

[Justin Scott [:fligtar]]

We don't need to check that the user is logged in, only that the user info in the ping has indeed purchased that add-on.

Comment 5

[Andy McKay]

So if I can find out whom has purchased an add-on, I can get a watermarked copy from AMO? The update ping will send back the URL to Add-on Manager of the URL to get it from, we'll essentially have to trust that request from the Add-on Manager for the watermarked file. 

We could obfuscate this by the use of tokens, but as long as I can send that ping to AMO, I can get the watermarked add-on.

Comment 6

[Wil Clouser [:clouserw]]

I see what andym is saying.  If our watermark is based on just the email address anyone could get watermarked add-ons.  If we require them to be logged in, we should prompt for that in firefox or users who don't log in will never get updates.

Comment 7

[Justin Scott [:fligtar]]

The watermarks aren't intended to be full DRM, only a way to verify that a purchase is tied to a specific user and monitor the number of installations that user has to detect wide sharing.

Once BrowserID is integrated into the client we can look at more sound solutions for authentication. Using a token or hash of some sort to make sure a user didn't just guess that fligtar at gmail bought this add-on is a good idea.

Let's discuss tomorrow morning if you're still unsure.

Comment 8

[Andy McKay]

I am concerned about this and would like to discuss it further.

Comment 9

[Andy McKay]

After chatting to fligtar we came up with:

We'll include a hash in the updateURL that gets added to the install.rdf, along with the existing value of purchaser. That will be sent to versioncheck.

Versioncheck will then return that hash and the purchaser in the updateLink in the RDF. 

Then add-on manager will request the watermarked addon with the purchaser and the hash data. If those all match, the watermarked addon will be returned and installed.

This should prevent just spamming for emails of purchasers.

Comment 10

[Mark Goodwin [:mgoodwin]]

Can I have some more information on what, exactly, I'm looking at for secreview and where the code is, etc. please?

Comment 11

[Andy McKay]

We serve an addon with a hash:

https://github.com/mozilla/zamboni/blob/master/apps/versions/views.py#L107
https://github.com/mozilla/zamboni/blob/master/apps/addons/models.py#L1037

Then later we check that hash, so that an anonymous user can get an update without having to authenticate:

https://github.com/mozilla/zamboni/blob/master/apps/versions/views.py#L93

Comment 12

[Mark Goodwin [:mgoodwin]]

Thanks