Yet another new feature proposal for JavaScript that we'll live perfectly fine without (but would at the same time also be very handy).

Evaluate the following expression:

The answer is eighteen. How about that readability, huh?

Developers having used F#, Elixir, Elm (or a bunch of other languages) will be reaching for what's called "the pipeline operator" before you can say Santa Claus.

The pipeline operator allows for a much nicer syntax to the above code, where you start with the first input to the chain of functions, rather than the last function in the chain:

The pipeline operator simply swaps the order from fn3 fn2 fn1 object to object fn1 fn2 fn3.

If you're familiar with the unix pipe tool (of course you are), you already understand how this works.

Why do I care?

Because it's coming to JavaScript!

Well, maybe.

It's currently a TC39 feature proposal in stage 1, meaning it's still considered experimental and that the syntax might very well change before it ends up the language specification.

Functions With Multiple Arguments

This also plays well with multi-argument functions:

By using arrow functions, we can create new functions that make sure our piped values end up in the right place in the argument list for the next function of the pipeline.

This can be improved further by using another new language feature proposal: the partial application operator.

As seen in the example, the partial application operator enables ? as a placeholder for the value that will be passed from the previous step in the pipeline chain.

Under the hood, calling a function with ? will create a new function with the other arguments bound to their values.

Given a function add:

I want this, now!

Good!

There's been some concerns about this feature among those who govern the ECMAScript standard. As a result, several different variations of this feature has been discussed:



The original pipeline operator proposal



The "Smart Pipelines" proposal



The "F# Pipelines" proposal

As we understand, the committee is currently awaiting feedback from the community on experiences using these, before moving forward.

This basically means, that the next step of the process involves people like you and me actually using it in real projects and sharing our experiences.

What are you waiting for?

The Pipeline Operator

If your API has sensitive endpoints which returns different HTTP-responses given user action A or B, then this information is enough to infer user information which can be exploited. Learning from Tinder, let's investigate why having non-deterministic HTTP-responses are important and try to make our most business-critical API-endpoints more secure.

Many of us tend to think that if we just slap on end-to-end encryption with a SSL-/TLS-certificate and use HTTPS on our website, then that makes our website secure. It is true that this enables a secure encrypted connection between the client and the server so that no one can view the TCP-packet's data passing in between. It's a good security infrastructure to start off with, and Let's Encrypt will even give you this for free!

But what happens if you have an app that uses API-endpoints that undermine this encryption? An attacker can still infer sensitive user information by analyzing the size of the TCP-packets in the HTTP-responses.

Let's look at an example from Tinder and see why we should, in some cases, prevent deterministic HTTP-responses.

Got Love For Sale

First of all, Tinder weren't using HTTPS and obviously this opens up a lot of attack vectors and introduces vulnerabilities because anyone watching the traffic between the app and the server could view all of the contents being sent to and from the APIs! Watching traffic between users and servers is easier than you might think.

But let's assume that they had HTTPS. The primary features on the Tinder-app is the "Left swipe"/"Right swipe" feature, which is the same as saying "I don't like this person" or "I like this person". The ones you like might result in a match if the feeling is mutual.

C'mon And Love Me

These swipe-actions triggered API-calls that responded with different HTTP-response sizes, meaning if someone were watching the traffic they could infer that response sizes of x bytes is a left swipe, y bytes is a right swipe and a match is z bytes. An attacker could exploit this vulnerability by mapping actions and aggregating the different sizes of the HTTP-responses, perhaps for own gain to get more matches or to sell it to third parties.

Sure Know Something

We can mitigate the risk for this attack vector by making sure that the most sensitive API-endpoints we have use some kind of protective mechanism to ensure unique or equal byte sizes in the HTTP-responses, e.g.:

HTTP-response fuzzing: adding randomness to each HTTP-response results in unique HTTP-response sizes

HTTP-response padding: ensure that all of your sensitive API-endpoints return equal HTTP-response sizes

Use nonces between client and server: adding a unique one-time-use cryptographic token (nonce) per HTTP-response results in unique HTTP-response sizes, and a known secret that the client and server share per HTTP-request.

These techniques will make the API-responses less deterministic and inferring anything based on HTTP-responses alone will be much more difficult.

I Stole Your Love

Tinder and dating aside, this kind of security vulnerability has more serious implications on our private economy or demographic society when you use the same attack vector on APIs and apps for banking or even government voting...

Identify your most important API-endpoints that handles sensitive user actions and information, and ensure they are non-deterministic in their behavior!

Predictable HTTP-responses

I needed one for this site - follow along if you want one too!

Notice that hero image? It's 2 megabytes big. That's more than 6 times the rest of the bytes required for you to visit this site!

Now, images are nice, and quality photos are a big part of an amazing user experience, but that doesn't mean you have to download a few megs of images just to get a first impression!

It's day 12 (yeah, I really write most of these articles the day before), and I realized the load time on that first hero image was terrible. I'm going to fix that for this site throughout this article - and you can do the same for your site or app.

Started from the bottom

The first step of a great image loading component is to show a really compressed version of the image to start with, and then load the high quality version in the background. This way, it progressively improves the image quality!

Let's first look at a mega-simple Image component:

Now we up

In order to load a more high-res version of the image, we need to pass a high resolution URL, and load it once the low-res version has been displayed. Let's pass two props - src and highResSrc, and switch over to the high res version once it's loaded.

This way, we can upgrade our image significantly after the first load.

Is this the best we can do?

In 2019, we're going to see a lot of improvements to the React API. One of the most anticipated additions is what's known as Suspense.

With Suspense, we can specify a fallback component while we wait for some promise to resolve. Perhaps that promise could be an image loading?

Let's sketch this up as well:

As you can tell, this isn't stable or production ready yet, but it's probably similar to something we'll see in a React version not too far away.

You can play with a live example of the code above here.

By creating progressive image components like this, you'll improve your user experience on all mediums - whether it's slow mobile connections or fast desktop ones. There are, of course, tons of improvements left to do, but this seems like a great first start.

12-Dec

Today's posts

The Pipeline Operator

Predictable HTTP-responses

Creating a progressive image loader