Nativescript: Security for the JS code

[valentinstoychev]

Think of ways to IP protection of the JavaScript which is packaged in the app packages.

If you are interested in this feature please leave comment here and vote for this issue in our ideas portal.

[RangerMauve]

Easiest way would be to uglify the code at some point during the build step

[NathanaelA]

I would add encryption. At least on iPhones, AES is hardware assisted.

But this would have to be tested to see what type of startup hit it would cause. I also would ONLY encrypt the users code and not the node_modules or tns_modules those are already open source.

[RangerMauve]

In some cases, some of the code in node_modules might actually be private modules, so that'd probably need to be encoded too.

[RangerMauve]

But even if it's encoded, or uglified, or obfuscated, there are still ways to get at the code if the app has a way of running without user input. So you can't really stop someone that actually wants to get it.

[NathanaelA]

Agreed, but making the bar a lot higher would be a good thing.

As for node_modules; if I have something I needed to be "encrypted" I would make sure to move it into my apps folder as a sub-folder. (i.e. /apps/my_modules/nativescript-topsecret) pretty much anything published npm is open source -- so I still tend to think node_modules should be excluded from the encryption. I know encryption will cause a hit; so the less items that are forced to be encrypted the better.

[RangerMauve]

Well, you should also keep in mind that npm now has first-class private modules, and though it might still be kind of new right now, I'm sure a lot of companies are going to be taking advantage of this.

What if there was some sort of whitelist for which modules/code were to be encrypted?

[NathanaelA]

Yeah, I am aware of those -- but I can't imagine that it is really that popular.

However maybe inside the package.json file, we can have a "encrypt" setting that nativescript detects and then automatically encrypts the files in side the user folders. This way a node_module can have that switch set and then its files would get encrypted.

[JamesReate]

I would vote for the package.json file having an encrypt setting. Easy to control and flexible.

[NathanaelA]

@valentinstoychev -- is this something that Telerik is serious about adding by default to NativeScript; or would this be something a third party (like me :grinning: ) could create as a paid add-on. I was already researching this before you posted your question and I have a pretty good idea how to do it on both the iOS & Android.

[FlipOneDev]

@Nathanaela @valentinstoychev - Nathanael, I think this IS a NativeScript security issue concern, and I suppose Telerik wouldn't want concerns about Javascript code security proliferate in the NativeScript user community.

I also believe the NativeScript team is capable enough to provide this feature for free to developers, and while I do understand your commercial intent, I personally would rather have it provided to us by NativeScript "gratis" as a feature.

[NathanaelA]

@FlipOneDev - As one of the very few third parties (i.e. non-Telerik employees) that has actually dug through most of the code in the whole project (the runtimes, meta generation, and this common code repo) I'm 100% sure the Telerik could do all the code; of that I have no doubt -- what they have created here is amazing and in some cases pure genius.

However, that being said; at this moment they have a LOT of things that they are working on, most of them a lot more important that this feature (at least in my humble opinion). I even suggested #195 should be something the community should do to help lighten the load of what is needed to be done; and personally I think #195 is a bigger feature (for developer mindshare) in my mind than this one. So that is the reason why this _might_ be something that they would be willing to let third parties handle since it might not be a core feature.

If you look at what I've created and already open sourced like LiveSync or Sqlite for NativeScript; you can see I'm fully behind making NS a awesome platform. However just like Telerik; I unfortunately have to pay bills too. :grin:

[valentinstoychev]

Hey @Nathanaela this feature is mostly requested by enterprise companies who are using our Telerik tooling and services as part of Telerik Platform. That said our idea is to introduce this feature as part of our paid offering.

I don't see a reason why you can't make it as a separate paid plugin, I don't think we will be able to provide this feature in the next 3 months at least so maybe you can be faster than us and use your research to implement it.

If you need any help with integrating this - please let us know. Once we have our plugins marketplace available we can think of including your plugin there.

[NathanaelA]

@valentinstoychev -- The only thing I can think of is actual plugin support. (Is their anyone I should bounce the issues off of like I ran into with LiveSync ) For this project at least Initially I can just easily distribute my own "modified" android/ios runtime with my new code and just keep it in sync with the real releases.

However, this would be much better if the plugin supported out of the box the ability to enhance/replace/add internal functions like "require" (which then would have solved my LiveSync issue that I'm currently trying to get a function added to the android-runtime so that people can now easily use the real time editing on the android emulator.)

[valentinstoychev]

The best way is to comment in the issues - just like you did. All the comments there are taken into consideration!

[FlipOneDev]

@Nathanaela - It's good to know this feature will be available in the Telerik Platform, but I think we also need it for the NativeScript CLI.

So if Telerik won't offer it as a free feature in the CLI, then by all means, please build one for us. I surely will be among its early adopters.

It's probably not necessary to say th is, but thanks for your contributions to the NativeScript ecosystem. We'll all benefit from it.

[sprhawk]

Appcelerator Titanium has a encryptJS feature, how it works ? I think native script can do the same thing.

IMO if the nativescript doesn't have a even same feature, it can not be used as a commercial development framework

Think when I worked out a complete app and upload it to app store / market, others can easily copy our source code and repackage it or exploit our apis

[maknz]

:+1:, protection around the JS code is a high priority for us.

[NathanaelA]

@maknz & @FlipOneDev is there a particular platform you need first? Android is the easiest for me; but I'm curious which platform is desired first...

[maknz]

Not in particular, ideally we'd have support for both iOS and Android eventually. That said, we wouldn't need this until placing apps in the app stores.

[FlipOneDev]

@Nathanaela - What I refer to as Javascript code protection/security is basically Javascript code "minification + obfuscation", NOT just "minification" as what tools such as the Google Closure Compiler, YUI Compressor or UglifyJS offer.

Being a development tool, It's something I'd want to use on the command line as part of a build process - for both iOS and Android. It's also a tool I'd pay a one-time fee for.

[NathanaelA]

@FlipOneDev - Actually I'm thinking one step larger than that. I'm thinking actual encryption of the files. So the files are actually encrypted in the apk & ios package and in the extracted state on the devices. However, this would require a replaced runtime (which I now have a lot of experience with now because of my LiveSync stuff :grinning: ) as the runtime would be totally responsible for loading the encrypted copy and doing the decrypting it in memory before using it (decrypted file would not touch the disk/sdcard). As for the TNS tool; I believe (but haven't verified) I might be able to patch into the TS -> JS compile phase and add a JS -> Encrypted JS phase. If they don't have that open yet to configuring external tools; I know I can create a new service file for the tns command line that you would be automatically installed in your "tns" command line folder.

This process has to be totally seamless for people to want to use it. (Or maybe I should say at least for me to want to use it it needs to be transparent and not interfere with my work flow...)

Minification & Obfuscation, are a good idea -- I had looked at the Minification a bit; just to make the size of the file smaller; but I hadn't looked into Obfuscation. My bigger concern is the encryption and how to make this as bulletproof as possible.

As for the fees; I would probably be on a yearly subscription bases; a yearly fee since the runtimes would have to be kept in sync with the release runtimes. But it would be like other companies that I've have annual licenses with; if you don't pay you can still use the version you have forever....

[FlipOneDev]

@Nathanaela - I think those are mighty good ideas.

Maybe you can have two versions of your tool so that it can cater to different development requirements/needs:

(1) a basic or entry-level, one-time-fee, command-line version that simply minifies and obfuscates Javascript code --- perhaps using UglifyJS for minification, and then your own implementation of the obfuscation feature.

(2) a professional or advanced, yearly-subscription-based, encryption package.

Looking forward to seeing your work on this completed tomorrow ;).

[NathanaelA]

Sorry guys I got distracted by some of the other projects I was working on (i.e. websockets). I'm going to try and get this one done next.

The encryption/decryption is pretty simple -- I have that easily figured out (a couple months ago). But the biggest issue is how do I keep the key secret -- I'm not sure their is a good way to keep the key secret. I can make it difficult (i.e. use several artifacts to create the key); but a determined hacker will find a way through the AES encryption since the key has to be generated somewhere in the app on the phone they control.

As a case in point; I decided to see if Titanium had a good way to store the key and it took me less than an hour to figure out how to decompile an encrypted Titanium application and get the source code. What they did wasn't bad, but as I stated above; the weakness is if you can figure out the key location -- you can easily decrypt it.

I guess I am raising the question; does anyone have any good ideas on Key storage/calculations; or do I just go ahead with a couple techniques to make it a high barrier to generate the decryption key and at least get code to be encrypted so it would easily eliminate any simple copying of the source code and eliminate any one not skilled in reverse engineering code.

At this point I think minification is going to be a highly recommended part of the process; because with minification at least then the code will be totally un-readable if they manage to decrypt it. I have some ideas on minification also; but at this moment I'm going to focus on the encryption side of things. Any other thoughts, suggestions?

[moll]

Who's your adversary, @NathanaelA? An evil competitor? They have the one hour to spend it takes to reverse the naíve obfuscated decryption routine. The rest of us don't particularly care about ugly JavaScript code that lacks tests. ^_^

[NathanaelA]

@moll - No, as far as I know I don't have any specific evil competitors. But that was my point; a determined person with knowledge of reversing, can reverse anything I can do since the key has to be in the application somewhere. So this is not a end-all solution. However, currently with NativeScript it is extremely easy for anybody to take any NS application and install it and pull everything out of it. I would rather not give any competitors a leg up on what I am doing. So by encrypting the JS code; then they can't just pull it out of the app and use it as is, which raises the bar for anyone attempting to clone my app.

As for your second comment; I have no idea what you are talking about -- what exactly does tests have to do with the subject of Minification or Encryption key management.

[maknz]

Obfuscation is definitely better than nothing, for sure.

[moll]

By "ugly code lacking no tests" I meant to hint that what good is your (minified) code to me if I can't continue working with it properly. Anyone worth their salt considers code without tests unsuitable for working with or extending. And those of us don't go stealing others' code. ;-)

"Encrypting" apps with keys in the same binary is a fool's errand. You waste a day of your own valuable time implementing something that's breakable by a fraction of that time. I'd stick with minifiers or go with a compiled language. Some of the former mangle enough names to perhaps satisfy your IP concerns.

[NathanaelA]

@moll -- Ah, I get what you are trying to say. I realize that there are people like you and me who won't be going around stealing others code; but looking at the Google store you can see their are people who will blatantly decompile a Java program, make a couple minor changes and then submit it as their own. My first app was like this. I wrote a very unique app; within a month it was cloned dozens of times using my data and my code.... Those are part of audience that I want to eliminate.

I realize that the encryption is not perfect solution -- however, I would disagree on your thoughts on the encryption (despite the weaknesses that we know exists) for three reasons:

1. If I can raise the bar on cloning my application above your application then, by all means it is worth while --> since the cloners will target apps they can easily clone vs a harder targets. So, your app gets cloned (since they can just rip your source code out in 2 seconds). Mine gets left alone since it is too hard of a target because it would take (hopefully) hours of work to potentially decrypt.
2. Just because someone of my skill level can decompile it doesn't mean that the average developer can. This eliminates another section of developers from stealing my app code.
3. A Boss (especially in larger companies) may require that I've done due diligence in attempting to protect the app. Cost is not normally the issue; the issue is protecting the companies IP.

As for the Minifiers/Obscuring the JS; like I mentioned in my earlier comment; I think they are part of the solution. If I minify/obscure the source; then encrypt it; that will really eliminate a large chunk of people attempting to clone my app as the code is almost worthless if they even do figure out how to decrypt it. :grinning:

[TheBrousse]

If I may add to the discussion @moll and @NathanaelA. While it is important to come up with a proper technical encryption solution. I don't think that this ticket should be used to discuss the _philosophy_ of whether or not you should encrypt apps.

Every single enterprise client we have impose that the technical solution we use to develop our apps have an encryption mechanism. Now if you dont have this type of clients, more power to you. But this is the world we live in and {N} can't be a contender until this is addressed.

My 2 cents

[rborn]

:+1: @TheBrousse

[stephenfeather]

@NathanaelA I'd encourage you to continue your project. No lock is unpick-able, but the trick is to make the effort cost more than the return.

"any encryption you do can be defeated so dont bother" is akin to saying "locks can be picked, so dont bother putting them on your house doors."

[NathanaelA]

@sfeather actually I have the first version done for android and am in the middle of testing it... I realize no lock is un-pickable. My objective is to be able to add a layer or two to your apps security.

[NathanaelA]

For those who are interested; a status update.

I have a fully working version on Android. I have the stuff to do the same for iOS; just haven't had time to work on it. (Too many other things on my plate). I have one issue that I'm hoping that they can fix for v1.5 (https://github.com/NativeScript/android-runtime/issues/271) but if they can't -- I'll work around it and have the scripts that encrypt everything do a hash check on the runtimes and throw a warning if the runtimes match the normal release versions.

Some real bench marks for those who are interested.

Please note these timings are on Geny emulator, on a fairly fast machine. So the hit might be more or less depending on the cpu of the actual device.

1. Minimizing and compressing all common core scripts speeds up boot by about 4,000nano seconds. (Not a major gain, on a fast machine, but might be a gain on a slow phone... Still need to do tests on an actual device). Also drops the raw file size from 1.1megs to about 600k. This actually can be useful for the device as then the the large number of runtime files all loaded at startup are much smaller...
2. Encrypting the entire runtimes actually slows down application boot by over a full second. So like I postulated earlier; their is a speed hit so I only recommend you encrypt what you need to; not the runtimes. (It is pointless in my opinion to encrypt the runtimes; it doesn't add any additional security to your program in the slightest -- I did it just to make sure EVERYTHING is working properly... Good stress test of the encrypt/decrypt code.)
3. Just encrypting all your entire application files (not the runtimes); the speed hit is negligible.
4. No changes are needed besides replacing the runtimes; I'll be using the exact same infrastructure and experience I have for my LiveSync/LiveEdit product.

Please feel free to ask any questions; and I hope to soon have a sample app you guys can play with to see how well it works. ;-D

[moll]

@NathanaelA: Encryption implies decryption: Where's the decryption key stored?

[NathanaelA]

@moll, Well, Awesome question that is actually the crux of the entire problem, and took a lot of thinking about how to handle this problem as I had the encryption & decryption code done months ago on Android. :grinning:

The actual key itself is generated from several pieces of information that is located in different places in a deployed application. The idea is to make it a very large barrier; and to make it as difficult to access the raw source again.

Unfortunately since the app does have to be able to decrypt it, so it obviously isn't impossible to break. (No protection is impossible, but you make layer after layer of security to make it more difficult and make them want to go pick an easier target). The files are NEVER decrypted and stored on disk/sdcard (you won't believe how many products make this stupid mistake). The stored versions always remain encrypted. Decryption is handled only in memory.

From my comparisons; It will be WAY WAY harder to break than any other JS based app system (I.e Phonegap, titanium, etc) I have played with. I've looked at several; and none of them was able to stand up after messing with them for typically a half hour. I have tried to incorporate anything I found good in them; and leave out anything bad. Doesn't mean I'm perfect, but I am extremely proud of what I have managed to accomplish and how many different loop holes I have managed to find and block . :grinning:

Someone who understands actual assembly on the device; and has that low level of technical ability will be able to break it with what I hope will take a large amount of time. ;-)
However, each customer will get a unique encryption key which is generated using a large variety of algorithms, so even if the bad guy breaks application "a"; to get a decryption key; he would have to duplicate a lot of the work again for anther application.

However, since nothing is un-crackable, it can be broken. Anyone who claims their system is; is selling snake-oil.

But I hope with its ability to totally encrypt & minimize all your APP's JS and minimize the entire runtime system during a normal tns build/tns run; that this tool would be something that people want and need. ( Oh, and it can be set to only trigger on release builds; so that it doesn't slow down your debug builds :grin:)

[alejonext]

Well, not until it is helpful to point encryption code. Recall that were already open Java in the APK, and that has a fairly heavy configuration.

[NathanaelA]

@alejonext -- I'm not understanding what you are writing. I have this fully working on Android and now fully integrated with the nativescript build system. So when you build a app; it can automatically minimizes and/or encrypt your source code. It is now totally seamless. By seamless I really mean seamless; you just install, configure what you want it to do, and then you can forget about it. :grinning:

I'm just working on video, docs and a web site home for it, so it should officially be announced in the next couple days. (Its amazing how much behind the scenes work that goes into just launching a working product... )

[moll]

Has anyone reviewed its security, @NathanaelA?

[NathanaelA]

@moll,

Nope, finding someone else who is reasonably competent in NativeScript, the Android-Runtime, the v8 engine, and encryption is not a easy bill to fill. However, if you know someone who would be good at doing a in-depth look at this; I would really love for this to be done.

If you check my my github account you will see I am very familiar with the low levels of the the v8 engine, and of course with all my LiveEdit work I'm very familiar with the Android-Runtimes. I have also been following and practicing in the security scenes for years (you should see my RSS feeds).

I don't believe I missed anything, -- but I really would love to have a second or third opinion on this, since we are all human and I could have missed something and I am basing my reputation on how strong this is...

I will be releasing a sample fully encrypted app so that the community can pull it apart when I release the video and web site in the next day or so.

[valentinstoychev]

Hey @NathanaelA - I think these people have these rare combination of skills and can help you with the review of your security proposal:
@blagoev @stephenfeather @ligaz @atanasovg @TheBrousse @fealebenpae

[NathanaelA]

@valentinstoychev awesome. I was a little hesitant to ask the NS team to do it since they are already so busy with all the bugs and issues in github. But I'll check with them and see if any of them have some time they can spare.

[alejonext]

It sounds good about the "encryption code". And the problem of opening the APK is Java. However, I do not understand what the proposal, given that {N} and V8 engine is a code translator to C or Java.

• If you were to use minify, it browserify used?
• It will use eval?

What method to use?

[NathanaelA]

@alejonext - I actually make changes in both the V8 engine, and the Android Runtimes to do this. All of it is totally transparent to the rest of the engine (well other than attempting to debug a encrypted page (or any other methods to try and get access to the source), those don't work :grinning: ). I do actually have a optional minification step. But the goal of this product is that it actually encrypt all the JS files. I don't use browserfy, minify or eval to do the encryption or decryption. The code to do this on Android is all C and/or Java code scattered throughout the different pieces of the v8 & tns runtimes.

For those new to this issue; let me sum up what you may not know:
Right now if you send me your application Android .APK (or I can easily get from my phone in like 10 seconds after I download it from Google Play or the Amazon store) or the iPhone APP. I can pull out all your hard work in less than a minute. The JSON, XML, CSS and JS are all embedded in the application AS-IS (Please note this is also an issue with Titanium, PhoneGap, React, Cordova, so it isn't unique to NativeScript). I can then do TNS create newApp; copy all _your_ css, xml, js from your original app into my newApp/app folder; do a TNS run android --emulator and then have a fully working copy of your app on my computer and emulator for me to modify. Now if you think about this, that isn't really a good thing; especially if you spent months making your app just perfect, I come along steal the source make a small branding change in 5 minutes and then make the millions you were supposed to.

In a nutshell, what my product does; is encrypt your JS files using industry standard encryption, and the runtimes/v8 have the decryption code in them to decrypt any encrypted JS files in memory while your app is running.

Again, a very determined and knowledgeable hacker can break this, as NOTHING is impossible to break (just ask the XBOX & PS4 teams and they even controlled both the hardware and software). The objective here is to make it impossible for pretty much everyone else. :grinning:

[stephenfeather]

For accuracy, Titanium does NOT have your code sitting in plain text within the distribution targeted APK or IPA. How easy it is to get your Titanium code from its encrypted form to plain text is a different discussion, but to put Titanium's bundled code into the same category as PhoneGap/ReacctNative isn't correct.

[rborn]

:+1: @stephenfeather
@NathanaelA maybe you built for debugging/test and in this case the js is not encrypted.

But keep up the good work :smile: encryption is a key feature for {N} imho.

[NathanaelA]

@stephenfeather - That is really funny I almost put a * (astrick) and explained why I put titanium with them. and then I figured nah, wasn't worth the time since I kinda covered it earlier... But for everybody else; Titanium does have an encrypt step; but the security is so laughably bad it took me about 15 (Edit: looks like I exaggerated; I put 60 minutes in the messages above, so that is probably more accurate time. LOL, in my defense it was months ago I did my review of things...) minutes to break it (which includes the time to download and install everything) even though I had never touched titanium before. The encryption it has is absolutely worthless; which makes it worse in my book than no encryption as it gives the people a false sense of security. Now maybe I'm just good at breaking things; but I had honestly expected it to be a bit difficult and I found it trivial.

@rborn - The build step I add is activated automatically on a RELEASE build; not your DEBUG builds. The idea is I want you to be able to debug your code, so all debug builds are not touched. But once you build for RELEASE; your code is no longer debuggable. Please note; you can enable it to encrypt in debug mode; but it is more feature for testing then something I would imagine anyone would use.

[alejonext]

@NathanaelA Completely agree!!! Unable to find a solution that does not consume resources to mobile. But I believe that a solution is needed... The real problem is the code injection.

[NathanaelA]

Ok, for everybody subscribed to this issue; I have released NativeScript-Protect; Blog post for it:
http://fluentreports.com/blog/?p=159

@moll, in the effort to be TOTALLY transparent; I still have not had anyone review the code yet. I still have a request into several people on the NS team; I had a couple of them tell me they don't know the Android/V8 side so they can't review it; but are willing to review the iOS side when completed...

Two of the names listed that Valentin listed I don't recognize as doing anything in the NativeScript community and as such I'm not sure how they can really review it as their github profiles don't actually show any patches or issues submitted to either the Android runtimes or the v8 engines.

[maknz]

Some basic minification/concat would go a long ways.

[TheBrousse]

@NathanaelA I see that you are already selling the NativeScript-Protect product (not quite sure you can use the _NativeScript©_ trademark in your product name though).

Does this mean that you had the code peer reviewed?

[NathanaelA]

@TheBrousse - Nope, wish I could say otherwise. I plan on re-asking this week since; now the NS team is back from vacation I hope to have someone on the team review it(if they have time). I do have a someone slated to review the iOS version, already. However, on the Android side, it requires someone with v8, JNI and hopefully a little bit of encryption knowledge. :grinning:

As for the name; since you appear to be new to the NativeScript ecosystem; I'm using the standard plugin / install name; that pretty much every single plugin in the NativeScript sphere uses; nativescript- See npmjs and Telerik Plugins site. However, if they didn't want me using it; I'm sure they would email me; pretty much everyone on the NS team has access to multiple ways to contact me.

[TheBrousse]

So basically, what you are saying is, if no one from Telerik will review your code, no one from the community will validate it? Which should make any client nervous since you are not offering anyone to test here, you are selling a product. That would imply that. in order to test it, someone would have to fork money (without any guarantee it will work or not). And knowing that this product hasn't been tested or validated by the NativeScript community does not improve the "trust" situation.

Anyone is free to make and sell a product; but you said yourself (in all _transparency_) that no other developer reviewed the code.

One more thing:

since you appear to be new to the NativeScript ecosystem...

Don't talk about things you don't know.

[NathanaelA]

@TheBrousse, wow, not sure what I did to set you off. Take it a notch down.

I want someone to review it; and if you look above; I have been TOTALLY upfront that it has not been reviewed yet and that I want it reviewed. I even restated it when I announced its release in this issue; I totally disclosed this multiple times if you had been bothering to read. As someone who has invested a LOT into the NS community; my reputation means a lot to me... So I would advise you to take a little bit of your own advise and stop talking about things you don't know.

Now as to your "involvement" in NativeScript; Before I made that statement, I had actually checked pretty deeply into who you are. It is a pretty valid conclusion that you are not part of the NativeScript community. So I phrased it as such because I figured you must be unaware of the normal way we do things around here. I was not trying to criticize you; just stating that I figured you were unaware of how things worked... When @valentinstoychev mentioned you way up in this thread; I did a pretty decent review of who you were (and you appear to be fairly big in the Titanium world) to see if I thought you would be someone I could ask to review it. At that point I checked:

1. Your github account (No NativeScript repos, no NativeScript plugins, no Nativescript anything, no v8, no webkit, no encryption)
2. The NativeScript, NativeScript-Android, NativeScript-ios repos.
3. Your google+ account.
4. The Google Groups forums
5. The Google+ NativeScript group
6. The Facebook NativeScript group
7. General Googling
8. You twitter account (a couple NS tweets)

From everything I have seen, you have done nothing with NativeScript in any of those venues beyond a couple tweets; the conclusion is you aren't involved with NS in any material way appears to be pretty valid. So yes this is an informed guess; but since you appear to be not contributing to the community in any meaningful way that I can find, it seems like it is still the most logical conclusion. I don't have a problem being wrong; so I am open to you correcting my well researched guess with some facts that will show any work that you have done recently in the NS community.

[blagoev]

I see some of you need an adult supervision over here. "Calm you shell keep, Patience you must have"

@NathanaelA you can ask specifically someone from the community to review your code especially if you intent to sell it. This is in order to gain people trust and is common practice on all security related products. Or you can hire an agency specializing on that if you prefer. This of course is optional, anyone is free to make a product based on {N} and sell it in any way one chooses to.

@TheBrousse, @moll you could offer a code review on Nathanael's plugin.

To all: Lets be productive shall we
cheers

[NathanaelA]

@blagoev - Your right, I should show more patience, normally I have a pretty thick skin; guess we all have our off days. Sorry about that! Is their anything specific in my response you would like me to remove or reword?

As for reviewing it; I'm still hoping I can get someone from the NS team (You interested?) that knows v8/jni to review it. If that fails; then @moll actually is someone who appears from my research to have a good understanding of at least the security side of things; so he is on my community short list. I don't really want to just get the review checkmark because its a checkmark; I want the review to actually be meaningful so that any issues that aren't obvious to me; are pointed out so I can rectify them quickly.

[TheBrousse]

Alright I'm out. I don't need this.

[blagoev]

@NathanaelA If it was an OSS project I would have liked to take a look. In general it is best to ask an external party to do the security review to skip {N} team probably biased look on the matter.

@TheBrousse You did nothing wrong. Exactly the opposite. It was the reaction to your comment that provoked me to take a stance here. It is totally valid to ask for security review for a security product. My suggestion was for you to offer to do the review yourself if you were keen to do so. But that's only my way of looking how we can improve the situation.

I hope we all can stay on the positive side. A good community is when helping and supporting each other.

cheers,
blagoev

[NathanaelA]

@blagoev -- ah, now I understand your comment.

I hadn't realized you guys had done any POC's for this, nor were going to open source it, since back in June it was going to be commercial . This might make my solution a whole lot less commercially viable. Oh well, you win some and you lose some. The game continues. :grinning:

[rborn]

@NathanaelA
Tough times I guess :smile: , but why not try to join forces with the {N} team?
I mean you could open your code, or bring your knowledge to the official one that will be opened, and this will boost A LOT your community reputation.

Just an idea, don't start shooting :wink:

[NathanaelA]

@rborn - Nah, I try to only take one hostage a week. It was Christian's lucky week. ;-) As for opening my code; I'm not sure. Guess I really need to see what they did to see if their is still any market for this still; I put a huge amount of my time and money into this project; and unfortunately I have to pay bills also. I still have several open source plugins coming out; just have to wrap them up nicely.

@TheBrousse - In all reality; if you wouldn't mind emailing me a [email protected]; I never try to burn any bridges; so I would love to see if we can discuss and eliminate the issues and hard feelings and I don't really think github is the place to discuss it. I honestly was not trying to drive you away and would love to switch this to a friendship rather than adversarial.

[blagoev]

Thumbs up @NathanaelA. Now that's really good.

[vtjon]

Are there any updates on when this might get added to a milestone?

[NathanaelA]

For those who are interested; I did finally "officially" release this as a service; AppProtection.net the encryption works on both iOS and Android.

[jrz]

How about bytecode?

[NathanaelA]

I actually looked a bit into byte code; the biggest issue is that there are two engines in play; iOS uses JavaScriptCore and Android uses v8 engine. You would have to do a lot of work to precompile the code into two different byte systems.... This might be something I do in the future if AppProtection generates funding to pay for the R&D on it....

[AnthonySmith01]

+1 for a free solution on this issue.

[NathanaelA]

For those interested Telerik has finally released their open source implementation: https://github.com/NativeScript/nativescript-app-encryption -- please note this is a trivially broken experimental plugin, so I recommend you make your own customization to it before trusting it with anything.

[valentinstoychev]

@NathanaelA Thanks Nathanael - yes the plugin is in experimental state. The reason to make it open source and not closed source is exactly this - to enable people like you to suggest improvements and make PRs.

We also do not recommend using it in production apps just yet.

[valentinstoychev]

Moving the discussion here - https://github.com/NativeScript/nativescript-app-encryption

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.