DEV Community: Alexander Mia

I Hid a Web Server on My Coworker's MacBook to Make It Talk. Eight Years Later, He Still Locks His Screen.

Alexander Mia — Thu, 14 May 2026 13:51:10 +0000

Around 2018, I sat across from a coworker — let's call him D — who had a habit of stepping away for lunch with his screen wide open. I told him about it. Twice. He laughed both times and forgot the next day.

So I taught him with twelve lines of Python.

The setup

macOS ships with a command-line utility called say. You pipe text to it, and your laptop talks. Or, more accurately, your laptop talks to everyone in the office.

The plan was simple:

Sneak onto D's laptop while he was at lunch.
Run a tiny HTTP server in the background.
From my own desk, send GET requests with words I wanted his laptop to shout across the room.
Wait.

The whole thing

from subprocess import check_output
from aiohttp import web


async def handle(request):
    name = request.match_info.get("name", "")
    text = name
    check_output(f"/usr/bin/say '{text}'", shell=True)
    return web.Response(text=text)


app = web.Application()
app.add_routes([web.get("/{name}", handle)])

web.run_app(app, port=6063)

Twelve lines. No auth. No rate limit. No input validation. (We will come back to that.)

I ran it on his MacBook over lunch — python server.py & — and walked back to my desk. Then I curled it from across the room:

curl http://<his-laptop>:6063/hello

His MacBook, sitting unattended on his desk, said "hello" in a soft computerized voice.

The whole team turned around. He was still eating his sandwich somewhere on the other side of the building.

The escalation

Over the next forty minutes I tested limits:

curl http://.../I-forgot-to-lock-my-screen
curl http://.../please-lock-your-laptop
curl http://.../this-is-what-happens-when-you-do-not

say handles dashes-as-words pretty well. The laptop announced its own delinquency to the entire team. People stopped working to listen.

When D came back, he stared at his laptop for ten seconds, said one word I will not repeat here, and lunged for the menu bar. The server kept running because I had backgrounded it with &. Closing the terminal did not stop it. He had to kill the PID. He learned about lsof -i :6063 that afternoon.

The actual security lesson

The trick is funny. The underlying flaw is not.

That 12-line server is what an unlocked MacBook looks like to anyone with thirty seconds of physical access:

They can run arbitrary shell commands. check_output(shell=True) on user-supplied input is a textbook command injection. In the prank version, I controlled both sides. In a real attack, the attacker controls both sides too — because they have your laptop.
They do not need your password. The Python interpreter is already there. Homebrew is already there. curl is already there. Your SSH keys are already there. Your browser's saved passwords are decryptable from a logged-in session.
The server survives a screen lock. Once it is running, locking your screen changes nothing. The process keeps listening. The attacker keeps having fun.
You will not notice it. A Python process on port 6063 does not show up in your Dock. It does not push a notification. The only sign is the port being open — and who checks lsof -i after lunch?

What I exposed with say, somebody else could exploit with rm, with a curl to a remote webhook that exfiltrates ~/.ssh/, or with a launchd plist that survives reboot and phones home forever. The 12 lines of Python are not the attack. Walking away from the keyboard is the attack.

What you should actually do

Set auto-lock. System Settings → Lock Screen → "Require password immediately after screen saver begins." Screen saver delay: one minute, not fifteen.
Use Hot Corners. Bottom-left = lock screen. Muscle memory in a week.
Enable FileVault. If someone walks off with your laptop, they get an encrypted brick. Without it, they get your home directory.
Ctrl+Cmd+Q. Built-in macOS lock shortcut. Use it every single time you stand up. Even for the coffee machine. Especially for the coffee machine.
Audit listening ports. Once in a while, lsof -i -P -n | grep LISTEN. You will be surprised what is running.

Why I am writing this in 2026

Because nothing has changed.

Eight years later I still see unlocked screens at every co-working space, every conference, every startup office I walk into. The defenses are better — Touch ID, Apple Watch unlock, FileVault is on by default — but none of them help if you walk away with the session active.

D locks his screen now. Every time. He has muscle memory for Ctrl+Cmd+Q that he did not have before that day. We do not work together anymore, but at conferences he closes his lid before he walks to the bar. Every. Time.

Sometimes the most effective security training is a laptop that announces your own negligence to a room of people you respect.

Twelve lines of Python. One coworker permanently reformed. Zero incidents since.

I Built a Dataclass in 25 Lines of Python. Then I Found Three Bugs.

Alexander Mia — Thu, 14 May 2026 03:59:10 +0000

Python's @dataclass is great, but it is a decorator. You sprinkle it on, you get __init__, __eq__, __hash__, __repr__ for free. Lovely.

But what if you wanted a function instead? Call it with kwargs, get back a class. No decorator, no class statement, no module-level boilerplate.

Here is one in 25 lines. And here are the three bugs I found while writing this article.

The result first

Klass = Klass(a=1, b=2)

# fields become defaults
Klass(a=3).a            # 3
Klass().a               # 1 (class-level default)

# equality by attribute dict
Klass(a=3) == Klass(a=3)   # True
Klass(a=2) == Klass(a=3)   # False

# hashable, usable as dict keys
Klass(a=4) in {Klass(a=5): 1}   # False
Klass() in {Klass(): 1}         # True

# strict validation
Klass(g=3)
# NameError: Unkown argument g=3

The whole implementation

def Klass(**fields):
    fields["__data__"] = list(fields.keys())

    class _(type("DataClass", (object,), fields)):
        def __init__(self, **class_kwargs):
            for k, val in class_kwargs.items():
                if k not in fields:
                    raise NameError("Unkown argument {}={}".format(k, val))
                setattr(self, k, val)

        def __str__(self):
            return "&data.{}({})".format(self.__class__.__name__, fields)

        __repr__ = __str__

        def __eq__(self, other):
            return self.__dict__ == other.__dict__

        def __hash__(self):
            return hash(tuple(fields[k] for k in fields["__data__"]))

    return _

That is the entire thing. No imports. No metaclass. No __init_subclass__ gymnastics.

What is happening

Three nested layers:

Klass is a function. You call it with kwargs and it returns a class.
Inside, type("DataClass", (object,), fields) builds a class on the fly whose class-level attributes are the kwargs you passed. This is the same type() you use every day, except with three arguments it acts as the class constructor.
Then we define an inner class _ that subclasses that fresh DataClass. The subclass adds __init__, __eq__, __hash__, and a custom __repr__. It returns _.

The closure over fields is doing the heavy lifting. Every method on _ can see the original kwargs because they are captured in the enclosing function's scope.

fields["__data__"] stores the original key order so __hash__ has a stable iteration. (This is a leftover from pre-3.7 days when dict order was not guaranteed. On modern Python you could drop it.)

The trick: defaults live on the class, overrides live on the instance

When you call Klass(a=3), __init__ only sets a on the instance. The other field b stays as a class attribute. So Klass(a=3).b resolves to 2 via normal attribute lookup, but Klass(a=3).__dict__ only contains {'a': 3}.

That is elegant — and it is also where the bugs hide.

Three bugs hiding in plain sight

Bug 1: `hash` ignores the instance

def __hash__(self):
    return hash(tuple(fields[k] for k in fields["__data__"]))

fields is the closure, not self.__dict__. Every instance of the same class returns the same hash.

hash(Klass(a=1)) == hash(Klass(a=999))   # True

Python lets you have hash collisions (the hash invariant only requires that equal objects have equal hashes, not the reverse). But it means a dict full of these instances degrades to O(n) — every key collides into the same bucket. Use it for ten objects, fine. Use it for ten thousand, your dict is a linked list.

Bug 2: `repr` lies

def __str__(self):
    return "&data.{}({})".format(self.__class__.__name__, fields)

It prints fields — the closure — not the instance state. So if you do x = Klass(a=99) and then print(x), you see a: 1, not a: 99. The repr lies about what the object actually contains.

Fix: format {**fields, **self.__dict__} instead.

Bug 3: `eq` only sees what `init` set

def __eq__(self, other):
    return self.__dict__ == other.__dict__

Klass() has an empty __dict__ because no kwargs were passed. Klass(a=1) has {'a': 1}. They should be equal — both objects have effective a == 1 — but they compare unequal because one has the attribute in its instance dict and the other inherits it from the class.

Klass = Klass(a=1, b=2)
Klass() == Klass(a=1, b=2)   # False — equal in spirit, unequal in __dict__

Fix: compare resolved attribute values, e.g. {k: getattr(self, k) for k in fields['__data__']}.

Why this is still interesting

The bugs are real, but the pattern is genuinely useful as a teaching tool. It demonstrates four things in one tiny example:

Classes are first-class values. A function can return a class. type() is just class spelled differently.
Closures over class definitions. The methods on _ close over fields from the enclosing function — no self.fields storage needed.
The class-vs-instance attribute split. Defaults on the class, overrides on the instance — the same trick Django models and many ORMs use.
Why @dataclass exists. Writing __eq__, __hash__, and __repr__ correctly is surprisingly easy to get wrong. The standard library does it once, properly. Your 25-line version does it wrong three different ways.

If you read the standard library's dataclasses.py, you will see it does essentially the same thing — generate __init__, __eq__, __hash__ — but with much more care about what __dict__ contains, when to freeze, when to compare by tuple instead of dict, and how to handle inheritance.

When to reach for this

Never in production. Use @dataclass or attrs.

But as an exercise? Read it. Type it out. Find the bugs yourself. That is how you learn what @dataclass is actually doing under the hood.

Twenty-five lines. Three bugs. One useful lesson about Python's object model.

I Built Rust-Style ADTs in 30 Lines of Python (Pattern Matching Works)

Alexander Mia — Tue, 12 May 2026 12:39:56 +0000

Sum types — also called tagged unions or algebraic data types — are the feature I miss most when I switch from Rust or Haskell back to Python. The match statement landed in 3.10, but the standard library still does not give you a clean way to declare a closed set of variants where each variant carries its own fields.

Here is a 30-line metaclass that fixes that.

The result first

class Computation(metaclass=EnumMeta):
    Nothing = Case()
    To = Case(target=int)
    List = Case(targets=list[int])


follower = Computation.List([1])


match follower:
    case Computation.To(target=p):
        print(p)
    case Computation.List(targets=p):
        print(p)
    case Computation.Nothing:
        print("nothing")

Three variants. Each variant is its own type. Pattern matching destructures fields by name. No Union, no isinstance chains, no boilerplate constructors.

The whole implementation

from dataclasses import make_dataclass, fields


class Case:
    def __init__(self, **attributes):
        self.dict = attributes


class EnumMeta(type):
    def __new__(cls, name, bases, clsdict):
        new_cls = super().__new__(cls, name, bases, clsdict)

        for field_name, value in clsdict.items():
            if not isinstance(value, Case):
                continue
            dc = make_dataclass(
                f"{name}.{field_name}",
                list(value.dict.items()),
                bases=(new_cls,),
            )
            dc.__match_args__ = tuple(f.name for f in fields(dc))
            setattr(new_cls, field_name, dc)

        return new_cls

What is happening

Case is a placeholder. It records the fields a variant will carry and nothing else. Case(target=int) means this variant has one field named target typed as int.

EnumMeta walks the class body when the class is constructed. For every Case it finds, it does four things.

Builds a dataclass for that variant with make_dataclass. The fields come straight from the Case kwargs.
Inherits from the parent class. bases=(new_cls,) means Computation.To is a subclass of Computation. This is what makes match Computation.To(...) work as a class pattern.
Sets __match_args__. This is the magic line. The match statement uses __match_args__ to know which positional fields to destructure. Dataclasses do not get this in the right shape by default for keyword-style patterns, so we set it explicitly from the field names.
Replaces the Case placeholder on the class with the new dataclass.

After EnumMeta runs, Computation.List is no longer a Case — it is a real dataclass type. Calling Computation.List([1]) constructs an instance with targets=[1].

Why this beats the alternatives

Enum cannot carry per-variant fields. You would end up smuggling data through value tuples and losing type information.

Union[A, B, C] of dataclasses works for pattern matching, but you have to declare each variant as a separate top-level class and then wire them into a union by hand. The variants live everywhere; the union is a comment.

Libraries like returns or pyrsistent give you sum types but pull in a dependency and an opinionated style.

The metaclass approach keeps variants grouped under the parent type, so Computation is a closed namespace. You read the class definition and you see every possible value the type can take. That is the property that makes ADTs useful: exhaustiveness in one place.

Caveats

This is not exhaustive checking at the type level. mypy does not know Computation is closed, so a missing case in your match will not be flagged. If you want that, add a case _: assert_never(x) arm at the end.

make_dataclass does not accept forward references the way a typed dataclass body does. Stick to concrete types in Case(...) or pass strings and let dataclasses resolve them.

The variants are subclasses of the parent. That is load-bearing for match, but it also means isinstance(x, Computation) returns True for any variant, which you usually want.

When to reach for this

When you have a small, closed set of states that each carry different data. Parser results. State machine transitions. Validation outcomes. Anywhere you would write a chain of isinstance checks today.

For two states or a state without data, just use a dataclass with an Optional. For four or more variants with distinct payloads, the metaclass earns its keep.

Thirty lines. No dependencies. Real pattern matching.

The Meta Security Layer: What Nobody Told You About Zero-Human Companies

Alexander Mia — Fri, 24 Apr 2026 16:27:34 +0000

I open-sourced a little thing called mesa. It's an orchestrator, paperclip alternative — you run it on your laptop, it spawns coding agents, babysits them, wires them up to your actual work. Local dev tool. That's the whole pitch.

Within a week, two strangers opened PRs to it. One of them shipped 62,000 lines of Shopify onboarding docs, finance-team agent definitions, and a marketing ops playbook, into a Go project that has nothing to do with any of that: mesa#28. Go look. It's still open.

Nobody got hacked. They were using mesa the way it's supposed to be used — running it locally, pointing agents at their own projects. The agents had push access (of course they did, that's how agents work). And somewhere between "do the work" and "commit the work," something pushed to msoedov/mesa instead of to their own fork. I don't even think they noticed right away.

Think about what that means for a second. A competent developer, on their own machine, using their own credentials, with their own CLAUDE.md, ended up publishing a private business playbook to a public repo they didn't own. Not because anyone attacked them. Because the stack got weird.

The meta security layer

This is the part I keep coming back to. I don't think we have a name for it yet, so I'll call it the meta security layer, which I realize sounds like a conference talk, sorry.

The idea is simple: we now stack models under agents under orchestrators under teams under companies. Each layer brings its own rules. And the rules do not compose.

A rule at the agent level — "don't run git push," stick it in CLAUDE.md — works great for the first five minutes on one laptop. Then somebody clones the repo, their CLAUDE.md doesn't have the rule. A subagent runs without inheriting parent instructions. An MCP server returns a tool description that quietly contradicts it. A persuasive issue body asks for "just one quick PR." A template overrides the memory file. A teammate runs the same orchestrator with their own credentials attached.

Instructions to a probabilistic system in markdown are not controls. They are vibes. Every time you add a layer — another agent, another teammate, another shared tool — the vibe gets a little more diluted and the blast radius gets a little bigger. Nobody did anything wrong. The thing just drifted.

Shared data is the other one

The other one I learned the hard way is shared data access. I used to think "my tools use my credentials" was fine. It was fine when the tool was a CLI I was typing into. It is not fine when the tool is an autonomous process reading untrusted inputs and deciding to make authenticated calls.

In mesa we ended up doing two things I wish I'd done on day one instead of week three. Every agent session gets its own scoped API key — not the user's key, not a shared key, its own. And the human-facing dashboard has a completely separate auth path — a dashboard login never touches an agent context, and an agent session can't suddenly act as the operator. If one agent goes sideways, the damage is that one session. Not the org, not the other work in flight, not the human's creds.

The reason this is hard to see before you get burned is that in the old world it was fine. One developer, one laptop, one key, one intention. Now "I" is a team, "my laptop" is a fleet of orchestrators, "my agent" is twelve agents in parallel, and "my intention" is whatever the agent decided about the issue it just read.

The supply chain is worse than you think

I'm not even going to do a real section on supply chain because I'd be here all day. But briefly: the classic supply chain is lockfiles, package registries, signed builds.

The agent supply chain is all of that, plus the model itself, plus the runtime, plus every MCP server anyone on the team installed, plus every skill and subagent definition someone imported from GitHub, plus every repo the agent reads, plus every issue body, plus every tool description the agent sees at runtime.

The agent follows instructions it encounters along the way. That's the feature. That's also the vulnerability.

There is no SBOM for that yet. I don't think there can be one, not in the shape we're used to.

Closing

I don't have a neat ending for this. I'm writing it because I watched two smart people accidentally leak their own work into my repo, and the uncomfortable part is that I can see how it happened and I'm not sure my own setup is much better.

If you're building in this space, the thing I'd tell 2025-me is: assume your rules will be bypassed, your keys will be reused somewhere you didn't expect, and your agent will one day open a PR you didn't ask for. Not because anything broke. Because the stack got weird.

Design for that day. It's closer than it looks.

DEV Community: Alexander Mia

I Hid a Web Server on My Coworker's MacBook to Make It Talk. Eight Years Later, He Still Locks His Screen.

The setup

The whole thing

The escalation

The actual security lesson

What you should actually do

Why I am writing this in 2026

I Built a Dataclass in 25 Lines of Python. Then I Found Three Bugs.

The result first

The whole implementation

What is happening

The trick: defaults live on the class, overrides live on the instance

Three bugs hiding in plain sight

Bug 1: __hash__ ignores the instance

Bug 2: __repr__ lies

Bug 3: __eq__ only sees what __init__ set

Why this is still interesting

When to reach for this

I Built Rust-Style ADTs in 30 Lines of Python (Pattern Matching Works)

The result first

The whole implementation

What is happening

Why this beats the alternatives

Caveats

When to reach for this

The Meta Security Layer: What Nobody Told You About Zero-Human Companies

The meta security layer

Shared data is the other one

The supply chain is worse than you think

Closing

Bug 1: `hash` ignores the instance

Bug 2: `repr` lies

Bug 3: `eq` only sees what `init` set