source code access

[Stephen Cunliffe]

One of the biggest concerns on other mobile platforms is access to source code/piracy.

When an app is placed in the Firefox OS marketplace (or other store) and users can download/purchase it... do the (savvy) end users have access to the underlying source code? or is the content placed on their device in a folder that they don't have typical read access to thus can't see the actual code (e.g. steal it & clone) or copy the app to another device (e.g. piracy)?

Thanks,
Steve

[David Clarke]

Steve,
The web is built on html / javascript / css, and generally there are lots of different implementations for websites, games, blogs, video / picture sharing, social networks, and they all use this same standard.

You have multiple ways to deliver your app to the end user. You can package your entire app up, and deliver it as a bundle of html /js / css.
https://developer.mozilla.org/en-US/docs/Apps/Packaged_apps or you can have your app hosted on the web and installed by the end user.

The good thing about the web is you can take snippets, learn how someone else created a css transition, or animation. There is never a shortage of people who would try to clone your software and release a similar app, however I don't think this has been a problem for the web, and don't really think you'll have much of a problem on mobile.

Also, there are several tools out there that you can use to obfuscate / minimize your css /js which for your purposes should make your actual code harder to decipher, but not harder to copy.

-David

_______________________________________________
dev-webapps mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

[Stephen Cunliffe]

Thanks David.

I totally understand the Web side of things (heck view-source: is how I learned to begin with).

With "web apps" or "html5 games" that are not served up live from a server but downloaded to the device as "an app" there's a little piece of the web that changes as developers often would like to monetize their apps and also protect their code.

I was hoping that there was a basic effort on the device to obfuscate/hide the source from the user. e.g. what if that source contains API keys to REST services?

I don't think that the level of code security will stop me from developing but I think I'll go the extra mile and at least obfuscate/minimize my code to at least make it harder to re-engineer.

Thanks!

[Fabrice Desre]

On production devices, root access is disabled so people don't get easy
access to the packaged apps downloaded.

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Harald Kirschner]

Hi Stephen,

As David said, obfuscates would be a first step to protecting your code. UglifyJS already munges several special cases for more efficient code, making it harder to reverse it. The next step would be Google Closure in advanced mode, which is a one-way transformation.

The final and most protected path for you would be Emscripten. Writing your business critical modules (like API client or Encryption) in C++ and compiling them to JavaScript (or even asm.js).The result resembles byte code, using typed arrays as memory.

We are working on ideas for protecting API keys, as it's a request often coming up with app partners. I'd be happy to hear input on that from this list!

---
Harald Kirschner | Mozillian Partner & Labs Craftsman | hkirs...@mozilla.com (mailto:hkirs...@mozilla.com)

> dev-w...@lists.mozilla.org (mailto:dev-w...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-webapps
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org (mailto:dev-w...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-webapps
>
>

[Kumar McMillan]

On Mar 4, 2013, at 11:27 AM, Stephen Cunliffe <stephen....@gmail.com> wrote:

> Thanks David.
>
> I totally understand the Web side of things (heck view-source: is how I learned to begin with).
>
> With "web apps" or "html5 games" that are not served up live from a server but downloaded to the device as "an app" there's a little piece of the web that changes as developers often would like to monetize their apps and also protect their code.
>
> I was hoping that there was a basic effort on the device to obfuscate/hide the source from the user. e.g. what if that source contains API keys to REST services?

Hi Stephen.
I would not trust B2G enough to put API keys on the client. An experienced developer can find a way to get root access to the phone, snoop around and find the package source.

There was some discussion around how to protect assets in relation to paid apps after this post https://hacks.mozilla.org/2013/02/building-a-paid-app-for-firefox-os/

If you're planning to sell a paid app it's important to understand how checking receipts works. It won't be 100% effective but with a strong server side component (which is possible even for a packaged app) you can combat piracy pretty well, I think.

Kumar

>
> I don't think that the level of code security will stop me from developing but I think I'll go the extra mile and at least obfuscate/minimize my code to at least make it harder to re-engineer.
>
> Thanks!

[Stephen Cunliffe]

Thanks everyone for the input! This is all great info.

In my case I'm likely being a bit paranoid but its obviously important info for some.

I think I'll be OK with some obfuscation and likely that Google Closure 1-way tool. In my particular case I have no sensitive API keys (in my first few apps) and there's nothing majorly magic about my code.

I'm quite happy with any efforts made to protect the code (it is appreciated!)

[Gervase Markham]

On 04/03/13 17:35, Harald Kirschner wrote:
> As David said, obfuscates would be a first step to protecting your
> code. UglifyJS already munges several special cases for more
> efficient code, making it harder to reverse it. The next step would
> be Google Closure in advanced mode, which is a one-way
> transformation.
>
> The final and most protected path for you would be Emscripten.
> Writing your business critical modules (like API client or
> Encryption) in C++ and compiling them to JavaScript (or even
> asm.js).The result resembles byte code, using typed arrays as
> memory.

While some partners will no doubt do it anyway, it concerns me a little
that we are going around actively recommending these things. Mozilla
runs the Webmaker program, whose entire point is that the web is
hackable and remixable, and that people should do that. It's this
ability to change and innovate which is part of the selling point of
Firefox OS to users and carriers.

If every Firefox OS app came as a bit of Emscripten-compiled-from-C++,
then it would be a very sad day for the open web.

Gerv

[Kumar McMillan]

I think there is a valid use case in protecting source code when a merchant is selling an app. If the app can't be protected, how can you sell it? And if you can't sell an app then you can't build a business on offering something compelling to the user. This obviously isn't the only business model for apps but it's one that the open web should support better than it does today, IMO.

I'd liked to see web businesses get support for more models than the ad model, which is the most prevalent today and it's clearly disliked by users.

-Kumar

>
> Gerv

> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-webapps

[Harald Kirschner]

Hi Gervase,

it's true, that our proprietary packaged format doesn't have "openness" written all over it to start with. Here the perspective from partner engineering:

As I want to promote openness and that companies share their work I only recommend putting "business critical" pieces in Emscripten. That means code that companies wouldn't open source anyways, as its part of their core business. With open sourcing other libraries, tools and snippets companies usually have no problem with, given that they can spend the time and people.

Even though obfuscation is a side effect of Emscripten; performance and optimal memory use are others.

There are other needs, like DRM and message encryption; which depend on protecting keys and sometimes protecting the algorithms. Even though its a weak protection, partners ask for it; some music streaming services bound by label contracts to have it.

I'd be happy to get some more ideas on how to get partners to open source more code and worry less about protecting their client side JavaScript. How do you see packaged apps fitting in the story we are weaving around openness and hackability?

Cheers,

---
Harald Kirschner | Mozillian Partner & Labs Craftsman | hkirs...@mozilla.com (mailto:hkirs...@mozilla.com)

On Tuesday, March 5, 2013 at 9:25 AM, Kumar McMillan wrote:

> I think there is a valid use case in protecting source code when a merchant is selling an app. If the app can't be protected, how can you sell it? And if you can't sell an app then you can't build a business on offering something compelling to the user. This obviously isn't the only business model for apps but it's one that the open web should support better than it does today, IMO.
>
> I'd liked to see web businesses get support for more models than the ad model, which is the most prevalent today and it's clearly disliked by users.
>
> -Kumar
>
> >
> > Gerv

[Gervase Markham]

On 05/03/13 17:25, Kumar McMillan wrote:
> I think there is a valid use case in protecting source code when a
> merchant is selling an app. If the app can't be protected, how can
> you sell it?

What do you mean by "protect"? This is the DeCSS fallacy - encrypting or
obfuscating something doesn't stop someone copying it. It' just as easy
to make a copy of the string "FCv46vszgrf" as it is to make a copy of
the string "Hello".

> And if you can't sell an app then you can't build a
> business on offering something compelling to the user. This obviously
> isn't the only business model for apps but it's one that the open web
> should support better than it does today, IMO.

The open web should support selling apps. And we have copyright laws
(and licensing servers) which are designed, to varying degrees of
effectiveness, to stop people copying paid apps without paying. But the
best way to sell apps is to make it easier to pay for them than to
pirate them. Mozilla should not join the list of companies attempting to
make water run uphill by stopping the Internet from being the fabulously
efficient machine for copying things that it is.

All obfuscating code does is stop people being able to read the code for
the apps they are already running and have paid for. And that's a great
shame.

Gerv

[Harald Kirschner]

I agree that obfuscation doesn't protect assets. Everything on client side can be "compromised" and developers need to understand that and design accordingly.

> All obfuscating code does is stop people being able to read the code for
> the apps they are already running and have paid for. And that's a great
> shame.

I'd love the idea that people would by apps to read their code, but I am not sure if that reflects current reality. I hope it's something that we can
promote in the Marketplace; like promoting open source apps.

---
Harald Kirschner | Mozillian Partner & Labs Craftsman | hkirs...@mozilla.com (mailto:hkirs...@mozilla.com)

> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org (mailto:dev-w...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-webapps
>
>

[Kumar McMillan]

On Mar 5, 2013, at 11:41 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 05/03/13 17:25, Kumar McMillan wrote:
>> I think there is a valid use case in protecting source code when a
>> merchant is selling an app. If the app can't be protected, how can
>> you sell it?
>
> What do you mean by "protect"? This is the DeCSS fallacy - encrypting or
> obfuscating something doesn't stop someone copying it. It' just as easy
> to make a copy of the string "FCv46vszgrf" as it is to make a copy of
> the string "Hello".

I wouldn't say it's just as easy; it's a littler bit harder. However, as soon as one person figures out the hard part and publishes it, then it's just as easy.

>
>> And if you can't sell an app then you can't build a
>> business on offering something compelling to the user. This obviously
>> isn't the only business model for apps but it's one that the open web
>> should support better than it does today, IMO.
>
> The open web should support selling apps. And we have copyright laws
> (and licensing servers) which are designed, to varying degrees of
> effectiveness, to stop people copying paid apps without paying. But the
> best way to sell apps is to make it easier to pay for them than to
> pirate them. Mozilla should not join the list of companies attempting to
> make water run uphill by stopping the Internet from being the fabulously
> efficient machine for copying things that it is.
>
> All obfuscating code does is stop people being able to read the code for
> the apps they are already running and have paid for. And that's a great
> shame.

To a lot of people that's like buying a car and not getting the schematics to the oil pressure sensor. In other words, they won't care, they have a car and they can drive it.

I agree that client side encryption/obfuscation is a hard problem and not worth our time to solve. I don't think we should prevent others from trying though.

Anyway, I think the ultimate success will come from apps that sell experiences rather than source code. If the game code you copied doesn't come with the ability to play against your friend across the Internet then it may not be fun at all in the pirated version. Building online communities is intrinsic to web technology; it can already do this very well.


>
> Gerv

[Andy McKay]

On 2013-03-04, at 9:16 AM, David Clarke <dcl...@mozilla.com> wrote:
> Also, there are several tools out there that you can use to obfuscate / minimize your css /js which for your purposes should make your actual code harder to decipher, but not harder to copy.

Bear in mind that if you want a packaged app, obfuscation might not be an option since it does not allow the reviewers to review your code and hence sign the app.

[Gervase Markham]

On 05/03/13 19:04, Harald Kirschner wrote:
> I'd love the idea that people would by apps to read their code, but I
> am not sure if that reflects current reality.

I don't expect people to buy apps to read their code; but I do hope some
people will read the code of the apps they buy - e.g. to find out how to
do something. That's how many people got started making web pages.

And a bit of software doesn't have to be open source in order for you to
read its code and be inspired by it, just as a web page doesn't have to
be CC-licensed for you to read the markup for ideas. There's no
copyright on ideas.

Gerv

[Gervase Markham]

On 05/03/13 17:29, Harald Kirschner wrote:
> As I want to promote openness and that companies share their work I
> only recommend putting "business critical" pieces in Emscripten. That
> means code that companies wouldn't open source anyways, as its part
> of their core business.

Let's not conflate "not obscuring" with "open sourcing". There are
plenty of web pages out there which are not under open source licenses,
but I can View Source them and be inspired nonetheless.

Also, in passing, let's not perpetuate the idea that core business code
can't or shouldn't be open-sourced. :-) There are plenty of
counter-examples.

> Even though obfuscation is a side effect of Emscripten; performance
> and optimal memory use are others.

Writing C++ and compiling to JS via Emscripten is now more performant
and uses less memory than writing JS straight?

> There are other needs, like DRM and message encryption; which depend
> on protecting keys and sometimes protecting the algorithms. Even
> though its a weak protection, partners ask for it; some music
> streaming services bound by label contracts to have it.

We can't get rid of other people's contracted foolishness; however, my
concern is not that it never happens, my concern is that we don't
recommend it.

> I'd be happy to get some more ideas on how to get partners to open
> source more code and worry less about protecting their client side
> JavaScript. How do you see packaged apps fitting in the story we are
> weaving around openness and hackability?

Why would they be different to non-packaged apps?

Gerv

[Lawrence Mandel]

> > Even though obfuscation is a side effect of Emscripten; performance
> > and optimal memory use are others.
>
> Writing C++ and compiling to JS via Emscripten is now more performant
> and uses less memory than writing JS straight?

That is my understanding. I've cced Martin, who should be able to give a more definitive answer.

Lawrence

[Fabrice Desre]

On 03/06/2013 07:59 AM, Gervase Markham wrote:
>
> Writing C++ and compiling to JS via Emscripten is now more performant
> and uses less memory than writing JS straight?

You can write emscripten-style JS by hand, but it's not a natural style
at all. Emscripten uses a big typed array as the c/c++ heap, and thus
avoid all garbage collection. That's pretty important for games since
this prevents gc jank.

[Martin Best]

There are two answers to this.

On desktop this tends to be true because Emscripten exports only js that is core to the language and well optimized. You also don't have GC pause issues. This uses about the same memory.

ASM.js, which is landing this month gives you about 4x faster and is already supported by Emscripten. This uses less memory.

JS on ARM is not in good shape. We have had issues with IonMonkey. It's causing all sorts of problems with Emscripten generated code as typed arrays are slow. This is a temporary situation and is being worked on.

Martin Best
E: mb...@mozilla.com
C: (647) 292-2748

This message was written on my iPhone. Likely to be short, overly direct, and totally unintelligibly auto corrected.

On 2013-03-06, at 11:04 AM, Lawrence Mandel <lma...@mozilla.com> wrote:

>>> Even though obfuscation is a side effect of Emscripten; performance
>>> and optimal memory use are others.
>>

>> Writing C++ and compiling to JS via Emscripten is now more performant
>> and uses less memory than writing JS straight?
>