Warblet

Open: start naked, harden as you learn

Open (formerly L0 Open) is one line of firmware:

POST http://http.warbletiot.com/ingest/sunny-otter-7c2f   ← your payload, nothing else

No token, no certificate, no clock sync, no TLS stack eating your MCU’s RAM. That is the plain-HTTP front door on port 80, and it is plain in both senses: anyone on the path can read what you send. This is the level where an idea gets proven or abandoned — and both outcomes should take an evening, not a month. A board that does have a TLS stack can post the identical request to https.warbletiot.com and be unreadable on the wire without leaving Open.

The Open starter is that line on a board, in MicroPython, Arduino or C: it sends a line of text every 10 seconds and says back whatever you type in its Message box.

What Open is for

At Open, your idea lives or dies faster than anyone could bother to hack it. That’s not bravado, it’s attack economics: an attacker needs discovery, motive, and time, and a bench prototype nobody has heard of, under an id nobody can guess, offers none of the three. You have a sensor, a hunch, and an hour — Open exists so the distance between “hunch” and “chart on a dashboard” is minutes, and the experiment is concluded before it was ever worth attacking. It’s also for gear you can’t reprogram, as long as it can post to a URL you choose. Gear that can only send a fixed frame to an address cannot join: the TCP and UDP doors need the CHIRP1 line first.

What can go wrong (we won’t pretend otherwise)

Anyone who knows your hardware id can send data as your device, and if they capture a payload they can replay it. Your first defenses are boring but real: a generated id like sunny-otter-7c2f is unguessable (a MAC address isn’t — vendor prefixes are public), and platform rate-limits blunt the firehose.

The hardening ladder — due diligence without leaving Open

This is the part nobody else offers: because you control the payload bytes and you write the decoder, you can add protection in user space and stay in your development cycle with confidence:

  1. 1Sign your payload yourself. Give the spec a secret, append hmac_sha256(secret, payload) on the device, and verify in your decoder — a forged or corrupted message never becomes decoded data, never reaches your routines, never touches your dashboard. (Your decoder has crypto.hmac_sha256 and meta["secret"] built in.) Add a timestamp inside the payload and reject stale ones: replay handled too.
  2. 2Bounce the spammers. If your script decides it’s being spammed, it can call block() — the offending source is blocked at the front door for an hour, before it costs you anything. (We block the sender’s address, not the hardware id — blocking the id would let an attacker lock out your real device on purpose.)
  3. 3Bind before first contact. Claim-code onboarding means your device’s very first packet lands already bound to your account — there’s no window where someone else can claim it.

That ladder is real security engineering, done in a scripting sandbox, on your schedule. It is also, deliberately, a working demonstration of why the higher levels exist: step 1 is Signed’s idea in user space.

When to leave Open

When the project stops being an experiment: it actuates something, other people rely on the data, or you’re shipping units to customers. Then move up: Token asks the device to store and send one token — and the browser flasher will write it to your fleet over USB. On HTTP the token rides in one header, X-Chirp-Token. A device that cannot set a header can put ?token= at the end of the URL instead, but the token then sits in logs along the way, and that device collects its commands with POST.