The designers use Figma and Lovable. The engineers use Claude Code and Cursor. The team lead uses ChatGPT. Thats a lot of tools, each representing a siloed set of user data.

As models converge in capability, the differentiator is no longer the LLM. It is the quality of the user’s prompt and the relevance of the context they provide. The frontier labs are recognising that their models are becoming commodities and that their moat will be long term memory and context that they build up with their users.

Small teams can often maintain a mental map of the current context of their work. In a brand new startup the design team, engineering team, leadership team, are two people sitting next to each other at a desk. The state of the entire company resides within the two brains of its founders. With the passing of time and as the enterprise scales this becomes much harder. This institutional knowledge is transferred into a more permanent form in the shape of spreadsheets, databases, word documents, pdfs, email threads.

But there’s a disconnect between this vital context and the team’s AI tools.

Manually uploaded context becomes stale in each individual’s AI tool, valuable prompts are trapped in individual chat histories. Overloading the LLMs fails to work as they begin to suffer from “context rot.” As you flood a prompt with more data, the model’s ability to accurately recall specific information actually decreases.

Minnas is a tool that aims to fix this problem: https://minnas.io

Minnas is a central hub for a team’s prompts and context. It allows you to store, manage, and share your knowledge in one place.

Instead of copy-pasting context into every new window, Minnas provides a single source of truth. Your team stays aligned, and your AI outputs stay accurate.

I made a demo video below:

The two of us have spent the lion’s share of the summer in Stockholm working on various ideas, launching products, meeting founders and mapping out our future. Urgency is a word that’s often on the lips of those in the startup space. Everything is about high velocity, making quick decisions, failing fast. Those are great soundbites and a useful mentality in many environments, however sometimes you just need to take some time to really fucking think about things. No pressure, no deadlines, just thoughts. Before starting this journey I spoke to a successful founder I know — he runs a tech company in London with 200 employees. I asked him for some advice about my first steps as a founder. “Enjoy the summer” was his wry reply. Now, whilst I didn’t spend the last two months sipping mai tais through an umbrella straw, I made sure I enjoyed myself.

One discussion my cofounder and I have indulged in over the summer is choosing where to found our new enterprise. Armed with European passports and no real sense of loyalty to anywhere, this has been a much more difficult decision than I initially thought. Paul Graham’s 2008 essay “Cities and Ambition” came to mind whilst I compared the pros and cons of the various cities on our shortlist. Truthfully, the first time I read Graham’s essay I dismissed it as an utterly lame and cliché-filled analysis. He makes the unique and clever assessment that in Paris people like to be “stylish” and in London they want to be “aristocratic.” It gave the impression of a tourist who had watched Mary Poppins and eaten a croissant in front of the Eiffel Tower, suddenly feeling qualified to judge the ambitions of tens of millions of people. Yet look past the stereotyping and Graham manages to describe a real phenomenon we have all felt: the city you choose to live and work in matters. Its ambition is palpable. And Stockholm has that in spades.

There’s certainly a buzz in Stockholm that wasn’t present when I lived here a few years ago. A tight-knit community of founders and startups has emerged, and the city of less than two million is competing with much larger players. Dealroom ranked Stockholm as the third best startup hub in Europe, after Paris and London. So far in 2025 Sweden has produced more unicorns than any other EU country, and more than France and Germany put together.

One thing that struck me is how “un-Swedish” this new generation of startup feels. If you’ve spent any time in Stockholm during the summer you’ll be aware of the notorious summer shutdown that occurs. The words sommarstängt (closed for the summer) and på semester (on holiday) are plastered across shopfronts and auto-reply emails. Swedes are normally entitled to four weeks of continuous holiday from June to August, which they take. There’s a general understanding that during the summer if you want to get something done - whether its sales or hiring - you’re better off just waiting until September.

This relaxed approach is definitely not present in the new crop of founders. Slowing down for the summer is off the table and their approach to work seems much more akin to our friends across the pond than the traditional Swedish style. 60 or 70 hour work weeks. Lunch and dinner in the office. Often working weekends. Remote work is the exception. Dropping into to each others office for a face to face chat is the norm.

After all, if you’re building an AI startup, your competition in San Francisco, London or Beijing definitely aren’t taking the summer off.

It’ll be interesting to see where this generational divide takes the city’s tech scene in the next few years, and whether the old school approach will seep into the younger companies as they become more mature.

One rule remains even at hip startups like Lovable, take your shoes off when you enter the office!

1. their cost
2. their inherent latency
3. rate limited and unreliable APIs

Semantic caching is a tool at your disposal. The idea is simple: there are many different ways of asking a question to get the same answer. If you can understand the underlying meaning of a query, you can reuse a response to answer it. By mapping different prompts to existing responses you avoid making an unnecessary API call to your LLM provider, reducing your token usage and cutting the latency to almost zero.

I tested the use case of semantic caching by running an experiment using real world data - questions posed on the website Quora. I present an open-source tool for this called Semcache, which provides a caching layer between a client and an LLM API.

The dataset published by Quora contains actual questions posted on their website. For example “What is the most populous state in the USA?” and “Which state in the United States has the most people?”. Questions that are semantically equivalent, such as these, are marked as duplicates in the dataset. I like the use of this dataset because it is human and raw (have a look at some of the questions in there). They have spelling mistakes, incorrect grammar and many are generally idiosyncratic.

Summary of experiment

• Requests sent to a LLM API via Semcache
• Dataset: Quora Question Pairs - ~20,000 questions sent
• 28% cache hit rate (5,432/19,400 requests)
• 165x speed improvement (0.010s vs 1.648s average latency)
• LLM Model: claude-3-haiku-20240307

Setup

The experiment consists of three components: the client sending requests, the semantic caching proxy and the LLM API.

Semcache acts as a middleware layer between applications and LLM providers. It works as a drop-in HTTP proxy, which accepts requests from clients and forwards them to the LLM API. Semcache stores responses from the LLM API and returns them to the client. When a new request comes in it compares the embedding of the text to existing cached prompts. If the similarity is above the user set threshold it is considered a hit. The cache operates entirely in-memory and is cold at the start of the experiment - it is built up over time as requests are received.

We used Anthropic’s Python SDK to send the Quora questions and altered the base url to point to our Semcache instance:

self.client = AsyncAnthropic(
                api_key=os.getenv("ANTHROPIC_API_KEY"),
                base_url=semcache_host
              )

Semcache was deployed on an AWS t2.micro EC2 instance (running on the free tier) with the benchmark client operating on a separate EC2 instance within the same network. The system used cosine similarity for comparing vector embeddings, with the similarity threshold set to 0.9. For text embedding generation the implementation used the sentence-transformers/all-MiniLM-L6-v2 model. The client is calling Anthropic’s claude-3-haiku-20240307 model for answers to its questions.

Results

Out of 19,400 total requests the system achieved a cache hit rate of 28.0%, serving 5,432 requests from the cache. The performance difference between hits and misses was substantial: cached responses were served with an average latency of just 0.010 seconds, while cache misses required an average of 1.648 seconds to process.

Semcache’s memory footprint grew from 160MB to 201MB after caching 5,494 unique prompt-response pairs. This works out to approximately 7.5KB per cached entry. Each entry includes a 384-dimensional vector embedding of the prompt, the entire response from Anthropic, metadata (timestamp, access count). This means a server with 8GB of RAM could theoretically cache over 1 million prompt-response pairs.

Accuracy challenge

Unlike traditional exact-match caching, semantic caching operates in a fuzzy domain where “similarity” is subjective and context-dependent. In this experiment we observed questions that were considered a cache hit by Semcache but were labelled as “non-duplicates” in the Quora dataset. Defining what should or shouldn’t be considered a cache hit is heavily dependent on the use case of the data. For instance Quora labels the questions below as non-duplicates whilst our system marked them as semantically equivalent:

1. “What is pepperoni made of?”
2. “What is in pepperoni?”

Now to me as a layman, both of these questions about the contents of spicy Italian sausage seem interchangeable. However clearly there is a definition that Quora is following that means they are not semantically equivalent.

We did observe some false positives in our cache hits that are more questionable. Such as the below example:

1. “What is Elastic demand?”
2. “How do you measure elasticity of demand?”

The challenge here is aligning the caching system to your application by altering the semantic similarity threshold and the text embedding model. The choice of text embedding model has probably the greatest impact. The sentence-transformers/all-MiniLM-L6-v2 model used here provides a good general model for semantic understanding, but domain-specific models are more likely to yield accurate results.

In the real-world

Semantic caching offers several practical benefits that make it worth implementing in production LLM applications. The most obvious is cost reduction. Fewer tokens sent to LLM providers means lower bills, which matters when you’re processing thousands of queries daily. This becomes even more relevant if you’re using AI orchestration tools that charge based on compute time. When your cached responses return in milliseconds instead of seconds, you’re paying for less execution time.

Perhaps most strategically valuable is the knowledge layer that accumulates over time. Each cached response becomes part of an organisational memory that’s completely agnostic to any specific LLM provider. During our experiment, Anthropic experienced service disruptions that forced us to throttle requests significantly. Applications with robust semantic caching layers can maintain functionality by serving cached responses.

Final thoughts

In our setup in this experiment we ended up with a hit rate of 28%, but depending on the source of your prompts this number can be a lot higher. The text embedding model, the similarity threshold, how to host your semantic caching infrastructure are all decisions that need to take into consideration your specific use case. Semantic caching proves itself to be a powerful tool to reduce token usage and latency, but it is not free of complications.

If you’d like to test out Semcache for yourself you can find it on Github: https://github.com/sensoris/semcache

Interested in learning more?

We’re currently beta testing our cloud-hosted version of Semcache, designed to eliminate the technical complexities of managing semantic caching infrastructure yourself. Instead of being concerned with semantic similarity, embeddings and persisting challenges you focus on building your LLM applications and use Semcache to reduce token usage and latency. Join our waitlist at https://semcache.io/waitlist or reach out directly at louis@semcache.io to get early access.

Requirements:

A Linux machine that can run the perf command

TLDR:

1. Create a mix release of your application
2. Run it in daemon mode with JPperf enabled
3. Pass the application’s process id into perf and record some activity
4. Visualise the outputted data file with the Flamegraph scripts

Why use Perf?

You might ask: “why should we use the perf tool for profiling Elixir? The BEAM ecosystem has numerous built-in tools for profiling”. And you would be right. The issue with these tools is that they can significantly slow down the program they profile. This might be okay if you want to profile a specific small use case of your program, but in this guide we want to demonstrate a process that works with profiling a production level application.

1. Creating our web server

We’re going to use a Phoenix application as our example for profiling with perf. You can follow what we did step by step below or skip to the next section by simply cloning the server in its final form here.

First we want to initiate our no-thrills Phoenix server (get set up with Phoenix here).

mix phx.new slow_server --no-html --no-assets --no-ecto

Now we could stop here and profile this application, but that would be pretty boring. So instead we’re going to add two endpoints:

1. POST /api/fib → calculates and returns the nth Fibonacci number.

2. GET /api/desc → Will make a HTTP request of its own and return a description of Elixir.

Firstly, in order to make our HTTP request we are going to use the Req HTTP client library. So add {:req, "~> 0.3.0"} as a dependency in your mix.exs file and mix deps.get

After that we want to edit our router.ex file to include our new endpoints we are going to call:

defmodule SlowServerWeb.Router do
  use SlowServerWeb, :router

  pipeline :api do
    plug :accepts, ["json"]
  end

  scope "/api", SlowServerWeb do
    pipe_through :api

    get "/desc", ApiController, :desc
    post "/fib", ApiController, :fib
  end
end

Then we want to create our api_controller.ex file that will look something like this:

defmodule SlowServerWeb.ApiController do
  use SlowServerWeb, :controller

  def desc(conn, _params) do
    desc = Req.get!("https://api.github.com/repos/elixir-lang/elixir").body["description"]
    resp(conn, 200, desc)
  end

  def fib(conn, %{"n" => n}) do
    fib = SlowServer.Fibonacci.fib(n)
    resp(conn, 200, Integer.to_string(fib))
  end
end

We will leave it up to you to implement the Fibonacci function! Try running the server and making requests to the two new endpoints we’ve just created.

2. Getting production ready with mix release

As stated already, our goal is to profile our application as similar to its production state as possible. This way we can hopefully identify any issues that happen in the real world. In order to do that we will be using mix release. This assembles all of our code and the runtime into a single unit.

Firstly we need to run our mix release command with the environment set to production:

MIX_ENV=prod mix release

You should see instructions on how to run the built release. You may need to set a secret key to be used by Phoenix which you can set as such export SECRET_KEY_BASE=1234

Run our application with a command similar to the one below:

_build/prod/rel/slow_server/bin/slow_server start

Now lets test it by calling our endpoints:

➜  ~ curl http://localhost:4000/api/desc
Elixir is a dynamic, functional language \
for building scalable and maintainable applications%

➜  ~ curl -X POST -H "Content-Type: application/json" -d '{"n": 6}' \
http://localhost:4000/api/fib
8

Great! Now let’s actually profile our application.

3. Finally profiling

In order to profile our application we need to pass in a specific flag which enables support for perf: +JPperf true. We’re also going to run our release in daemon mode so that it runs in the background. In order to do this run the following:

ERL_FLAGS="+JPperf true" _build/prod/rel/slow_server/bin/slow_server daemon

Next we want to get the process id of our application to profile.

BEAM_PID=$(_build/prod/rel/slow_server/bin/slow_server pid)

Now we are going to do the actual profiling with perf! This will output a data file containing the stack traces of our running application once we exit.

perf record -F 10000 -g -a --pid $BEAM_PID

In another terminal call our endpoints with the above curls, then return to our running perf and exit with ctrl-c. You should see some output along the lines of the following and a perf.data output in the folder the command ran in.

^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.092 MB perf.data (964 samples) ]

4. Flamegraphs

Now we could stop here, we’ve officially profiled our application! But instead let’s visualise this to really see what’s going on. We’re going to clone the Flamegraph repo inside of the folder you’ve created your perf.data and then run these some commands to generate the graph.

git clone https://github.com/brendangregg/FlameGraph
mv perf.data FlameGraph/perf.data
cd FlameGraph
perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > flame.html

This will give use our lovely outputted Flamegraphs, which should look something like this.

Can you figure out what I set to n to from this Fibonacci flame graph?

Before diving into how WebAssembly’s specification was mechanised, it’s important to understand the backstory of the language and why it was devised.

If you’ve been a user of the web for longer than a few years you may remember the loading screen in the above image. Flash, Java Applets, Shockwave and others were technologies that allowed developers to embed applications with multimedia features into a website. This could be apps such as games, videos and other computationally intensive programs. These technologies were not part of the website’s technology stack of HTML, CSS and Javascript. Instead they were essentially a separate entity stuck onto the webpage. As a result there were often performance and security issues with these applets as they relied on users to install and update plugins which were owned and developed by third party companies. As the web became more mature and users’ requirements changed there was a shift away from these multimedia plugins. Steve Jobs famously slated Flash in 2010 when Apple decided not to support the plugin on the iPhone, saying:

“Letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform"

Jobs continued, stating:

“While Adobe’s Flash products are widely available, this does not mean they are open, since they are controlled entirely by Adobe and available only from Adobe. By almost any definition, Flash is a closed system."

Job’s ultimatum was the first nail in the coffin for web software such as Flash, with its demise finally coming in 2020 when Adobe officially stopping support the product. This is where WebAssembly comes in. After JavaScript it is the first language to be implemented across all major web browsers, and although it is very different it accomplished similar things to products such as Adobe Flash. WebAssembly has been developed by several top tech companies including Apple, Google and Microsoft, with the aim of enabling high-performance programs on web pages. Due to the fact WebAssembly is an open standard and a joint venture between several actors the language represents the shared interests of multiple stakeholders, both individuals and companies.

In this post I will provide a short overview of the mechanisation of WebAssembly since its announcement in 2015. The development of WebAssembly has been unique as multiple organisations have come together to define a collective open standard. This allows for an analysis of the language from the perspective of its formal methods.

Mechanisation can be considered the process of implementing a formal definition of a language using a mechanised theorem prover. WebAssembly is an ideal target for mechanisation due to the fact it is stable, not large and formally specified - unlike other more mainstream languages.

Technical details

WebAssembly is a binary instruction format for a stack-based virtual machine. It is designed as a target for compilation of higher-level languages like C and Rust, enabling deployment for web applications. Although designed for the web, the language can be theoretically used across any operating systems for any number of programs. The primary use case of WebAssembly is running inside of a web browser’s JavaScript virtual machine. The WebAssembly function that is called by the host environment exists within a sandbox environment, unable to directly access the host’s resources. As previously mentioned the language’s official specification includes formal semantics, which is normally reserved for academic work on programming languages and not a characteristic of industry projects. A goal of the language is that all undefined behaviour is eliminated and the specification precisely states the intended type soundness property - before a WebAssembly program is executed all programs undergo type checking validation.

A history of mechanisation

In this section I will describe the timeline of WebAssembly and how it has been mechanised over its short history.

The plan for the development of the WebAssembly project was first announced in 2015, with several browser vendors coordinating a public statement. The aim of the project was to replace JavaScript as the the assembly language of the Web. Brendan Eich, creator of JavaScript and founder of Mozilla stated on his blog:

“Yes, we are aiming to develop the Web’s polyglot-programming-language object-file format."

In its initial iteration WebAssembly was to be co-expressive with asm.js, a subset of JavaScript designed to behave like native code. Asm.js was the predecessor to WebAssembly and was Mozilla’s attempt at enabling programming languages such as C to run natively in the web browser. However in the long term WebAssembly was to diverge from JavaScript’s semantics in order "to best serve as common object-level format for multiple source-level programming languages". JavaScript was never intended to compile to low-level targets, and there were performance issues using the language for such a purpose.

In 2017 WebAssembly was moved to a minimum viable product status and the initial draft of the language’s semantics were released. This draft allowed researchers to mechanise the language according to its formal rules. The first mechanised formalisation of WebAssembly was conducted by Conrad Watt, a PhD researcher at Cambridge. Watt utilised the proof assistant Isabelle in order to mechanise the language’s specification. The W3C claimed that the language’s type system was sound, implying both type safety and memory safety with respect to the WebAssembly semantics. While conducting the proof of this claim, Watt discovered a few key errors which meant that the type system of the language were unsound. In the next section we will go into more detail on the specifics of the errors discovered in the specification.

At the Programming Language Design and Implementation conference in 2017 the language’s formal semantics were released, including details such as its typing rules, small step reduction rules and abstract syntax. The paper included suggested fixes by Watt to the errors he discovered, and he was mentioned by name in the paper’s "Acknowledgements" section. Later on in 2018 Watt officially published his mechanisation of the language, publicising his type soundness proof for the improved semantics.

In 2019 WebAssembly 1.0 was released (known as wasm 1.0). The W3C announced that WebAssembly was now an official web standard, and the language became the fourth "language" to run natively in the browser (alongside HTML, CSS and JavaScript). Wasm 1.0 had some slight refactoring done to it since its initial published 2017 version. The official specification contained a stronger statement of type soundness, however didn’t contain any proof, instead citing Watt’s earlier 2019 work as proof that its standard soundness theorems hold.

In 2021 a second paper is published by researchers matching this new official specification and to prove the stronger statement of type soundness. This time no errors were found in the language’s specifications and W3C’s claims were backed up. This paper contains two Wasm 1.0 mechanised specifications, which together prove type soundness and include an end-to-end verified interpreter. The paper’s objective was to replace Watt’s earlier 2018 work and become "the canonical source for the Wasm 1.0 type soundness proof".

Bugs in WebAssembly’s draft specification

Conrad Watt’s 2018 paper describes the bugs discovered in WebAssembly’s initial formal specification. These errors were related to the claim of type soundness in the language, and meant that the original specification’s type system was unsound. Here I will briefly describe two of Watt’s highlighted errors related to the type system.

Traps

WebAssembly contains traps as a core concept. Similar to software traps in classic assembly languages, a trap is issued by a program in order to immediately abort execution and transfer control to the host. When the trap value is generated in WebAssembly it propagates through the stack terminating all execution of functions, until it reaches the top of the stack and stops the program. However in the draft version of WebAssembly the trap value could become stuck during its reduction progression, meaning exceptions wouldn’t bubble up to the top of the program and would potentially be ignored.

Return

According to the specification, Result types classify the result of executing instructions or functions, which is a sequence of values. In its original iteration the specification defined a return type simply as a "break" operation, where the break procedure would be called for the number of nested labels within the current function call. According to this specification a return operation could occur outside of a function and still be considered well typed instead of being rejected.

Nothing left to prove

In April of 2022 the initial draft of WebAssembly 2.0 was released. The new specification contained a number of key changes, among which are significant alterations to the language’s definition and types. This includes the addition of three new types: number, vector and reference. A key update is the inclusion of reference types, as with this a WebAssembly program can handle references to complex host objects instead of being limited to integer and floating-point values. The goal with reference types is to potentially bring more complex features to WebAssembly such as garbage collection - which has been discussed as a potential addition since 2015. Despite these changes, this new 2.0 specification points to the same 2018 paper by Watt as proof of its soundness:

A machine-verified version of the formalisation and soundness proof is described in the following article”

Researchers such as Watt are working on new and updated mechanisations of WebAssembly 2.0, as stated in the 2021 paper

“we intend to keep our mechanisations abreast of these new features in WebAssembly changes”.

References

– “From asm.js to webassembly”, https://brendaneich.com/2015/06/from-asm-js-to-webassembly/, Brendan Eich, 2015, Jun

– “Steve Jobs slams adobe flash in open letter - and maybe kills it for mobile”, The Guardian, 2010, Apr

– “Adobe Flash Player End of life General Information Page”, Adobe, 2020, Dec

– “WebAssembly is now ready for browsers to use”, InfoWorld, 2017, March

– “WebAssembly Core Specification 1.0”, W3C, 2019, Dec

– “Mechanising and Verifying the WebAssembly Specification”, Watt Conrad, 2018, Association for Computing Machinery, https://doi.org/10.1145/3167082

– “Bringing the Web up to Speed with WebAssembly”, Haas, Andreas and Rossberg, Andreas and Schuff, Derek L. and Titzer, Ben L. and Holman, Michael and Gohman, Dan and Wagner, Luke and Zakai, Alon and Bastien, JF, 2017, Association for Computing Machinery, https://doi.org/10.1145/3062341.3062363

– “Two Mechanisations of WebAssembly 1.0”, Watt, Conrad and Rao, Xiaojia and Pichon-Pharabod, Jean and Bodin, Martin and Gardner, Philippa, https://doi.org/10.1007/978-3-030-90870-6_4

– “WebAssembly Core Specification 2.0”, W3C, 2022, May

– “WebAssembly Github”, https://github.com/WebAssembly/gc, W3C, 2022, May

In this “Hello World!” tutorial we will:

• Compile a C program to .wasm and run it on our browser
• Not use Emscripten
• Only use standard tools
• Write less than 100 lines of code in total, all from scratch!

Code

You can find all the code on my Github here.

Requirements

You’ll need to make sure you have:

• An up to date version of Clang (bundled with LLVM) which supports wasm32. You can check this by writing: llc -version and looking for wasm32
• Python
• A modern web browser

Getting started

Here I will run through how to get the program up and running.

C to wasm

Let’s first write our C file and save it as main.c, it will look as simple as this, where we are returning a pointer to memory containing our array of chars.

const char* getString() {
  return "Hello World!";
}

Next we want to compile our C program into a .wasm file. We use this Clang command to produce a main.wasm file.

clang --target=wasm32 -nostdlib -Wl,--no-entry -Wl,--export-all -o main.wasm main.c

Javascript and HTML “glue code”

Our HTML page will just load the Javascript script which actually fetches the .wasm file. We’ve also added an empty placeholder heading element. Save the following as index.html:

<!doctype html>

<html>
  <head>
    <meta charset="utf-8">
    <title>WebAssembly test!</title>
  </head>

  <body>
    <h1 id="heading"></h1>

    <script src="script.js"></script>
  </body>
</html>

Next we need to create our Javascript file, this is where things get a bit more complex. Due to us returning a memory pointer from our getString() function we need to actually go into the wasm program’s memory and fetch our char values. Then we need to convert it to char from the byte integer we store it as.

var importObject = { imports: { imported_func: arg => console.log(arg) } };

WebAssembly.instantiateStreaming(fetch('main.wasm'), importObject)
.then(obj => {
  var charArray = new Int8Array(
    obj.instance.exports.memory.buffer, // WASM's memory
    obj.instance.exports.getString(), // char's pointer
    12                                 // The string's length
  );

  let string = String.fromCharCode.apply(null, charArray) // Convert from ASCII code to char
  console.log(string);

  document.getElementById("heading").innerHTML = string // Set the value of the heading to our string
});

Running it

Now all we need to do is run the python server, save the code below as server.py:

import http.server
from http.server import HTTPServer, BaseHTTPRequestHandler

import socketserver

PORT = 8000

Handler = http.server.SimpleHTTPRequestHandler

Handler.extensions_map['.wasm'] = 'application/wasm'

print("Server starting at port:", PORT)

httpd = socketserver.TCPServer(("", PORT), Handler)
httpd.serve_forever()

Then run:

python server.py

And navigate to localhost:8000 on your modern browser. You should see “Hello world!”

Last week I demonstrated how to hack an Android to Sweden’s King, Queen and Crown Princess.

This was during a cyber security seminar at KTH for a selected audience of 80 people - comprised of royals, politicians, members of the military and heads of industry. During the event there were talks and panel discussions on the current state of Sweden’s cyber defence, as well as what the future may bring. Looming in the background, of course, is the brown bear in the room. Russia’s invasion of Ukraine has brought up fierce debate in Sweden over whether to join NATO, and whilst conflict in the Baltic may look ever slightly more likely now, an increase in cyber attacks originating from Russia is looking inevitable. Many of the speakers mentioned cases such as the Coop attack of 2021 which caused a majority of stores of one of Sweden’s largest supermarkets to completely shutdown. The origin of the attack was a Russian ransomware gang called REvil. Whilst the Russian government claims to not harbour cyber criminals and in fact has said has “dismantled” REvil, many groups like REvil don’t target Russian organisations. The broader question to ask is in the current political climate will Russian police hunt down cyber criminals residing in Russian purely to assist western investigations? I think we know the answer to that. Sweden may be particularly vulnerable to cyber attacks as it is one of, if not, the most digitalised societies in the world. By being effectively cashless and with a transition to tech and service industries in recent years there are many more vectors for attacks. On stage Micael Byden, the Swedish military’s Supreme Commander, stated that Sweden was well aware of these threats and had been working on improving its cyber defence. During his talk he even gave a shout out to a so-called “cyber soldier” graduate sitting right next to me in the audience as an example of the strides being made. I later spoke to the nameless cyber soldier (who was dressed very much like a real soldier) who told me around 30 people graduated from the program in his year. Most of them didn’t carry on to work for the military.

My part in this event was representing KTH’s Cyber Security Lab where I work part-time whilst doing my Master’s in Computer Science. Our department decided to demonstrate a few hacks, one of which being the ES File Explorer vulnerability. The ES File Explorer app was an Android app that brought rich file exploring features to Android devices and was hugely popular in the late 2010s, reaching over 500 million users. The vulnerability in the app is that as part of its local networking features it exposes a port on the user’s phone which essentially allows an external actor full access to the user’s file system. If you had the app open and were connected to a Wi-Fi network, anyone else on the network could have complete read and write access to your device in a matter of seconds. I walked through this with the Royals and alongside my fellow NSE employee Viktor we demonstrated how this hack worked. I took a selfie with the King and Princess and then we showed how that selfie can be stolen. As the Princess herself said, I should probably not give up the hacking to be a photographer.

See if you can spot me in this promo video for KTH Innovation. It’s the first modelling role I’ve taken in my career - I think I’ll stick with the day job.

Last Thursday we attended Demo Day, the finale of the year long pre-incubator program at KTH Innovation. At the event we exhibited our ideas along with the other start-ups in batch 12. I got to go on stage with my co-founder, Matay, and discuss Busybee in front of an audience of about 150 investors, fellow entrepreneurs and journalists. It was a great experience and a fun way to end the program at KTH Innovation, who have been a great help. Regardless of what happens with Busybee the things I’ve learned by attempting to build a tech company from the ground up will stay with me for the rest of my career. Below you can watch our demo day pitch.