I have JavaScript scripts in my application containing JavaScript and jQuery functions.
All user interaction with my application is dynamic and it's passing to the application through jQuery.
What I realized is, when I run my application, on the client side, the client can see my all source code by viewing page source (Ctrl + U).
How can I hide or do something so that user can't understand or read the source?
I want to do something like what Facebook does. By viewing Facebook source user can't reuse its source code or even understand it.
I googled and found that this process is called obfuscation, but this doesn't work for me.
I tried this:
http://www.javascriptobfuscator.com/default.aspx
and
http://dean.edwards.name/packer/
and
http://www.daftlogic.com/projects-online-javascript-obfuscator.htm
even i tried
http://www.jasob.com/
But it's of no use for me.
If someone really cares about your code he will take the workload of un-minifying (replacing random with useful variable/function names). Anything else such as "encrypting" or packing is just snake oil since it can be reverted extremely easy. So save yourself some work and rather spend it on making your application better.
So: The only thing you should do on a production system is minifying your JS code. This makes it smaller and thus faster to load - so it is an actually advantage. Besides that, it will make it less readable to people who are just curious for a quick look but don't want to spend time on it.
The facebook JS files for example are just minified by the way - most likely just for bandwidth/performance reasons.
The easiest way to minify your JavaScript is using Google's web service for it: http://closure-compiler.appspot.com/home
Note that it has an 1MB limit so if your JS is that huge, you might need to download the Java-based minifier to run it locally.
Everything ThiefMaster says is true. It's also worth noting that your apps should be designed with the assumption users can see and manipulate everything on the client. If you're worried about obfuscation because you think it will prevent users from seeing sensitive data or manipulating information such as prices, then you need to redesign your application so that secure logic resides on the server.
As I need to minify my javascript source code, I'm looking for a javascript program whose minify itself any javascript code.
Why a javascript minifier ?
Because, i'm writing some randomized javascript code from the web server to the client.
I should use "node.js" on the web server to execute a javascript program which generates a javascript code and minifying it on the fly and send it to the client.
This javascript program is a : encryption and decryption program. The javascript code result for the client should contains a javascript function which decrypt each portion of a json or hexadecimal version of an encrypted data. The function executes some plus, minus and multiplications of integers. Sometimes, I can generate a condition (if,then and else) to compute two different operations.
This function is used to decrypt two or more parameters inputs.
That's the randomized function : each time the client requests some private data, the web server generates two different javascript functions : one for encryption and one another for decryption. The decryption function is sent to the client. The encryption function is used by the web server to encrypt and send private data to the client. It's make a sense for obfuscation : each time the process is running, each time the sending function is totally different.
And, to convince the encryption/decryption is very secured, I add for the client, a tabular values conversion of two or more parameters ; but, the tabular values are generated, in fact, by a function written for the web server only and contains some numeric constants, which are NEVER send to the client. Thus, any one whose want to decrypt must have the constants value.
I'm explained that process because :
you are taken some things about obfuscation in javascript source code; but, obfuscation in javascript is not yet implemented by web server and browsers...maybe, it could happen...but, what kind of solutions is useful with the help of "SSL-ize" all transmission over the internet.
It's possible to crypt and decrypt with encryption/decryption functions which can be readable. And, without the cost of SSL certificates. Even, "a man in the middle" would decrypt the encrypted data ; for that, he just has to execute the javascript function. Ok..but imagine that the javascript decryption function is also encypted...then, the "man in the middle" has to execute the decryption function and then decrypt again the decrypted content which are javascript function to decrypt the encrypted data.
And, imagine if the web server asks a question to the client and the unique answer is handled by the client's result computation (whose not sent through Internet) ... it's impossible to "the man in the middle" to have the answer.
Check out my idea; i'm waiting for comments from any one.
Related
I am working on a React-based web app that uses Tensorflow.js to run an AI model in realtime on the client in the browser. I've trained this AI model from scratch and I'd like to protect it from being intercepted and used in other projects. Are there any protections available to do this (obfuscation, DRM, etc.)?
From a business perspective, I'd only like the model to work on my web app, nowhere else.
The discussions (1 2 3) I've been able to find on this are more geared toward native apps, not web apps.
Here is an example open source web app that uses Tensorflow.js. These weights are an example of what I would like to protect in my app.
Client-side code obfuscation will never fully prevent it. Use a server instead.
Obfuscation
If your client-side application contains the model, then the user will be able to somehow extract it. You can make it harder for the user, but it will always be possible. Some techniques to make it harder are:
Obfuscating your code: That way the user will not be able to read your code and comments easily. Depending on your build tools, this might already be done for you when you produce a "production ready" build.
Obfuscating the library and its public API: Even if your code is obfuscated, the user might still be able to guess what is going on by seeing the public API calls of the library. Example: It would be rather easy to set a break point at the model.predict function and debug your code from there on. By also obfuscating libraries and their API, this will become harder.
Put "special checks" in your code: You could also check if the page the code is running on is your page (e.g. if the domain matches), etc. You also want to obfuscate this code as well.
Even if your code is perfectly obfuscated and well protected, your client-side code still contains your model somewhere. With these methods it will always be possible to somehow extract your model.
Server-side approach
To make it impossible to get your model, you need a different approach. Only put your "dumb logic" on the client. Exclude the part of code that you want to protect. Instead you offer a API on your server that executes the "protected part" of your code.
This way, instead of running model.predict on the client-side, you would make an AJAX request to your backend (with the parameters) and then return the results. That way the user only sees the input and the output and cannot extract the model itself.
Keep in mind that this means a lot more work, as you not only have to write the code for your client-side application but also for your server-side application, including the API. Depending on how your application looks like (e.g.: does it have a login?), this might be a lot more code.
Another way you can protect your model is to split the model into more than one blocks. Put some blocks at server side and some at client side. This method may also introduce a lot of engineering work, but once you do that you can trade off the computation loading and network latency between the server and client. Users can only get some model blocks which is useless without cooperating with server side blocks.
I'm designing a game and have a somewhat unique problem.
To play the game, players each write a simple javascript program that continually makes a request of my backend for the game state and then decides what to do and posts their move (also to my backend).
I want to store the user scripts on my end though, so I've given them the option to upload their scripts with the standard HTML5 input type="file". Then I use FileReader to read in the raw binary, and associate that binary input as a "bot" for the user in Mongo. (My backend is written in Go)
Docs for FileReader:
https://developer.mozilla.org/en-US/docs/Web/API/FileReader
So far, I've found a resource for converting the binary back to ascii:
Converting Binary to text using javascript
I found a javascript interpreter that I can allegedly execute javascript from:
https://github.com/jterrace/js.js
In this situation, is there a better way to run the uploaded code, perhaps as an executable? Is a javascript sandbox solution like JSJS overkill?
It should always be a good idea to sandbox any user submitted code, regardless if it's executed on the client or server.
This is a question about the best way to structure an app that has both server-side and client-side needs. Forgive the length -- I am trying to be as clear as possible with my vague question.
For a standalone non-web-connected art project, I'm creating a simple browser-based app. It could best be compared to a showy semi-complicated calculator.
I want the app to take advantage of the browser presentation abilities and run in a single non-reloading page. While I have lots of experience writing server-side apps in perl, PHP, and Python, I am newer to client-side programming, and neophyte at JavaScript.
The app will be doing a fair bit of math, a fair bit of I/O control on the Raspberry Pi, and lots of display control.
My original thought (and comfort zone) was to write it in Python with some JS hooks, but I might need to rethink that. I'd prefer to separate the logic layer from the presentation layer, but given the whole thing happens on a single non reloading html page, it seems like JavaScript is my most reasonable choice.
I'll be running this on a Raspberry Pi and I need to access the GPIO ports for both input and output. I understand that JavaScript will not be able to do I/O directly, and so I need to turn to something that will be doing AJAX-ish type calls to receive and sent IO, something like nodejs or socket.io.
My principle question is this -- Is there a clear best practice in choosing between these two approaches:
Writing the main logic of the app in client-side JavaScript and using server-side scripting to do I/O, or
Writing the logic of the app in a server-side language such as Python with calls to client-side Javascript to manage the presentation layer?
Both approaches require an intermediary between the client-side and server-side scripting. What would be the simplest platform or library to do this that will serve without being either total overkill or totally overwhelming for a learner?
I have never developed for the Raspberry Pi or had to access GPIO ports. But I have developed stand-alone web apps that acted like showy semi-complicated calculators.
One rather direct approach for your consideration:
Create the app as a single page HTML5 stand-alone web app that uses AJAX to access the GPIO ports via Node.JS or Python. Some thoughts on this approach based on my experience:
jQuery is a wonderful tool for keeping DOM access and manipulation readable and manageable. It streamlines JavaScript for working with the HTML page elements.
Keep your state in the browser local storage - using JavaScript objects and JSON makes this process amazingly simple and powerful. (One line of code can write your whole global state object to the local storage as a JSON string.) Always transfer any persistent application state changes from local variables to local storage - and have a page init routine that pulls the local storage into local variables upon any browser refresh or system reboot. Test by constantly refreshing your app as part of your testing as you develop to make sure state is managed the way you desire. This trick will keep things stable as you progress.
Using AJAX via jQuery for any I/O is very readable and reliable. It's asynchronous approach also keeps the app responsive as you perform any I/O. Error trapping and time-out handling is also easily accomplished.
For a back end, if the platform supports it, do consider Node.JS. It looks like there is at least one module for your specific I/O needs: https://github.com/EnotionZ/GpiO
I have found node to be very well supported and very easy to get started with. Also, it will keep you using JavaScript on both the front and back ends. Where this becomes most powerful is when you rely on JavaScript object literals and JSON - the two become almost interchangeable and allow you to pass complicated data structures to/from the back end via a few (or even one!) single object variable.
You can also keep your options open now on where you want to execute your math functions - since you can execute the exact same JavaScript functions in the browser or in the node back end.
If you do go the route of JavaScript and an HTML5 approach - do invest time in using the browser "developer tools" that offer very powerful debugging tools and dashboards to see exactly what is going on. You can even browse all the local storage key/value pairs with ease. It's quite a nice development platform.
After some consideration, I see the following options for your situation:
Disable browser security and directly communicate with GPIO. No standard libaries?
Use a JavaScript server environment with GPIO access and AJAX. Complexity introduced by AJAX
Use the familiar Python and use an embedded web browser If libraries are around, easy
Don't add too much complexity if you're not familiar with the tooling and language
Oh what a nice question! I'm thinking of it right now. My approach is a little difference:
With old MVC fashion, you consider the V(iew) layer is the rendered HTML page with Javascript CSS and many other things, and M and C will run on the server. And one day, I met Mr.AngularJS, I realized: Wow, some basic things may change:
AngularJS considers the View ( or the thing I believed is view ) is not actually view. AngularJS gave me Controllers, Data resources and even View templates in that "View", in another word: Client side itself can be a real Application. So now my approach is:
Server do the "server job" like: read and write data , sends data to the client, receive data from client ect....
And client do the "client job": interact with user, do the logic processes of data BEFORE IT WAS SENT such as validation, or format the information collected from user ect...
Maybe you can re-think of your approach: Ask your self what logic should run at client, what should at server. Client with javascript do its I/O, Server with server-side script do its I/O. The server will provide the needed resource for client and javascript use that resources as M(odel) of it's MVC. Hope you understand, my bad English :D
Well... it sounds like you've mostly settled on:
Python Server. (Python must manage the GPIO.)
HTML/JavaScript client, to create a beautiful UI. (HTML must present the UI.)
That seems great!
You're just wondering how much work to do on each side of the client/server divide... should be functionally equivalent.
In short: Do most of the work in whichever language you are more productive in.
Other notes come to mind:
Writing the entire server as standalone python is pretty
straightforwad.
You don't have to , but it's nice and
self-contained if you serve the page content itself from it.
If you
keep most of the state on the server/python side, you can make the
whole app a little more robust against page reloads (even though I
know you mentioned, that should never happen).
I want to develop a game in NodeJS but i'm not sure how much 'easily' hackable it is. For example if i write my game rules in PHP modifing them will need the hacker to actually get access to the server, instead if my rules where in javascript anyone could easily rewrite the rules as they want.
More over if the game would involve people discovering rules as they play how could i prevent those rules to be there for anyone just by looking at the code.
The actual code of your Node.js app will remain unexposed. Ideally, your client (whatever you're doing on the browser side of things, whether this is rendering html elements or using html5 canvas) will only handle I/O and update your server, while your server will take care of all logic.
You can still use javascript client side, but keep in mind that your fear is legitimate concerning client side javascript. This is why it is common practice to separate input/output code (which happens in javascript on the client) from game logic code that happens on the server. So the worst thing someone would be able to do is to send a message to your server saying they are pressing every key at once, and you can filter for things like this.
Developing in nodejs means javascript on server. Javascript code on server which your players will not be able to see unless you open-source your game. This code won't be exposed to your players.
the same problem haunting me a month ago is still haunting me now. i know ive asked several questions regarding this on this site and i am truly sorry for that. your suggestions have all been excellent but the answer is still elusive. i now realize that this is a direct result of me not being able to phrase my question properly and for that i am sorry.
to give you guys a generalized view of things, here i go: the situation is like this, i have 2 server side scripts that i want to run.
a python program/script that continuously spouts some numbers
based on the output from that python script, a javascript script will perform some action on a webpage (e.g., change background color, display alert message, change some text)
ive studied the replies to my previous posts and have found that what i want to accomplish is more or less accomplished by json. it is my understanding that json transforms 'program-specific' variables into a format that is more 'standard or general or global'.
two different programs therefore now have the means to 'talk' with each other because they are now speaking the same 'language'.
the problem is then this, how do i actually facilitate their communication? what is the 'cellphone' between these server side scripts? do they even need one?
thank you!
If I understand what you're asking, the "cellphone" is TCP/IP. The javascript is not server-side; it runs on the client side, and alters what the client's browser displays based on json data that it downloads from the server -- data that in this case is generated by Python.
This question provides a relevant example, though it's a bit technical: JSON datetime between Python and JavaScript
Here's a very basic tutorial that explains how to create a dynamic webpage using python and javascript. It doesn't appear to use json, but it should familiarize you with the fundamentals. Once you understand what's there, using json to transport more complicated data should be fairly straightforward.
http://kooneiform.wordpress.com/2010/02/28/python-and-ajax-for-beginners-with-webpy-and-jquery/
I assume you mean: Python is on the web server, and Javascript is running in the client's web browser.
Because browsers are all different (IE6 is terrible, Chrome is great), there are a huge number of ways people found to "hack" this "cellphone" into place. These techniques are called AJAX and COMET techniques. There is no one "cellphone", but a whole bunch of them! Hopefully, you can find a library to select the right technique for the browser, and you just have to worry about the messages.
Comet is harder to do, but lets the server "push" messages to the client.
Ajax can be easier - you just periodically "pull" messages from the server.
Start with Ajax, then look at comet if you really need it. Just start by have the client (javascript) make a "GET" request, to see if the number has changed.
I don't know Javascript or json, but...
if you've ever seen an Unix-like operating system, you know about pipes. Like program1 | program2 | program3 ... Why don't you just connect Python and Javascript programs with pipes? The first one writes to stdout, and the next one reads from stdin.
This probably isn't the answer that you are looking for, and without links to your previous posts, I don't have much to go on, but nonetheless...
javascript is client side. I can interpret your question 2 different ways...
Your python script is running on your computer, and you want a script to actually alter your current browser window.
Not too sure, but writing a browser plugin may be the answer here.
Your python script is running on the server, and as a result of the script running, you want the display of your site to be changed for viewing persons.
In this case, you will could use ajax polling (or similar) on your site. Have your site be polling the server with ajax, call a server method that checks the output of the script (maybe written to a file?), and see if it has changed.
When 2 process need to communicate, they need to decide of a common/shared way to express things and a protocol to exchange those things.
In your case, since one of the processes is a browser, the protocol of choice is http. So the browser needs to do an http request or regular http request to your python process.
This python process Will need in Some way or another to be exposed via http.
There are several ways to build a web server in python. You should read this article : http://fragments.turtlemeat.com/pythonwebserver.php as a jumpstart.
Once you have this, your browser Will be able to issue HTTP GET requests to your server and your server can reply with a string.
This string can be whatever you like. Nevertheless if your answer contains structured data it can be a good start to use the XML notation or the json notation.
Json (stands for Javascript object notation) is very easy to use in javascript and this is why many people advised you to choose this notation.
I hope this will help you
Jérome wagner