OCXLY Digital Media House — Technology

The quiet return of the static web

Tue, 01 Sep 2026 00:00:00 GMT

For most of the web’s history, a page was a file. You asked for it, a server handed it over, and your browser drew it. Then, for a decade or so, publishing became a live performance: every visit assembled the page from a database, a template engine, a personalisation layer and a dozen third-party scripts, all in the few hundred milliseconds before a reader lost patience.

That model is quietly being unwound. Not by a new framework, but by a rediscovery of an old idea: build the page once, put the finished file on a network of servers close to readers, and only run code where something genuinely has to change per person.

Why it came back

Three pressures pushed publishers in the same direction.

Speed stopped being optional. Search engines now measure how quickly a page becomes usable, how stable its layout is and how fast it responds to a tap. A pre-built file served from a nearby cache wins those measurements almost by default. A page assembled on demand has to work hard to tie.

Attack surface became a board-level topic. A server that runs application code on every request is a server that can be exploited on every request. A static file has no login form to brute-force, no query to inject into and no session to hijack. The dynamic parts, such as a newsletter sign-up or a comment system, can be isolated into small services with narrow permissions.

Cost curves inverted. Serving files from a content delivery network is cheap enough that a traffic spike from a viral story is an inconvenience rather than an outage. Running enough application servers to survive the same spike is expensive, and the money is spent whether the spike arrives or not.

What “static” actually means now

The word is misleading. Modern static sites are not frozen. The content lives in a content management system, a Markdown repository or a headless database. A build step turns that content into HTML, images and feeds. A deployment step pushes the result to the edge. Editors keep their tools; readers get files.

Interactive features have not disappeared. They have been demoted to components. A search box can query an index that was generated at build time. A video player can load its heavy code only when someone presses play. A form can post to a tiny function that validates input and forwards it, without the rest of the site knowing the function exists.

The trade-offs are real

Static-first is not free. Builds take time, and a site with hundreds of thousands of pages has to be clever about rebuilding only what changed. Truly personal experiences, such as a logged-in dashboard, still need a server. Editors used to seeing a change appear instantly have to learn that “published” and “deployed” are separate steps that usually complete within a minute or two.

The honest summary is that static-first moves complexity rather than removing it. The complexity moves from the moment a reader arrives, where every millisecond and every vulnerability is expensive, to the moment an editor publishes, where a slow or failed build is annoying but harmless.

Why it matters for readers

A page that loads instantly, does not jump around and works when the network is poor is a page that respects the person reading it. A site that cannot be compromised by a request is a site that will not leak the reader’s data through a hole nobody noticed. Those are editorial values expressed as architecture.

This site is built the same way. The stories you are reading are files. The chrome around them is glass, but the words underneath are solid.

What "open source" actually promises, and what it doesn't

Thu, 27 Aug 2026 00:00:00 GMT

“Open source” is one of the most successful phrases in the history of software. It is also one of the most over-loaded. People use it to mean free, safe, community-run, transparent, ethical and permanent. The definition guarantees exactly one of those things, and only partly.

What the licence gives you

An open source licence is a legal instrument. It grants permission: to read the code, to run it for any purpose, to change it and to pass it on, sometimes with conditions attached. That is a large grant, and it is the reason the modern internet exists. Almost every server, phone and browser is built on code that anyone can inspect.

But a licence is not a service agreement. It does not say the code works. It does not say anyone will fix it if it breaks. Most licences say the opposite, in capital letters, in a paragraph that nobody reads.

What it does not give you

Maintenance. A project can be open and abandoned at the same time. Much of the software that critical systems depend on is maintained by one or two people in their spare time, and the fact that the code is public does not create a queue of volunteers to take over when they stop.

Security. “Many eyes make all bugs shallow” is an aspiration, not a law. Eyes have to be pointed at the code, and they have to belong to people who know what they are looking for. Serious vulnerabilities have lived for years in widely used open libraries because everyone assumed someone else was auditing them.

Governance. Who decides what gets merged? Who holds the publishing keys for the package registry? What happens when a maintainer’s account is compromised, or when a company that funds the project changes its mind? Open code can sit under closed decision-making, and the licence has nothing to say about it.

Permanence. Licences can change for future versions. Projects can be relicensed, forked, or simply left to rot. The code you downloaded stays open; the project you depended on may not.

The supply-chain framing

The most useful mental model for open source today is not “free software” but “supply chain”. Every dependency you add is a supplier. You are trusting their code, their build process, their account security and their judgement about their own dependencies, recursively.

That framing suggests the right questions. Who maintains this? When was it last updated? How are releases signed? Does the project have a security policy and a way to report problems privately? Does anyone actually read its changelog? None of these questions are answered by the licence file.

What good stewardship looks like

The healthiest projects have boring characteristics. More than one person can publish a release. Contributions are reviewed by someone other than the author. Dependencies are pinned and audited. Security reports have a private channel and a public disclosure timeline. Funding, where it exists, is visible.

None of that is glamorous, and none of it is required by the definition of open source. It is simply what it takes for the promise in the licence to mean something in practice.

The point

Open source is one of the great collaborative achievements of the last half-century. Treating it as a free resource that maintains itself is the fastest way to break it. The label tells you what you may do. The rest is your responsibility.

Passkeys, explained without the marketing

Wed, 19 Aug 2026 00:00:00 GMT

Passwords fail for a simple reason: the same secret is stored in two places, and one of them is a server you do not control. When that server leaks, the secret is gone. When a convincing fake site asks for it, people type it in. No amount of complexity rules fixes a design in which the secret has to be sent to be checked.

Passkeys change the design rather than the rules.

How they work, briefly

When you register a passkey with a site, your device creates a pair of mathematically linked keys. One half, the public key, is sent to the site and stored. The other half, the private key, never leaves your device. It sits in a secure area of the hardware and is unlocked by whatever you already use to unlock the device: a fingerprint, a face, a PIN.

When you sign in, the site sends a random challenge. Your device signs it with the private key. The site checks the signature with the public key it stored. Nothing secret crosses the network, so nothing secret can be intercepted, and a database breach yields a pile of public keys that are useless without their private halves.

The passkey is also bound to the site’s real address. A fake site with a similar name cannot ask your device for a signature that belongs to the real one. That single property removes the most common form of phishing.

Where the trust goes

Every security design moves trust somewhere. Passkeys move it from the website’s password database to three places.

Your device. If someone can unlock it, they can use your passkeys. Device security becomes account security in a much more direct way than before.

Your platform account. For passkeys to survive a lost phone, they have to be backed up and synchronised. That means the ecosystem you use, whether it is a phone maker, a browser vendor or a password manager, holds an encrypted copy. The encryption is strong, but the recovery process for that account is now the weakest link for everything protected by it.

Recovery processes. When a device is lost and the sync account is unavailable, what happens? Sites still need a recovery path, and recovery paths are where attackers go when the front door is locked. A site with excellent passkey support and a weak “forgot my device” flow has not improved much.

The practical questions

Can you move passkeys between ecosystems? Increasingly yes, but it is still less smooth than exporting a password list, and it depends on which vendors you use.

Should you keep a password as well? Many sites keep it as a fallback, which means the old weakness remains. The strongest position is passkeys plus a recovery method you actually understand, with the password removed once you trust the setup.

What about shared accounts? Passkeys are personal by design. Shared logins need a different answer, usually delegated access rather than shared secrets.

The honest verdict

Passkeys are the biggest practical improvement in everyday authentication in decades, and the criticisms of them are mostly about the surrounding systems rather than the cryptography. They remove the two failure modes that cause the most harm: reuse and phishing. What they add is a dependence on device and platform security that is worth understanding before you rely on it.

Use them. Understand your recovery path. Do not assume the marketing covers the second part.

Local AI is a hardware story

Wed, 12 Aug 2026 00:00:00 GMT

Every few months a demonstration circulates of a capable AI model running entirely on a laptop or phone: no cloud, no account, no data leaving the device. The demos are real. The explanation that usually accompanies them, that clever compression made the model small enough, is only half the story. The other half is the physical layout of the machine.

The bottleneck is not compute

When a language model generates text, it produces one token at a time, and for every token it has to read essentially all of its parameters. A model with several billion parameters, stored at a couple of bytes each, is several gigabytes of data that must stream past the processor for every word.

The processor is rarely the limit. Modern phone and laptop chips can multiply numbers far faster than they can fetch them. What decides the speed is memory bandwidth: how many gigabytes per second the memory system can deliver. Double the bandwidth and, for this kind of workload, you roughly double the words per second.

That is why the devices that run local models well share a specific design choice. They place memory very close to the processor, often in the same package, with a wide bus between them. It is also why devices with plenty of storage but modest memory bandwidth struggle regardless of how fast their chips are on paper.

Quantisation is a bandwidth trick

The compression techniques that make local models feasible, collectively called quantisation, work by storing each parameter in fewer bits. A model stored at four bits per parameter needs a quarter of the memory traffic of the same model at sixteen bits. The quality cost is real but often small, and the speed gain is roughly proportional to the reduction in bytes.

In other words, quantisation is a way of buying bandwidth you do not have. It is a software technique in service of a hardware constraint.

The dedicated accelerator question

Phone and laptop makers now ship dedicated neural processing units alongside the main processor and the graphics chip. Their advantage is efficiency: they can do the specific arithmetic that models need using far less energy, which matters when the battery is the budget. Their limitation is that they share the same memory system, so they hit the same bandwidth wall. A more efficient engine does not help if the fuel line is the constraint.

Where these accelerators shine is in the many small, continuous tasks that were previously too expensive to run all the time: transcription, image understanding, on-device search over your own files. The headline chat-with-a-model demos are the least representative use of them.

Why it matters beyond speed

Local inference changes who sees your data. A model running on your device can read your messages, photos and documents without any of it being uploaded. That is a meaningful privacy shift, and it also changes the economics: a feature that costs the vendor nothing per use is a feature they can ship to everyone by default.

It also changes what fails. A cloud model fails when the network or the company does. A local model fails when your device is too old, which pushes the upgrade cycle and raises a fairness question about who gets the good version of the software.

What to watch

Ignore parameter counts in marketing. Look for memory bandwidth figures, how much memory is actually available to applications and whether the vendor publishes which tasks run locally and which fall back to the cloud. The interesting progress in local AI over the next few years will be visible in chip layouts, not model names.