Computer systems, networks and security

Every interface sits on a machine and reaches across a network. Both facts shape what a person experiences. A tap that feels instant, a page that appears whole, a login that does not interrupt: each comes from machinery a designer usually never sees. Knowing that machinery changes what you can predict and what you can promise.

The memory hierarchy is the reason an interface can stall

A processor executes instructions far faster than it can fetch data from memory. The gap has widened for decades (Tanenbaum and Bos, 2023). The hardware answers with a hierarchy. Small, fast caches sit close to the processor. Below them sit larger and slower main memory, solid-state storage, and the network. Where the data sits matters more than how much arithmetic touches it.

Run the case yourself. Open a photo library you have used before, and the thumbnail grid appears whole. Restart the machine, and the grid fills in row by row. The code and the layout are identical. Only the level of the hierarchy changed. After a restart, the thumbnails are read from storage rather than found in memory. That illustration is constructed rather than drawn from a study.

Move the data the first screen needs to where it is cheap to read, and the first paint is quick. Defer the rest, and show progress when a wait is unavoidable rather than a still screen.

Processes, threads and the freeze you can reproduce

An operating system gives each running program a process (Tanenbaum and Bos, 2023). Inside a process, threads share the same memory and can run concurrently. A scheduler decides which thread runs next, and can only switch the processor between threads.

This mechanism explains the interface that freezes. Graphical interfaces usually run one main thread that both draws and handles input. When that thread is given long work, it cannot also repaint the window or handle a click. Reading a large file or awaiting a network reply counts as long work. The window stops updating. The freeze is not a rendering bug. It is a scheduling consequence.

One platform turns that consequence into a rule with a clock. An Android application draws and handles input on a single UI thread. When that thread fails to answer an input event within five seconds, the system raises an "Application Not Responding" error (Android Developers, 2026). The figure is platform policy, not a law of nature.

The fix follows from the mechanism. Long work goes to another thread, and the main thread keeps drawing. When the work finishes, the second thread hands the result back. Two threads sharing state can corrupt it, so the designer must decide what is shared and protect it. The useful question is not whether to use threads but which work can move off the main thread.

A request is a sum, and the sum can be budgeted

The network stack is layered, from the physical link upward to the application (Kurose and Ross, 2025). Each layer adds delay, and the total is what the person waits for. The delay splits into four parts: propagation, the time for a signal to travel the distance; transmission, the time to push a message onto a link; processing, the time each router spends on it; and queuing, the time spent waiting on a busy router (Kurose and Ross, 2025). Only propagation is fixed, because it is set by distance and the speed of light, and no faster processor removes it.

A latency budget turns that into a design. The rule of thumb comes from the first survey of terminal response times (Miller, 1968). A key press had to be answered within a tenth of a second. Delay beyond a second intruded on thought. Ten seconds broke sustained problem solving. Miller gave seventeen transaction types, so a budget must name the transaction. Take a round trip of fifty milliseconds. Four sequential trips have spent a fifth of a second before a server has done anything. A page that loads its script after its stylesheet pays the price in series. Spend fewer round trips, not faster ones.

That rule holds for small requests and fails for bulk transfer. A large download is limited by bandwidth rather than by trips. An extra megabit changes the download, and an extra round trip barely does (Kurose and Ross, 2025). Measure which term dominates before choosing.

What crosses the wire, and how caching avoids the crossing

HTTP is a stateless protocol whose messages carry self-describing headers, and its newest version, HTTP/3, runs over QUIC (Kurose and Ross, 2025). Because it is stateless, a server needs help to recognise a returning user, and cookies provide that help. Beneath HTTP, TLS negotiates encryption between client and server (Rescorla, 2018). It prevents eavesdropping and tampering in transit. The handshake costs extra round trips. Session resumption avoids those trips (Rescorla, 2018). Before any of that, the domain name must be resolved to an address by DNS. Each uncached lookup adds another round trip.

That handshake has grown. Chrome began adding a post-quantum key share to it in 2024, because traffic recorded today could be decrypted by a future quantum computer. The key share is over thirty times larger than the classical one, which split the first packet in two and added about four per cent to the median handshake time (Google, 2024). The gain is protection against a threat that has not arrived yet.

Caching is the designer's main lever against latency because it removes round trips entirely. A stored response that is still fresh can be reused without contacting the origin (Kurose and Ross, 2025), and a stale one can be validated with a conditional request. Caches sit at several places, from the browser to a shared intermediary to a content delivery network near the user. The case is a site logo that never changes: given a long lifetime and a version in its filename, it is fetched once and never again.

Compression and streaming apply the same logic to the bytes. Text and images are compressed so fewer bits cross the link (Kurose and Ross, 2025). Video is encoded at several rates and switched as conditions change, which is how playback continues on a poor connection. Design deliberately for slow, lossy and absent connections.

Identity is a design problem before it is a cryptographic one

Authentication answers a question with three classic factors: something you know, something you have, something you are (National Institute of Standards and Technology, 2025). The password is the first. People reuse secrets across services and choose guessable ones (Bonneau, Herley, van Oorschot and Stajano, 2012). Bonneau and colleagues rated thirty-five replacement schemes against twenty-five benefits. They found that none retained the full set that passwords already provide, and that passwords take full credit on deployability. The password survives not because it is good but because it is cheap to deploy.

That verdict is a judgement rather than a measurement, and its weakest joint has since moved. The current federal guidelines endorse the synced passkey, a private key that a person's devices share, so a login can rest on something held rather than remembered (National Institute of Standards and Technology, 2025). A scheme rated hard to deploy in 2012 may need no extra hardware now, so the ranking is an argument about that year, not a permanent verdict.

The guidance moved with the behavioural evidence, and it has moved again. The current revision requires at least fifteen characters where a password is the only factor, and eight where it is one part of multi-factor authentication (National Institute of Standards and Technology, 2025). It permits long passphrases, and requires each new secret to be checked against known-compromised values. It forbids arbitrary composition rules and forced periodic changes, which push users towards weaker and more predictable secrets, and states that a password is not phishing-resistant.

Multi-factor authentication adds a second factor, usually something held, so that a password alone is not enough (National Institute of Standards and Technology, 2025). Single sign-on moves the login to one provider and reduces the secrets a person manages (Bonneau, Herley, van Oorschot and Stajano, 2012), at the cost of trusting that provider with all of them. Biometric traits are not secrets, so the guidelines allow them only alongside a physical factor. Authentication is therefore a burden the designer chooses where to place, where the value at risk justifies it.

A threat model a designer can actually use

Security work begins with a threat model (Anderson, 2020). The model names who the opponent is, what they want, and what they will do. Anderson places the opponent before any cryptography. A curious teenager, a criminal organisation and a state agency are different problems. Naming the opponent stops a design defending everything equally and therefore nothing well.

Storing credentials shows why the mechanism matters. A service must keep passwords as a salted, deliberately slow hash (National Institute of Standards and Technology, 2025). A bare fast hash can be attacked by hashing candidate guesses and comparing them. The same password always produces the same value, so one precomputed table covers every account that used it. A salt gives each stored value a unique addition, so one table no longer fits the file. A slow function raises the cost of every guess. Skipping either is a recurring mistake.

The designer's most useful contribution is deciding what the user is asked to do about the threat. A confirmation dialogue, a warning page and a second prompt all request attention. The measure of a security interface is not whether the control exists but whether it is used correctly under pressure.

Secure defaults are settled, and who failed at the warning is not

The principles that govern this area are largely settled. Saltzer and Schroeder set out eight design principles (Saltzer and Schroeder, 1975). Among them is fail-safe defaults, which means the absence of an explicit decision denies rather than permits. Others are least privilege, separation of privilege, and psychological acceptability. The last requires the protection interface to be easy enough that people apply it correctly by habit.

When a user defeats a control, the question is what to do. When someone clicks past a certificate warning and is compromised, who failed? The field splits into two camps. The first treats the user as the weak link: the control was correct, the person careless, and more education closes the gap. The second treats the control as the weak link: the prompt demanded effort and returned little, so dismissing it was reasonable.

Herley made the case for the second camp (Herley, 2009). Security advice, he argues, offers to shield a user from the direct costs of an attack while loading them with indirect costs. The direct costs are usually small, so the bargain is often poor for the individual. He examined password rules, phishing-site identification and certificate warnings, and found that where benefit can be estimated the burden exceeded the losses prevented. That is economic reasoning rather than a controlled trial, which is its weakness: it models users as weighing costs and follows no one as far as harm.

The first camp has evidence of its own. Akhawe and Felt observed over twenty-five million browser security warnings using telemetry that Firefox and Chrome already collected (Akhawe and Felt, 2013). Users continued through only a tenth of Firefox's malware and phishing warnings and a quarter of Chrome's, so most did stop for the phish. The same study gives the other camp its number: users continued through 70.2 per cent of Chrome's secure-connection warnings. Neither study measures whether the users who proceeded came to harm, which is the measurement that will settle the dispute.

A designer cannot wait for that measurement. The rule that holds under either verdict is to stop resting a control on a decision the user has to win. Where the safe action can be made the default, make it the default and remove the prompt. Where the user must decide, for a permission or a payment, make the safe option easier to reverse and measure whether it moved behaviour. An unheeded prompt is evidence about the prompt.

What a designer takes from the machine

The machine and the network set the bounds for interaction design. A designer who knows them can predict the freeze, budget the latency, place the cache, and argue about a prompt with evidence rather than taste. A claim about a design is only as good as the measurement behind it. The natural next step is testing an interface against people, and stating honestly what the test can and cannot show.