A few days ago I got an update from a Google Apps Script group that I subscribe to. The poster shared a jumble unreadable single-line mess of code with a message that read something similar to:

I hired a Google Apps Script developer and they shared me this. It works, but it is unreadable. What should I do?

It looked like the poster’s code has been deliberately obfuscated or obscured to make it difficult for someone to read. The code solves the problem for the client and runs as it should. It’s just near impossible to read or edit without seeing the original source code.

Picket lines were formed in the comments section of the post and salvos ensued. It wasn’t a Reddit-level skirmish, but it was getting there before it ran out of steam.

The post and the ensuing comments did raise some good points of view that are well worth considering as a freelance Google Apps Script developer or as someone who plans to hire a developer.

What’s going on?

In the above example, a developer has intentionally made their code difficult to read by humans. The above image is an example of obfuscated code that I generated from the code in this tutorial:

https://yagisanatode.com/2020/09/20/google-apps-script-3-google-sheets-custom-functions-to-allocate-items-from-a-column-and-spread-them-out-into-a-new-column-n-times/

It has 108 lines of code in its normal state. It is well commented on and documented. Among other things, the obfuscation removes comments and changed the variables to abstract names before smooshing them into one line. There is often a lot of other things going on as well, but that is the gist of the thing.

In the example, I’ve used the online tool JavaScript Obfuscator to create the image above. However, there are a lot of Node.js tools or online tools that will do this for you.

It’s not impossible to reverse engineer obfuscated code. There is some software available that can help with the process and if someone is patient and experienced enough, they probably could figure out the code eventually.

Before we go onto why a Google Apps Script freelance developer might do this, I think I should let you know that this topic…well…

It’s controversial!

This is the first time in my memory that I have written an opinion piece on this site that may elicit strong views. The aim is to help inform potential clients and stimulate Google Apps Script freelance developers to think about the consequences of this topic and keep both sides better informed.

The hope here is to improve client-dev communication and understanding.

I try not to dig my heels in on my beliefs if I am met will solid arguments that I have not considered. If you have a counterpoint to the chapters below or you think I have missed an argument completely please provide your perspective in the comments. If it is something insightful, even if it is contrary to my point of view I will add it to the post as a counterpoint.

Why might a developer do this?

Why might a Google Apps Script freelance developer obfuscate their code for the client?

There could be lots of reasons.

I’ve split this chapter into three sections based on, in my opinion, whether the developer’s reason might be:

• Well-intentioned.
• Well-intentioned but possibly misinformed.
• Not so well-intentioned.

I’ll provide some details on each point and why a dev might be deciding to take this approach.

If I get a good counterpoint in the comments I will add it as another point of view and give credit to the commenter.

Some good reasons

The client asked them to obfuscate the code.

If the client asked the dev to make the code difficult to read, then the dev’s fasted method to do this is to run the code through some obfuscation software.

In this case, the client should make sure that they also obtain a copy of the original code – perhaps in a separate file – and make that explicit in the agreement between the client and the dev.

When might you want to do this?

Web app HTML

If you are building a Google Apps Script web app and you have some awesome front-end code that you don’t want your competitors to simply copy and paste, then this might be an okay option for clients and dev.

The iframe nature of a Google Apps Script web app already makes it a little tricky to find the HTML code, but you can get at it after a few minutes of searching.

Take a look at the HTML dom tree to get access to the web app I created for this tutorial on building a chain story web app.

As you can see, it is quite a journey, but not impossible to find the web app HTML code. I hardly think my code here is a piece of original genius development and it was for a tutorial so, I didn’t even consider obfuscating it.

Just keep in mind that if you do decide to obfuscate your HTML here, that it can still be reverse engineered.

An alternative approach

A better approach, if possible, might be to leave some of the unique processes to be handled server-side in your Google Apps Script *.gs files.  They can’t be accessed by anyone but the people you share your project with. One downside to this approach may be a reduction in performance though.

What I have seen with a lot of web companies of late is that they have decided to forego obfuscation in their code. Jump onto Google, Twitter or Facebook and hit F12 and you will see what I mean.

Google Workspace-bound documents

Many Google Apps Script projects are bound to a Google Workspace documents like a Google Sheet, Doc, Form or Slide.

Probably the most common instance of this is when you want to automate part of a Google Sheet process with Google Apps Script. You can do this by going to Tools > Script Editor and start coding. This script is bound to the Google Sheet you are working on.

Anyone who has edit permission to your Google Sheet then has edit access to your Google Apps Script.

More often than not, your editors will leave your code alone or not even realise that the code editor doesn’t exist. However, if you have some savvy, ‘playful’ editors, you might find that they decide to ‘fix’ your code without letting you know. They may be more inclined to do this if they can somewhat easily read the code and believe they can edit it.

This might be a good case for obfuscation of your code. It may provide just enough disincentive for a curious editor to avoid editing your code.

Unfortunately, this does not absolutely stop an editor from editing your code.

An alternative approach

Three alternative approaches come to mind here.

1. Create your Google Apps Script independent of your Google Workspace Document. Then reference the document id to work on it. You can do this by going to script.google.com and creating a separate Apps Script project. This way your editors don’t have edit or even view access to your code. You won’t be able to do this with all scripts but you could do it with most.
2. Abstract the bulk of your code to a library that has view access. You can make a library in Google Apps Script pretty easily and then reference that library in your document bound project. The only thing that could be edited by people who have edit access to your doc is the connector script to the library.
3. Turn your script into an Add-on. This is one great reason to decide to upgrade to the paid versions of Google Workspace. You can create custom add-ons for your domain or business. Once your code is in an Add-on, it cannot be read or edited by users with edit permissions. It also gets rid of those nasty OAuth warnings (You’ll still have to approve scopes the first time though).

The dev-client relationship is a little uncertain

It can be risky working with someone you don’t know for the first time. You need to build rapport and trust with each other even if you have a Sofware Services Agreement or Contract. It is important to understand that it takes time and effort from both parties to build trust. As such you should not feel offended when either dev or client find ways to protect themselves from bad business exchanges as this trust is being developed.

Let’s take a look at a few scenarios.

Imagine you are on a freelance site like Upwork, Freelancer or Fiverr and you, as a client, have put out a job request for the first time. You have no ratings for the developer to see that you are the honest great person we know that you are.

Likewise, if you have has some bad initial experiences with devs and your rating is poor ( even if it was a misunderstanding or you have taken over your predecessor’s account) then a dev, quite rightly, may be suspicious of your intent and you will need to build trust with them.

Perhaps the client and the dev are in different countries and they have not worked together before. Quite often contracts and service agreements can be relatively worthless in these cases. You need to build trust with each other.

In these cases, the developer may send the client a working copy of the code for approval in the obfuscated format. So long as the code works as expected, then the client can approve the code, make the payment and the developer can then send on the original code.

Tips

It may seem like a difficult conversation, but it is much better to be upfront about doing this when you are agreeing on the parameters of the project. People are pretty understanding and if you get some hostility, then it may be a red flag and probably not a contract worth accepting.

Yagi’s opinion

One of the reasons why I keep my clientele within my country is that we both benefit from the trust that our mutual local law provides for us. If I had a new local client, I would rely on a strong Software Services Agreement and either start with a small project or portion of the larger project and then get paid and get a feel of how our business relationship is going and if we are both happy, move onto a larger project. This benefits both parties. In this case, I would forego obfuscation.

Well-intentioned but possibly unfounded reasons

Hiding Sensitive Data in Obfuscation

While it might sound like the best of a bad set of options to hide API keys and OAuth access tokens in obfuscated data, there are some much better options.

These tokens can be collected relatively easily. And you, as a dev, for example, might find yourself with a Google cloud bill that you weren’t expecting thanks to some nefarious person using your private keys for their own gain.

An alternative approach

As a dev, if you know that you have to expose some of your code to users like with Google Workspace bound Google Apps Script projects, a better alternative could be to abstract your external API connectors to a library and then hid your keys inside the Properties Service Script Property. Then share the library with view-only access.

Even if someone goes directly to your library via the file ID and makes a copy of it, the script properties are not copied along and cannot be seen.

The developer is using their own proprietary software

In this case, the developer may be adding some proprietary or patented code that they have developed before starting on the client’s project. They may also have purchased a licence for the proprietary code and are required to not share the code as part of their licencing agreement.

It can be a little tricky at times to import other software packages into a Google Apps Script so I understand the developer’s frustration here. However it is not impossible and again, it is important to remember that obfuscation can be reverse-engineered.

Note

If you are a dev who is using their own proprietary software in a project, then it is important that you inform and get approval from the client if you wish to obfuscate that part of the code. The client won’t be expecting this so it would be a professional courtesy to inform them.

An alternative approach

For the dev, there are a couple of alternative options here.

If you can store your proprietary data externally, then it is probably a safer option to run the portion of your code that is proprietary through a Restful API gateway that you could build. This way, the mechanics of your code is well hidden.

All you would need to do then is use the UrlFetchApp to access your API and call what you need inside Google Apps Script.

Even if your code relies on Google APIs in Apps Script you could modify your software to import any of the Google Apis into a Node.js project and create your Restful API.

If you absolutely need to put your proprietary data in Google Apps Script, you might be better off creating an Add-on for your client that you can manage from Google Cloud Console. If the client has a paid Google Workspace account you can have your Add-on available for admins only or you can set up a special access key for your client to use your app.

This would be something you would need to discuss with the client first.

Yagi’s opinion

Unless you really have the latest Einsteinian development in Google Apps Script software development on your hands that has been officially patented or is proprietary, I really don’t think obfuscation is necessary in this case.

If all you are doing is slapping together a few code snippets and packages you created in other projects, then it’s probably not that unique. A much better business model, I suggest, is to share the full code and earn some client trust so that they consider you for the next gig.

Attempt to speed up the code

A developer may feel that their code will run faster when the code is obfuscated. Yes, there is going to be some overhead when the script is going to be served when it has to parse, comments and spaces. However, with Google Apps Script’s modern V8 runtime there is probably going to be inconsequential.

In some cases when the script is larger, you may actually experience a slight slowing down and increase file size of your obfuscated code depending on the level of obfuscation.

Yagi’s opinion

Honestly, I just don’t think it is worth the hassle in this case. You are not going to get much performance bang for your buck. And the cost of having to store and work on your original code separately, re-obfuscate it and upload it to your Google Apps Script project seems too steep for me.

Not So well-intentioned

The dev had it in their Terms of Service

In this situation, the developer has stated in their Software Services Agreement or Contract with the client that the software that they produce will be intentionally obfuscated in order to protect their “intellectual property”.

The above is probably the most transparent form of documentation in an agreement. However, an agreement or contract may also have something like the following more obscure examples:

• The developer will take measures to protect the intellectual property of the service that they create for the client.
• The developer maintains the full rights to the code/intellectual property that runs the service provided to the client.
• The developer agrees to provide a solution to the client’s needs (this one is very vague and suggests that the solution is the only thing the client is paying for and not the code itself).

These are the few I could find. I’m not a lawyer and don’t play one on television. So I don’t know how legally viable any of these options are. Let me know if you have seen any more like this and I will add them.

Note

Whether developer or client has created the Software Services Agreement or Contract the other party really needs to read the contract – particularly with more litigious countries. It sucks, I know. Why can’t we just shake hands and get on with the job, right?

As a client, one thing you might want to make clear and in writing in your agreement with the developer is to ensure all code along with the service be human-readable, with clearly defined functions and comments. Further, the code should become your property along with the solution the code seeks to solve.

I agree a certain grey area exists with extensive proprietary libraries and APIs that you should mutually agree upon as they come up or even before the start of the project, if possible. I mean at the very least your dev will be using Google APIs and must follow Google’s quite generous terms. However, these do seem like rare occasions.

Yagi’s opinion

This point seemed to be the most contentious issue for developers. Here’s my take:

Personally, if I am developing a product for a client then they have full fair use to the code from which the solution was made. It should be well documented and clear. If the client needs someone else to update the code and I am not available or should they prefer someone else to update the code down the track it needs to be relatively easy for another dev to find out what is going on.

For smaller projects like many of the ones you see in my tutorials, I expect to be able to use part or all of the code in other projects and in educational material. Alternatively, the client is free to use the code how they wish. I do make sure the client is aware of this and have not had any pushback in the past.

In large projects, it is a good idea to discuss with the client if they wish to consider the project as a whole a piece of intellectual property owned by the client. I think this is important for the client to have particularly if they are planning to patent the product or make it a proprietary piece of software for their company. I would still ensure that I, as the dev, would be able to reproduce code snippets, classes, functions and methods for other projects and negotiate with the client where a reasonable line is drawn.

I also believe that the tacit understanding of the lay client is that they would expect to receive, at the very least, human-readable code for the development of their coding solution. I believe that it is intellectually dishonest to expect the client to have read and understood the Contract or Software Services Agreement regarding obfuscated end-product code.

I believe the practice of obfuscating freelancer code for client work is an anomaly. If a developer wishes to take this approach with a client, then they need to explicitly point to this item in their agreement or contract.

Overly untrustworthy

The developer may have been burnt by a bad dev experience before. Alternatively, they may have started to perceive signs from the client that they may not get paid in full or the work that they did would be used in other projects the developer may not have agreed to.

The developer may be upset with the client over something. Perhaps, the client has started to get aggressive about deadlines or simply suggested that they would like to add another dev to the team. Who knows.

It’s easy for both client and dev to get a little paranoid in remote work. It’s an all too common feeling.

Notes

The best thing to do if either party is feeling that the working relationship is breaking down or something seems off is to put it out in the open and communicate with each other. No, you don’t need to cast aspersions at one and another. You can be tactful. Even try some self-depreciation and say you were feeling a little worried and think that it’s probably not a thing but would the other party just put their mind at ease.

If you don’t see a way to repair the relationship, it is time to end the Agreement or Contract.

Yeah, these conversations are painful, but the end result is usually very positive.

Yagi’s opinion

This is why I like to work at an hourly rate on large projects or charge by stages. I also include in my contract that either party can end the agreement without penalty with reasonable notice and ensure all payments are made up to the current stage of work.

If you as a dev are not feeling good about the project. Don’t do it. Yeah, sometimes you have to pay the bills and take on dubious jobs but you also need to realise that you are taking a risk when you do it. If you haven’t agreed that it is okay to obfuscate your code in your final paid product then don’t.

They want you to come back to them only for changes

One quite dubious reason a developer may wish to obfuscate their code is that they want the repeat work to update the code exclusively. They may feel that they are minimising the competition in this case because they have the only copy of the original clean code.

Yagi’s opinion

I just don’t think this is a great way of doing business, creating a positive client-dev relationship and building a strong client base or repeat customers. It seems like a bit of a sucker punch to the client. Like their code is being held hostage.

I’d much rather get repeat work from clients who loved my work and wanted more of the same. If I didn’t have a great connection with a client, well, I can always say no to any new work in the future.

They want to sell you the clean code later

In this example, the dev may have set up an obscure Contract or Software Services Agreement that alludes to you getting a solution to the problem you are hiring the dev to solve but not necessarily their code.

When the final product is delivered to the client, they find that the code works, but it is an utterly jumbled mess.

The client then queries the dev about the obfuscated code and they might reply that they were hired to solve a problem, which they did, but not provide clear code. Didn’t the client read the contract?

The developer may then suggest that if they want the original code, then they are going to have to pay more.

Yagi’s opinion

This just seems like a hustler’s scam here. A bait and switch. If the developer was going to obfuscate the code, then they should have explicitly informed the client at the very beginning.

This is not what a typical client would expect and needs to be explicitly stated to the client and not just in the Agreement or Contract if that is the kind of approach the dev wants to take.

They are doing something with your data that you didn’t ask them to

In this case, the dev had provided working code but has also added some nefarious code into the mix. They are intentionally obfuscating the code to make it hard for you to see it.

What could they be doing?

Well, the developer could be mining your data and sending it to their server. If they still have ownership of the Google Apps Script project after they have completed the contract, they could even be able to delete or change files in your Google Workspace. There are a number of things they could be doing.

Fortunately, 99.9999% of the time you are not going to have a black-hat developer on your hand.

Note

As a client, keep an eye on the scopes, or permissions the project gives when you run the code for the first time. Often times they may seem broad but innocuous. If you do see something weird, it doesn’t hurt to ask the dev what it does. If they can’t give you a good answer, then that may be a red flag.

Further, to mitigate anything like this the client could ask the dev to provide the clean code as a say, *.js or *.txt file. If satisfied, the client could copy and paste the code yourself into a new Google Apps Script project.

I’ve worked with security-conscious first-time clients before and walked them through this process over a Google Meet call.

As a client, don’t be afraid to get a walkthrough of the code but also understand that you are paying for the time the dev is taking with you to do this.

Yagi’s opinion

I hate wrapping up on this last one. It makes you feel like the world is out to get you. In reality, most developers want to do an awesome job for you. They want to build a product that solves your problem and is something they can be proud of.

Keep in mind that any sort of business interaction has a similar pitfall in other industries. You have probably found that almost all people are trying to do right by you.

Why clear Apps Script code is good

Okay, so we have covered some of the reasons why a developer might obfuscate their code for a client. Now it’s time to talk briefly about why clear apps script code is good.

Explicit functions and variables

At the very minimum, functions and variable names should be explicit in their meaning. They should say what they are or doing in plain language.

A variable or function like this means nothing:

You want to be able to understand what the function or variable is or does.

Comment where necessary

If you are seeing something like the comments (/**...*/) in the example below above a function, you know you are in good hands.

These are JSdoc-based comments. Google uses them in their own Class and API products and encourages Google Apps Script developers to use them too in order to create clarity in their code.

In reality, not many developers use this level of commenting for their functions and classes for small projects. Only documentation-loving weirdos like me.

At the very least, expect to see some commenting (// comment) at the top of functions and classes like this:

You also might see some comments on how things work inside functions and classes that may be above or to the right of some code that are  produced with the double backslash (// a comment).

Documentation

On larger projects, then it is generally necessary to have an external document that details how the code works. This helps your current developer keep track of complex processes (especially when they are coming back to a project after a while).  It also makes it easier for new developers to add or modify the code in future.

Alternatively, if you have a project that will take a lot of user interactions, then tutorials and instructions will need to be developed for them to understand how to use the software.

On these larger projects, it is important for the client and developer to discuss the building of documentation and should be considered when quoting or budgeting for the project.

Conclusion

Well, that’s it from me.

I’ve no doubt missed some edge cases. So if you think I have missed something then please let me know in the comments. If it’s relevant I will add it to the post and attribute you. You’ll be famous!

Were there parts of this post that you agree or disagree with? I want to know and I think other readers would be interested in your opinion too. If you have a good argument I will add it to the post as a counterpoint.

Need help with Google Workspace development?

Go something to solve bigger than Chat GPT?

I can help you with all of your Google Workspace development needs, from custom app development to integrations and security. I have a proven track record of success in helping businesses of all sizes get the most out of Google Workspace.

Schedule a free consultation today to discuss your needs and get started or learn more about our services here.

~Yagi