6

I would like to offer some premium features within a Chrome extension. The idea is to make available the latter additional features whenever a user has donated a certain amount via PayPal.

Currently, my strategy is as follows:

1/. The user fills in the PayPal form.

2/. When the form is submitted, a return URL is generated containing some key parameters such as user ID, time of request, amount of donation. Everything is encoded via base64. For example:

var returnURL = 'https://subdomain.main.com/?params=';

// On Form Submission
function SubmitForm(type) {

    var paramURL = '?user=' + userID + '&time=' + now + '&type=' + ptype;

    // base64 encoding via btoa
    $('#donate [name=return]').val( returnURL + btoa(paramURL) );
    // Reday to submit form
    $('#PayPalForm').submit();

}

3/. Paypal donation is done and user is redirected to a subdomain of the extension's website with https enabled.

4/. Once on my website, some PHP code checks the referrer (i.e. is the user coming from PayPal?), and if the referrer looks good, it decodes the base64 string and gets the parameters (id, time, type...). For example:

// Retrieve URL parameters
$paramURL = parse_url(base64_decode($_GET['a']));
parse_str($paramURL['query'], $query);

$id_user = $query['user']; // ID of the user
$time_req = $query['time']; // Time of request/donation
$type_req = $query['type']; // Type of Premium license w.r.t amount donated

5/. At this stage, the idea is to create a new URL pointing to the options page of my Chrome extension with some existing and new parameters, among them the key that decrypts a part of the code encrypted by default when the user installs the extension. The first issue I meet is that I wish to find a way to encrypt those parameters in PHP and be able to decrypt them in Javascript in my extension.

What kind of symmetric encryption/ciphering method available both in PHP and JS should I use? AES256? On the JS side, I looked at the Crypto-JS and SJCL libraries. On the PHP side, AES encryption seems a bit tricky...

6/. Once the user is back to the extension's options page and that the URL parameters are decoded+decrypted, what would be your strategy to unlock specific features in a Javascript-written extension in order to limit cheating and free-riding coming from users, knowing that obfuscation is a very poor choice.

Community
  • 1
  • 1
flo
  • 983
  • 8
  • 23
  • @Arian, the extension's main features are free. It's just that some additional functionalities require a big time-involvement and the current monetization model, i.e. donations, is not optimal in terms of incentives (imo). I think a rewarding system giving my most generous users the possibility to use a more powerful version of the extension could be an interesting approach. I might be wrong :) – flo Dec 27 '13 at 01:02
  • ahh great response, makes sense! – Arian Faurtosh Dec 27 '13 at 01:24
  • What did you end up doing? – Benjamin Gruenbaum Mar 19 '14 at 10:51

4 Answers4

1

The key you are looking for is the 'custom' attribute in your paypal button form. Something like so:

<input id="customField" type="hidden" name="custom" value="SENT_FROM_addon_form">

If you have created a developer button in paypal developer, and set a validation URL, that custom variable will show up in the $_POST in PHP.

You do not need encryption during this step as paypal requires you to use https which is automatically encrypted. However if you do want to use encryption purely server-side, you should check out crytpo.js

john k
  • 6,268
  • 4
  • 55
  • 59
0

We do this ( http://tipranks.com ),

I don't think you need any encryption here. Don't send the 'encrypted' code at all.

Only send data from the server if the user has permission for it.

You let the user log in once and when they do you get their permissions in return, then the server only returns the data if the user has permission for it.

Essentially - an extension is no different from any website in this regard.

Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
  • Thanks @Benjamin. Yes, this is another approach. I wanted to use a database-free mechanism and keep the majority of the code part of the original extension, but your method is certainly the simplest and most effective, indeed. – flo Dec 27 '13 at 01:08
  • 1
    @flo it also works in practice. Keeping encrypted code introduces a _huge_ overhead when debugging or getting error reports from users (good luck with line numbers etc) - you do need to keep a list of subscriptions/users and keep to best practices as you would at any case. – Benjamin Gruenbaum Dec 27 '13 at 01:09
0

The Chrome Web Store program policies explicitly prohibit the approach you're describing:

Malicious Products:

[...] Where possible, make as much of your code visible in the package as you can. If some of your app's logic is hidden and it appears to be suspicious, we may remove it.

You will need to figure out an alternate way of monetizing your extension. If your extension depends on a web service which you operate, for instance, you may want to consider requiring a subscription to use that service.

  • 1
    This is not suspicious. He is trying to monetize his legitimate app. Knowing the people involved - they will not remove it just for that. – Benjamin Gruenbaum Dec 27 '13 at 00:58
  • 2
    The encrypted code will be suspicious *to a reader* inasmuch as it's impossible to tell what it's doing to the browser without the decryption key. –  Dec 27 '13 at 01:18
0

I think you can't lock premium features within an extension effectively. Anyone can inject js code using the browser developer console to unlock it pretty easily.

If the main features of your extension lies in a popup, then you can use an iframe, and within this iframe, you could call php code that does all the preprocessing before rendering UI (to lock/unlock premium features).

Limbus
  • 1