Always Stay Online and Active on Slack with WebSocket Framejacking

Even though Slack is on a dedicated monitor beside you, if you’re not focused on it you’ll appear “away” and “not at your computer”. Do you subconsciously think team members are sleeping when they appear away at 10 am? Let’s always be active until we close the Slack tab or manually set ourselves as away. This is fair: Slack is open somewhere, so we are active.

Am I really away or offline when I’m in a different window?

By changing just four characters in Slack, we can always stay active without going inactive, even after hours and hours with a minimized browser.

Are There Existing Solutions?

Let’s see what kinds of solutions exist or we can think of before we analyze an extremely simple and effective solution.

One solution requires giving away your user name and password to an online service that pretends to be you just enough to convince Slack you are active. Who is to know how safe this is? This doesn’t work for Enterprise Slack that uses SSO authentication.

Another solution is to open Slack in the foreground on your phone and never let your phone sleep. You’ll need a phone and charger.

Yet another solution is to open the Slack desktop app and use a mouse jiggler to prove to Slack you are active and awake. You’d need hardware or some way to nudge your mouse now and then, plus the desktop app.

Others have even written Python, Java, NodeJS, etc. code to generate faux user activity via the Slack API with a personal API key. This seems like a neat idea, but the API changes now and then, and it is unclear how to how to change the user status. We like don’t have Enterprise Slack access to the API.

You might consider writing a self-refreshing iframe that just loads Slack over and over again. Slack sets the X-Frame-Options header to sameorigin, so Slack will not even load in an iframe. Good thinking, though.

Another interesting solution is to fire up a web-testing framework like Selenium to load a headless browser that “clicks” around Slack now and again. Some steps are needed to enter your credentials (and hope the UI doesn’t change and a Captcha doesn’t appear), plus the programming knowledge required is high. This likely doesn’t work with Enterprise Slack and SSO authentication.

Let’s Arrive at a Neat Solution Together

As a rewarding read, let’s arrive at this solution together by asking ourselves some questions.

Let’s open Chrome DevTools and watch the console, XHR network requests, and WebSocket frames.

We see that when the browser loses focus and then is made active again, some console messages appear, but there are no similar WebSocket messages.

Let’s try that. We can easily remove all blur event listeners using DevTools like so.

When we focus on another window or minimize the Slack window, no blur events fire. So far, so good. Now we wait for thirty minutes to see if we go inactive.

Some time goes by …

Darn. We went inactive. Let’s see what network requests took place.

There were no unusual XHR requests, but there are some interesting WebSocket frames.

Did you notice these messages are response frames? We’ve now learned the server told us that we went inactive, but no browser event effectuated it.

Let see if there are any interesting messages when we return to an inactive Slack window.

The server again told us we became active when we entered the browser window.

Let’s click around the Slack channels and type some messages and observe the WebSocket.

We see a common typing message when we initiate typing. We also see an uncommon tickle message occurring when the browser goes out of focus then back in focus followed by a click. These are the only two innocuous events to signal activity.

No. There is a sequential id in the sent message frames. We cannot replay one of these messages under a JavaScript setInterval(), for example.

We could be clever and try to keep track of the current sequence id, then replay a doctored activity message with an id++. We’d likely invalidate the next message with the genuine id, or even enter a race condition with an asynchronous invocation in the Slack web Service Worker.

Here is the logic used to keep track of the sequence ids if you are curious.

It’s unclear if the sequence id is synchronized across new WebSockets, or if the sequences are reset or otherwise independent. Besides, Slack can modify its implementation at any time, say to send even-numbered sequence ids instead. Let’s not be over-clever with the sequence ids and move forward on the assumption we cannot predict the sequence.

Let’s look at some background messages and see what candidates there are for framejacking (my term for hijacking a WebSocket frame). A WebSocket, being a stream, may have a message fitting in a single frame, which is the case for most Slack messages. Let’s look.

Ping! Every ten seconds or so a ping is sent to the server and a pong is received. A ping message has the same format as the tickle message.

Let’s see if we can spoof a tickle message by changing the four characters “ping” to “tickle” in framejacked ping messages every few minutes (more on that soon). Possibly simple and elegant.

Yes and no. Granted, it’s trivial to MITM WebSockets, known as intercepting, and make modifications. To save you a few hours, I’ll tell you that WebSockets close and open and are even killed over time, so effort needs to be invested to ensure we always framejack the correct socket.

No. I’ll save you yet more time. Over the day, many sockets may be instantiated so many setInterval timers would be pending, and stacked internal timers can behave poorly, especially if variable references go out of scope in the meantime.

A wiser implementation is to not use timers as all and make use of timestamps whereby each incoming message kicks off some elapsed-time check to initiate the faux activity.

Yes. WebSockets use a heartbeat protocol to know to keep the socket open on the server. Slack uses a ten-second ping-pong challenge with sequential messages, and the client-side JavaScript has a pong watchdog that will close the socket if one pong is missed.

Here, every ten seconds a check for a pong with the same id as the ping is performed. If a matching pong is not found within ninety seconds, the client closes the socket. There is more logic in the send() method involving a buffer, but one missing pong will hold up the check.

Let’s not interfere with the Slack JavaScript or try to hack private variables. Should we prevent the socket from being closed? Here is an experiment I ran by editing the cache of a Slack JavaScript file.

What happened is no more pings were sent after one ping was framejacked and then Slack just stopped working a short while later.

Instead, let’s intercept the ping, massage it into a tickle, and “receive” a well-crafted pong into the WebSocket layer so the client-side JavaScript is satisfied.

It’s trivial to spoof a pong from the DevTools console, but we shouldn’t be satisfied sending a simple JSON string as a pong, though; let’s really forge a trusted EventMessage with all the trappings and attributes of a real message received on the wire. This makes it future-proof as well.

To save you yet more time, one cannot just forge a trusted EventMessage object (a real message received by WebSocket) and modify it; some engineering needs to be done to tamper with a read-only event message to return a valid pong, such as making the data attribute writeable.

It’s okay to admit that forging a trusted message is exciting. What we’ve done is saved a reference to a real pong (which we cannot easily clone), and made the data attribute writeable.

Yes. Slack uses a Service Worker that runs in the background in its own thread outside the rendering thread. Web Service Workers are responsible for sending alerts, updating charts, syncing data, and more.

Here is a console log of the script functioning well while the browser is minimized and hidden.

The Slack: Always Stay Active Script

We only need Chrome (or Brave) with a popular¹ browser extension called Tampermonkey to inject some JavaScript just on Slack pages.

This started as a proof of concept but expanded to include visual feedback and integrity checks to indicate if Slack changed something pertinent to our workflow. You can even remotely stop the script on all your browsers on different machines. You can still set yourself away manually as well. The script is laid out so it is easy to follow and verify its safety. Enjoy.

Quick Start

A thin orange line appears while Slack boots, then it becomes green when active.

If it goes red, internal sanity checks have failed so Slack has changed something major. This is designed to be future-proof, but if Slack changes tickle to, say, caress or nudge, then that is a breaking change to which we can still adapt.

Advanced Features

Send yourself these messages to control the script across all of your open Slack windows.

1. sigkill! – close all your open Slack windows.
2. sighup! – refresh all your open Slack windows.

Console Commands

You can test out the script from the DevTools console with the following invocations:

1. slackasa.ticklenow() – Framejack the next pong to signal activity now.
2. slackasa.listsockets() – List all the open sockets and timestamps.
3. slackasa.reload() – Reload the page.

Installation Steps

Step 1. Add Tampermonkey to Chrome.

Step 2. Create a new empty userscript without saving.

Step 3. Copy and paste the script at the bottom of the page. Save. Close Tampermonkey.

Step 4. Visit Slack. Find the Tampermonkey icon, and enable Tempermonkey and the ‘Slack: Always Stay Active’ userscript. Reload Slack.

Discussion

This started out as a mental exercise in finding a way to keep Slack active. Personally, I’m on web Slack all the time with it open on several computers and my phone, so at least once every thirty minutes I cause activity.

However, sometimes I’m engrossed in my IDE for long stretches and even though Slack is on a dedicated monitor beside me, I look “away” and “not at my computer” – far from it. Does this happen to you too?

Full Script

This was written and developed in vanilla JavaScript in the Tampermonkey script editor in my spare time over the weekend. Encapsulation isn’t perfect as it’s not transpiled from TypeScript. The goal is to make it easy to read and understand. Why not publish this script? To require users to examine the code and verify it is safe as a habit. If you share this script, kindly attribute it. Thank you.

Copy script to clipboard