Information sensitivity is a problem that can bring your organization to its knees. What do you do when disaster strikes?

It's burning on the toilet

In Norway we say "Det brenner på dass", can be translated to "It's burning on the toilet". This is our way of saying that "shit has already hit the fan".
Private information, that is private keys, passwords and tokens, or other type of sensitive information can end up getting spread throughout your infrastructure, or worse, on the internet. This is a case of Det brenner på dass. A developer committed a password or token to the repository, or forgot to remove a logging sentence. Your application is now leaking critical information.
What do you do when disaster strikes? The only prevention is to have routines and an infrastructure that lets you detect these forms of breaches before anyone else.

I messed up in Git

Ok, so a password was committed to Git, what do you do now? Remove the line of code that had the password, push to the repository, grab a cup of coffee and pretend it did not happen?
This is not the way to do it. Git will store the password, and if not correctly removed, an attacker could find it by sifting through the Git-logs. There are two options, git filter-branch, that lets you rewrite Git revision, all the way down to the possibility of modifying each tree and each commit. The problem with this is that rewriting Git-history for a large project is time consuming, and the pitfalls are many.
The second option is BFG Repo-Cleaner. Those of you that has played Doom knows what BFG stands for, and it is exactly what this tool is, but it's simpler and faster to use for removing passwords, credentials or other private data from Git.

My logs are logging sensitive information

Removing sensitive information in the logs is often as simple as to purge the logs, and remove the code that is logging the information. But you will also need to check that information has not been backed up, or logged by another system monitoring the logs. Once this information spreads, it is almost impossible to remove it. Your best option is to revoke the password/token/private key, and this leads us to the next topic.

Stop messing up

You, or someone in your organization is bound to mess up, it will happen, and there is nothing you can do that will prevent it. What you can prevent is the consequences of it. What you should do, is to run automated scans that look for passwords, tokens and private keys in your infrastructure. And have implemented good routines for revocation and rotation of this information.

We are aware that some of this information is hard to look for. Find unique markers that make it easy to detect, or design your access information in a way that lets you search for it. We want to mention Docker Swarm's tokens, that are designed with a prefix with the intent of it being easy to search for.


Closely related to our post on containers and orchestrators, this talk that explains the tokens, and security in Docker Swarm is recommended.

Photo credit:
Blogtrepreneur Computer Data Hacker by Blogtrepreneur, under CC 2.0
Docker Inc. Secure Substrate: Least Privilege Container Deployment - Diogo Monica

When developers disclose information

Animations are awesome. Make sure they are as smooth as they can.

I love React Native. It might have its flaws, but it's the most fun I've had developing. This short write up is an introduction on how to make the most out of your animations with useNativeDriver. If you're already a somewhat seasoned React Native developer this probably won't be news to you.

Animation in React Native is usually fairly straightforward. This article is about the Animated API, which ships with React Native. There are some cool alternatives, like Reanimated from Expo, which extends Animated. And then there's Lottie, Pose and a bunch of other exciting things. But lets get back on topic.

How to use it?

As you might know, most of the stuff going on in React Native occurs on the JS thread. While this works well most of the time, it might get clogged by things going on in your app, resulting in it being unresponsive and/or slow. That's where useNativeDriver might come to the rescue. In short it tells the app to run said animation on the UI thread instead of the JS thread. In other words, it runs in the world of native, which offers higher performance and you don't have to worry about the JS thread being blocked by something else.

There are some limitations though. For instance, you can only use it while animating on non-layout properties. So transforms and opacity are fine, while position and flexbox properties aren't.

The only thing you need to do to actually put your animations on the UI thread is to pass useNativeDriver: true to your animation properties. Like so:

And that's it.

Unsure whether or not you have a problem?

Running animations on the JS thread can be perfectly fine. I tend to use useNativeDriver whenever I can, but you certainly don't have to. An easy way to determine if you might have a problem is to bring up the developer menu in your simulator. Just press CMD + D for iOS or CMD + M for Android. If running on an actual device just shake it like a somewhat fragile maracas.

If you got the developer menu showing, tap or click the Show perf monitor option you'll see this:

If you use your app now you might see the frames per second jumping up and down. If the JS thread keeps dropping frames you are most likely doing too heavy lifting here, something that useNativeDriver might help you to solve.

useNativeDriving with React Native

Yeah. I know! Me too. I was also shocked when hearing this for the first time.

I even remember my very first experience with JavaScript, where co-students, the Internet, and even the university taught me the following:

"As you have experience from the Java paradigm, one of the key differences between Java and JavaScript is that JavaScript is interpreted, and Java compiled."

However, not all people agree that JavaScript really is an interpreted programming language. Yes, we do not compile our JavaScript code before deploying like we do with Java (luckily for us). However, the browser is the magical wizard performing the last preparations of our code before finally ending up at the end users computers.

The definition

So, in order to know whether JavaScript is a compiled language or not, one ought to define what a compiled language really is. Some (not all) would argue that a compiled language is based upon the following three procedures:

Tokenizing/Lexing

Parsing

Code-Generation

Proponents of JavaScript as compiled language mainly stick with this explanation, where all these 3 compile steps are run by browsers nanoseconds before code execution.

The discussion

As with many other things, this is not, by any means, settled. Kind of like the following (non-exhausting) list:

Tabs or spaces?

Emacs or Vim?

Flow or Typescript?

Requesting Christmas stockings from your mom at the age of 27, or realize that you now need to become a grown-up? 🤔

But remember, the discussion is half the fun with JavaScript. I guess it's time to decide for yourselves - is JavaScript compiled or interpreted?

Read through the linked articles and discussions for inspiration, and let us know what you think!

21-Dec

Today's posts

When developers disclose information

useNativeDriving with React Native

The secret