Blog

  • Mesh Wi-Fi vs One Good Router: How to Actually Decide

    Mesh Wi-Fi vs One Good Router: How to Actually Decide

    Mesh Wi-Fi is marketed as the modern answer to bad coverage, and sometimes it is. Often, though, poor Wi-Fi is a placement problem, and adding nodes spreads a weak signal around rather than fixing it — while introducing complexity and, in the cheaper systems, cutting your throughput.

    The short version

    • Most home Wi-Fi problems are placement problems. Try that first; it is free.
    • A mesh node relays traffic. Without a dedicated backhaul band, that roughly halves throughput per hop.
    • Wired backhaul turns mesh from a compromise into a genuine upgrade.
    • Coverage and speed are different problems with different solutions.

    First, establish which problem you have

    ‘The Wi-Fi is bad’ covers several distinct faults with different fixes:

    • Dead zones. Fine in some rooms, unusable in others — a coverage problem.
    • Slow everywhere. Including next to the router — usually your internet connection, not your Wi-Fi.
    • Fine alone, bad when busy. A capacity problem; an older router struggling with many simultaneous devices.
    • Intermittent drops. Often interference or a failing device, not coverage at all.

    Only the first is a mesh problem. Buying a mesh system to fix the second will change nothing at all, which is a common and expensive disappointment.

    Placement, which is free

    Routers are routinely installed wherever the cable enters the building — frequently a corner, a cupboard, or behind a television. All three are close to the worst available options.

    1. Move it central and high. Signal radiates outward and slightly downward; a corner wastes half of it outside the building.
    2. Get it out of the cupboard. Doors, pipes and metal shelving attenuate signal considerably.
    3. Keep it away from microwaves and cordless phones, which interfere with the 2.4 GHz band.
    4. Do not hide it behind a screen or a mirror. Metal and metallic coatings block Wi-Fi effectively.

    A long ethernet cable to a better location costs very little and often outperforms a mesh system outright.

    A single router in the right place frequently beats three nodes compensating for the wrong one.

    How mesh actually works, and where the speed goes

    A mesh node receives traffic wirelessly and retransmits it. If it uses the same radio to talk to your devices and to the main router, it must alternate between the two — so throughput through that node is roughly halved. Add a second hop and it halves again.

    This is why cheap two-band mesh systems can deliver worse speeds than the single router they replaced, while showing a full signal indicator. The signal is strong; the available bandwidth is not.

    The two arrangements that avoid this

    • Dedicated backhaul. A separate radio band reserved for node-to-node traffic, so serving your devices does not compete with relaying. This is the feature that distinguishes a good mesh system.
    • Wired backhaul. Ethernet between nodes. No wireless relay at all, full speed at every node. If you can run cable, this is the correct answer and it makes even inexpensive systems perform well.

    When mesh is genuinely right

    • Large homes, or layouts spread over several floors.
    • Thick masonry, stone or reinforced concrete walls.
    • Buildings where the incoming line is fixed at an unhelpful location and cannot be moved.
    • Anywhere you can run ethernet between nodes — at which point it is simply the right architecture.

    When a single good router is right

    • Apartments and small to mid-sized homes with a workable central position.
    • When the router is more than a few years old — replacing it may fix capacity problems that no amount of coverage would.
    • When the actual complaint is internet speed, in which case the fix is with your provider.

    A sensible order of operations

    1. Test wired speed at the router and compare it to what you pay for. This separates internet problems from Wi-Fi problems.
    2. Reposition the router and re-test the weak rooms.
    3. If the router is old, replace that one device first.
    4. Only then add mesh nodes — and run ethernet to them if the building allows it.

    The same discipline applies here as anywhere else in buying hardware: identify the constraint before spending, a habit we set out in reading a laptop spec sheet.

    Frequently asked questions

    Will mesh increase my internet speed?

    No. Mesh distributes the connection you already have. If speeds are poor beside the router, the problem is upstream and no Wi-Fi equipment will change it.

    Are range extenders the same as mesh?

    Not quite. Classic extenders typically create a separate network name and require manual switching, and they halve throughput. Mesh systems present one network and hand devices between nodes automatically.

    How many nodes do I need?

    Fewer than most vendors suggest. Every additional wireless hop costs throughput, so add one, test properly, and only add another if a measured problem remains.

  • On-Device vs Cloud AI: The Tradeoff Nobody Explains

    On-Device vs Cloud AI: The Tradeoff Nobody Explains

    ‘AI features’ now appear on phones, laptops and cameras without specifying where the computation happens. That detail determines what the feature can do, what it costs you, whether it works without a signal, and who else sees your input.

    The short version

    • On-device: private, works offline, no marginal cost, sharply limited by memory and power.
    • Cloud: far more capable, needs a connection, costs the vendor money per request, and your input leaves the device.
    • Most shipping products are hybrid and rarely tell you which path a given request took.
    • The honest question is not which is better, but which one just ran.

    The constraint is memory, then power

    A model’s parameters have to fit in memory to run. A phone has a few gigabytes available to applications; a data-centre accelerator has far more, and many can be combined. That gap is the reason the largest models cannot run locally at all, regardless of how fast the phone’s processor is.

    Techniques such as quantisation — storing parameters at lower precision — shrink models substantially, with some loss of quality. They narrow the gap; they do not close it. The second constraint is energy: sustained inference drains a battery and generates heat, so phones throttle it.

    What each side is genuinely good at

    On-device wins

    • Privacy. Input never leaves the hardware, which is the only guarantee that does not depend on a policy document.
    • Latency. No network round trip. For live tasks — transcription, translation, camera effects — this is decisive.
    • Availability. Works on a plane, underground, abroad.
    • Cost. Zero marginal cost per request, which is why vendors prefer it wherever quality allows.

    Cloud wins

    • Capability. Larger models reason better, handle longer context and cover more languages and domains.
    • Freshness. Updated centrally and immediately, without waiting for device updates.
    • Uniformity. Everyone gets the same behaviour regardless of how old their hardware is.

    On-device is not a cheaper cloud. It is a different set of capabilities with a different failure mode — and the marketing rarely distinguishes them.

    Hybrid, and the transparency problem

    In practice most products route: simple requests run locally, harder ones go to a server. This is sensible engineering. It is also opaque, because the same interface handles both and the user is seldom told which path was taken.

    The consequence is that you cannot reason about privacy from the feature’s description alone. A summarisation feature that runs locally on a short note may silently send a long document to a server. Some vendors publish this routing behaviour; many do not.

    Questions worth asking of any AI feature

    1. Does it work in airplane mode? That is the cheapest test of where it runs.
    2. Does the documentation state when data leaves the device, and what happens to it?
    3. Is input retained, and is it used for training? Is there an opt-out, and is it on by default?
    4. Is there an enterprise or regional variant with different handling? If so, the consumer default is the weaker one.

    These are the same questions worth asking about the benchmark claims that accompany such features — see how to read an AI benchmark. They also connect to a broader architectural argument we make in local-first software.

    Where this is heading

    Device memory is growing, dedicated neural accelerators are now standard, and small models keep improving faster than most people expected. More work will move on-device, because it is cheaper for vendors as well as better for users.

    But the frontier moves too. The largest models will remain in data centres for the foreseeable future, so the split is not a transitional state — it is the steady state. The thing to insist on is not one or the other, but disclosure of which you are getting.

    Frequently asked questions

    How can I tell if a feature runs locally?

    Enable airplane mode and try it. If it works, it ran on the device. If it fails or degrades, some or all of it was remote.

    Does on-device AI drain the battery?

    Sustained inference is demanding, yes. Short, occasional tasks are negligible; continuous processing such as live video effects is not, which is why devices limit how long such features run.

    Is on-device automatically private?

    The computation is. Whether the application also uploads the input, the output or telemetry is a separate decision, and only the privacy documentation or a network trace will tell you.

  • Local-First Software: Why Your Apps Keep Breaking Offline

    Local-First Software: Why Your Apps Keep Breaking Offline

    Open a note-taking app in a tunnel and watch what happens. Some show you your notes instantly and sync later. Others show a spinner, then an error, then nothing — despite the fact that your notes are a few kilobytes of text that could trivially have been stored on the device you are holding.

    The short version

    • Cloud-first apps treat the server as the truth and your device as a viewport. No network, no application.
    • Local-first treats your device as authoritative and sync as a background process.
    • The hard part is merging concurrent edits, which is why most products avoid it.
    • The real argument is longevity: your data outlives the company.

    Two different assumptions about where truth lives

    In a cloud-first design, the server holds the authoritative copy. Your client fetches a view of it and sends changes back. This is straightforward to build and reason about, and it fails completely the moment the network does — because the client was never holding anything real.

    In a local-first design, the authoritative copy is on your device. Writes go to local storage immediately and the interface updates without a round trip. Synchronisation happens in the background, and other devices converge when they can reach each other.

    The difference is not a caching strategy. It is a decision about who owns the truth — and it determines whether the application still exists when the network does not.

    What local-first buys you

    • Immediate response. No spinner between your keystroke and the result, because nothing crosses a network to render your own edit.
    • Genuine offline use. On a plane, in a basement, on a bad connection, the application behaves normally.
    • Ownership. Your data is on your disk in a form you can copy, back up and inspect.
    • Survivability. If the company shuts down, a local-first application degrades to a local one. A cloud-first application becomes an icon that opens an error.

    That last point is the strongest argument and the least discussed. Services are discontinued routinely. The question of what remains afterwards is an architectural decision made years earlier.

    Why it is genuinely hard

    The difficulty is not storing data locally — that part is easy. The difficulty is what happens when two devices edit the same thing while unable to see each other, and both edits are legitimate.

    Cloud-first systems dodge this by serialising every change through one server. Remove that and you need a merge strategy that produces a sensible result without asking the user to arbitrate.

    Approaches to merging

    • Last-writer-wins. Simple, and silently discards work. Acceptable for a toggle, unacceptable for a document.
    • Operational transformation. Transforms concurrent operations so they compose correctly. Powerful, and notoriously difficult to implement correctly.
    • CRDTs. Data structures designed so concurrent edits merge deterministically regardless of arrival order. Increasingly the practical choice, at the cost of extra metadata and memory.

    None of these removes the need for judgement. A merge can be mathematically correct and semantically wrong — two people editing the same sentence in different directions produces a valid document that says something neither intended.

    The commercial reason it stays rare

    A subscription is easier to justify when the product stops working without it. Software that keeps functioning on your own machine has a weaker recurring-revenue story, and it complicates analytics, feature gating and server-side enforcement.

    This is not a conspiracy; it is an incentive gradient. It does mean the architecture question is rarely decided on engineering grounds alone.

    What to look for as a user

    1. Turn on airplane mode and open the app. What still works?
    2. Can you export everything in an open format, without a support request?
    3. Where does the data physically live, and can you back it up yourself?
    4. If the company disappeared tomorrow, what would you still have?

    You will not always choose local-first, and you should not always want to — collaboration, search across large corpora, and anything requiring server-side computation have real reasons to be online. But knowing which you have chosen is worth the two minutes it takes to test.

    Frequently asked questions

    Is local-first the same as offline mode?

    No. Offline mode is usually a limited cache bolted onto a cloud-first app, with reduced functionality and awkward reconciliation. Local-first means the device holds the authoritative copy in normal operation.

    Does local-first mean my data is not backed up?

    No — most local-first products sync to a server as well. The difference is that the server is a replica rather than the sole source of truth.

    Is it less secure to keep data on my device?

    It changes the threat model rather than worsening it. You take on device security, and you reduce exposure to a breach of the provider. Full-disk encryption and a strong device unlock cover most of the added risk.

  • What Makes a Phone Camera Good (It Is Not Megapixels)

    What Makes a Phone Camera Good (It Is Not Megapixels)

    Phone camera marketing settled on megapixels because it is a single number that goes up. It is close to the least useful specification on the sheet. The things that decide whether your photographs are good are how much light the camera collects and what the software does with it.

    The short version

    • Sensor size beats resolution. A bigger sensor collects more light, and light is the entire game.
    • Most high-resolution phone sensors combine pixels by default, so you are not shooting at the advertised number anyway.
    • Processing is now most of the camera. Two phones with identical hardware produce visibly different photographs.
    • Judge a camera by its worst conditions, not its best.

    Light is the constraint

    A camera records light. Everything that improves image quality does so by collecting more of it or wasting less of it. Sensor area is the dominant term: a physically larger sensor gathers more photons in the same exposure, which means less noise, better colour and more usable detail in shadow.

    This is why a compact camera with a large sensor outperforms a phone with a far higher pixel count. The phone may record more pixels; each one is recording less light.

    Why more megapixels can mean worse photographs

    Divide a fixed sensor area into more pixels and each pixel is smaller, so each collects less light and carries proportionally more noise. Manufacturers manage this with pixel binning — merging groups of small pixels into one larger effective pixel.

    Which means a phone advertising a very high resolution is typically producing images at a quarter or a ninth of that number in normal use, by design. The headline figure describes the sensor’s construction, not your photograph.

    The advertised megapixel count and the resolution of the photo you actually take are frequently different numbers. That is not a defect; it is the intended behaviour.

    Aperture, stabilisation and the rest of the optical path

    • Aperture (the f-number). Lower admits more light. It also narrows depth of field, which is why phones fake background blur computationally rather than optically.
    • Optical stabilisation. Physically counteracts hand shake, allowing longer exposures without smearing. It is the single most valuable feature in dim conditions, and it is what sensor-shift systems extend.
    • Autofocus quality. A sharp photograph focused on the wrong thing is a failure. Focus speed and reliability on moving subjects separates cameras far more than resolution does.
    • Lens quality. Flare, softness at the edges and chromatic aberration are set by the glass and never fully fixed in software.

    The processing pipeline is most of the camera

    A modern phone does not take a photograph. It captures a burst of frames at different exposures and merges them, aligning for hand movement, reducing noise, recovering shadows, restraining highlights and applying a manufacturer’s idea of pleasing colour.

    This is why two phones with near-identical camera hardware produce obviously different images. One brand may render warm and contrasty, another cool and flat, another may sharpen aggressively in a way that looks crisp on a phone screen and brittle on a large display.

    None of this is visible on a spec sheet. It is only visible in full-size sample images, which is why a review that publishes only downsized photos has not shown you the camera.

    Extra lenses: useful, and unevenly implemented

    Additional rear cameras genuinely extend what a phone can do — a wider view, or real optical reach instead of cropping. But secondary sensors are frequently much smaller and less capable than the main one, so image quality can drop sharply the moment you switch.

    A phone advertising several rear cameras may have one good camera and two that exist to raise the count. Compare the same scene shot on each lens, particularly indoors, before treating them as equivalent.

    How to compare cameras honestly

    1. Look at full-resolution samples, not compressed social media uploads.
    2. Weight difficult conditions — indoors at night, backlit subjects, moving children and animals.
    3. Check the ultrawide and telephoto, not only the main sensor.
    4. Shoot the same scene at the same moment where possible; light changes faster than you expect.
    5. Decide whether you prefer the brand’s colour rendering. It is a taste question and it will govern how you feel about every photo you take.

    Our own approach to this, including how long we carry a device before publishing, is set out in how we test.

    Frequently asked questions

    Is a higher megapixel count ever better?

    Yes, when the sensor is physically large enough to support it, and when you genuinely need to crop heavily or print large. On a small sensor, past a point, it costs more than it returns.

    Do more rear cameras mean a better phone?

    Not by itself. One excellent main sensor with a good ultrawide beats a larger array of weak sensors. Judge each lens separately.

    Should I shoot in RAW?

    Only if you intend to edit. RAW discards the computational pipeline, which is doing most of the work in difficult light — so an unedited RAW file often looks worse than the processed image, not better.

  • USB-C Is One Port With Many Contracts: A Cable Buyer’s Guide

    USB-C Is One Port With Many Contracts: A Cable Buyer’s Guide

    USB-C solved a physical problem and created an informational one. The connector is reversible, compact and universal. What it carries is not universal at all — the same plug can be a slow charging cable, a high-speed data link, or a full display connection, and nothing on the outside distinguishes them.

    The short version

    • USB-C is a connector shape, not a capability. Three separate things vary: power, data speed, and video.
    • Charging cables are frequently USB 2.0 internally — fine for power, useless for fast transfer or a monitor.
    • For high power you need an e-marked cable; without it the cable is limited regardless of the charger.
    • Buy for the hardest job the cable will ever do, and label it.

    Three independent variables

    1. Power

    USB Power Delivery negotiates voltage and current between charger, cable and device. Above a certain current the cable must contain a small identifier chip — an e-marker — that tells the charger what it can safely carry. Without one, the connection falls back to a lower limit, no matter how capable the charger and laptop are.

    The practical failure: a laptop charges slowly, or only while asleep, because the cable is the bottleneck. People replace the charger and nothing improves.

    2. Data

    Data speed varies over an enormous range across cables that look identical. The cable bundled with a phone is very often USB 2.0 internally, because the manufacturer only needed it to carry power and occasional syncing. It will charge your laptop and take an hour to move a video file.

    3. Video

    Driving a monitor over USB-C requires the cable to carry display signalling, and both ends must support it. A charging cable will typically produce no picture at all — not a degraded picture, simply nothing. This is the failure most often mistaken for a broken monitor or a broken port.

    Three cables, one connector, no external difference. This is why the same USB-C cable that charges your laptop can refuse to show a picture.

    The port matters as much as the cable

    A capable cable cannot rescue a limited port. Laptops frequently ship with USB-C ports of differing capability on the same chassis — one supporting display output and high-speed data, another handling power and basic transfer only.

    Look for small icons beside the port: a lightning bolt or ‘DP’ for display output, a Thunderbolt symbol for the highest-capability ports. If the ports are unlabelled, the manual is the only reliable source. This is one of the specifications worth checking before purchase, as we argue in how to read a laptop spec sheet.

    How to buy without learning the specification

    1. Decide the hardest job. Will this cable ever drive a monitor? Ever charge a laptop? Buy for that, not for today’s use.
    2. Prefer Thunderbolt or full-featured USB4 cables for anything ambiguous. They are more expensive and handle every case, which is cheaper than owning four cables and guessing.
    3. Check the wattage rating is stated. A vendor who does not publish it has not certified it.
    4. Buy certified. Certification programmes exist precisely because uncertified cables have damaged hardware.
    5. Label them. A wrap of tape naming the capability saves more time over a cable’s life than any amount of specification knowledge.

    Length is a real constraint

    High-speed signalling degrades over distance. Passive cables are limited to short runs at top speed; beyond that you need an active cable containing signal-boosting electronics, which costs considerably more and is often directional.

    If a long cable is unexpectedly cheap for its claimed speed, the claim is the part to doubt.

    On counterfeit and uncertified cables

    A USB-C cable is an active participant in a power negotiation. A badly made one can misreport its capability and invite a charger to deliver more power than the cable or device can handle. There are documented cases of non-compliant cables destroying hardware.

    This is one of the few places where brand and certification are worth paying for outright. The saving on an uncertified cable is small; the downside is your laptop.

    Frequently asked questions

    Why does my monitor not work over USB-C?

    Most likely the cable does not carry display signalling, or the specific port does not support display output. Try a cable you know drives a display, and check the port’s icon before assuming the monitor is at fault.

    Can a cable damage my device?

    A compliant one, no. A non-compliant one that misreports its capabilities can. This is the argument for certified cables from vendors who publish their ratings.

    Is Thunderbolt worth it if I do not own Thunderbolt devices?

    As a cable, often yes — it is a safe default that handles power, high-speed data and video without you having to check. As a device feature you are paying extra for, only if you have something to plug into it.

  • How to Read an AI Benchmark Without Being Fooled

    How to Read an AI Benchmark Without Being Fooled

    Every model launch comes with a bar chart, and the bars are almost always accurate. That is what makes them effective. The problem is not fabrication — it is that a benchmark measures one narrow thing under one set of conditions, and the chart invites you to generalise far beyond it.

    The short version

    • Ask what the benchmark actually measures before you look at who won.
    • Contamination is the default assumption: if the test is public and old, it is probably in the training data.
    • A number with no error bar and no described method is a claim, not a measurement.
    • The only evaluation that reliably predicts your results is one built from your own tasks.

    A benchmark is a proxy, and proxies drift

    Benchmarks exist because the thing we care about — ‘is this model useful for my work’ — is expensive and subjective to measure. So we substitute something cheap and countable: multiple-choice exams, coding puzzles with unit tests, question-answering over a fixed corpus.

    That substitution is reasonable right up until the proxy becomes a target. Once a leaderboard matters commercially, effort flows toward the leaderboard, and the correlation between the score and the underlying quality weakens. This is Goodhart’s law, and it applies to model evaluation with unusual force.

    When a measure becomes a target, it ceases to be a good measure. Leaderboards are measures that have very much become targets.

    Contamination: the failure that invalidates the number

    Models are trained on enormous crawls of the public internet. Public benchmarks live on the public internet. If a test set was published before a model’s training cut-off, the sensible prior is that some of it was seen during training.

    A contaminated benchmark does not measure reasoning. It measures recall of the answer key, and it reports a high score either way. This is why a model can post excellent results on a famous exam and then fail at a structurally identical problem written last week.

    What to look for

    • Was the evaluation set created after the model’s training cut-off, or held privately?
    • Do the authors report a contamination check at all?
    • Does performance collapse on rephrased versions of the same problems? That gap is the memorisation signal.

    Read the conditions, not just the score

    Two labs can evaluate the same model on the same benchmark and publish different numbers without either lying. The conditions do the work:

    • Prompting. Zero-shot, few-shot, or chain-of-thought — each can move a score substantially.
    • Attempts. One try, or best-of-many? ‘Best of 64’ is a meaningfully different claim from ‘first answer’.
    • Scaffolding. Tool access, retrieval, code execution and self-checking are frequently included in the harness and omitted from the headline.
    • Scoring. Exact match, human preference, or another model acting as judge — and if a model is judging, which one, and does it prefer its own style?

    A difference of a few points between two systems evaluated under different harnesses tells you approximately nothing.

    Averages hide the distribution you care about

    Aggregate scores conceal variance. A model that is excellent on most inputs and catastrophic on a predictable minority may average out ahead of a model that is consistently good — and be far worse in production, because your users will find the failure cases and you will own the consequences.

    This matters most where errors are expensive. For anything touching money, safety or law, the shape of the tail matters more than the mean, and almost no public leaderboard reports it.

    Build the only benchmark that predicts your results

    The evaluation that actually forecasts your outcome is one assembled from your own work. It does not need to be elaborate:

    1. Collect twenty to fifty real tasks from your actual workload, including the awkward ones.
    2. Write down what a good answer looks like before you run anything, so you are not grading on vibes afterwards.
    3. Run each candidate model under identical conditions — same prompt, same tools, same number of attempts.
    4. Score blind where you can, so you are not rewarding the output you expected to win.
    5. Keep the set and re-run it whenever you consider switching.

    Fifty representative examples from your domain will tell you more than every public leaderboard combined, and the set keeps paying out every time a new model appears.

    What benchmarks are still good for

    Directionally, they are useful. Very large gaps are usually real. Trends across many benchmarks and several model generations carry signal. And a poor score on a well-constructed, uncontaminated test is meaningful negative evidence.

    Treat them as a filter, not a verdict — the same way you would treat a processor’s peak clock speed when buying a machine, a habit we argue for in reading a laptop spec sheet.

    Frequently asked questions

    Why do models score well on exams but fail at my task?

    Exams are multiple-choice, self-contained and well represented in training data. Your task probably has ambiguous requirements, implicit context and no single correct answer. Those are different skills, and the first does not imply the second.

    Are human-preference leaderboards more trustworthy?

    They measure something real but specific: which response people prefer at a glance. That rewards confident, well-formatted, agreeable answers, which is not identical to rewarding correct ones.

    How often should I re-evaluate?

    When you have a concrete reason — a new model in your price band, a change in your workload, or a rise in user complaints. Re-running a fixed set on a schedule with no decision attached is just expense.

  • Passkeys, Explained: What Actually Replaces Your Password

    Passkeys, Explained: What Actually Replaces Your Password

    Passwords fail for a structural reason, not a discipline reason. A password is a shared secret: you know it, the service knows it, and anything that can impersonate the service can ask you for it. No amount of length or complexity fixes that. Passkeys change the mechanism.

    The short version

    • A passkey is a key pair. The private half never leaves your device; the service only ever stores the public half.
    • There is nothing reusable to steal — a breached service leaks public keys, which are useless to an attacker.
    • Passkeys are bound to the real domain, so a convincing phishing page simply cannot trigger them.
    • The hard part is no longer login. It is account recovery.

    What actually happens when you sign in

    When you create a passkey, your device generates a key pair. It sends the public key to the service and keeps the private key locked in secure hardware — a Secure Enclave, a TPM, or a hardware security key. To sign in, the service sends a random challenge; your device signs it with the private key; the service verifies the signature against the public key it already holds.

    Your biometric or device PIN never travels anywhere. It unlocks the private key locally. The service never sees your face, your fingerprint or your PIN — it only sees a valid signature.

    A password database is a pile of secrets worth stealing. A passkey database is a pile of public keys worth nothing.

    Why phishing stops working

    This is the part that matters most, and it is easy to miss. Every passkey is cryptographically bound to the domain it was created for. Your browser will only offer a passkey to the origin it belongs to.

    So when a convincing replica of your bank asks you to sign in, there is no passkey to offer. Not because you were alert enough to check the address bar, but because the browser checked for you and found no match. The attack does not fail at the human — it fails at the protocol. That is the whole point, and it is why passkeys are a genuine improvement rather than a repackaging.

    Where passkeys are stored, and the tradeoff you are choosing

    Passkeys have to live somewhere, and the choice determines what happens when you lose a device.

    • Platform keychain (Apple, Google, Microsoft accounts). Syncs across your devices automatically. Convenient; ties you to an ecosystem and makes that account extremely valuable to protect.
    • Third-party password manager. Cross-platform and portable between ecosystems. Moves the trust to the manager’s own security.
    • Hardware security key. The private key never syncs anywhere. Strongest guarantee, worst recovery story if you lose the key and have no backup.

    None of these is correct in general. A synced keychain is the right default for most people; a hardware key is right when compromise would be catastrophic. What is not sensible is holding a single hardware key with no registered backup.

    The problem nobody advertises: recovery

    If your passkeys live in secure hardware and that hardware is at the bottom of a lake, you need a way back into your accounts. Every recovery mechanism is also, by definition, an alternative way in — which means it is the new weakest link.

    Many services still fall back to email or SMS for recovery. If that is true of an account, then the practical security of your passkey is capped by the security of your email account or your phone number. SMS in particular is vulnerable to SIM-swap attacks, where an attacker persuades a carrier to move your number to their device.

    1. Register passkeys on at least two devices, or use a synced keychain and protect that account seriously.
    2. Print or write down recovery codes where a service offers them, and store them physically.
    3. Secure your email account first — it is the recovery path for almost everything else.
    4. Remove SMS as a recovery method wherever an alternative exists.

    What passkeys do not fix

    Passkeys protect the moment of authentication. They do nothing about what happens afterwards. Session tokens can still be stolen by malware on your machine; a service can still be breached and leak your data; and an attacker who compromises the device holding your keys has bypassed the question entirely.

    They also do not protect you from being socially engineered into doing something harmful while legitimately signed in. Authentication is one link in the chain, and the surrounding advice about device hygiene and update discipline still applies.

    Should you switch now?

    Enable passkeys on your most valuable accounts — email first, then anything financial — while keeping a working fallback until you have confirmed recovery works. Do not delete your password on an account until you have actually tested signing in from a second device.

    Expect a mixed experience for a while. Support across browsers, operating systems and individual sites is uneven, and some implementations are better than others. That is an argument for a staged move, not for waiting.

    Frequently asked questions

    If someone steals my phone, can they use my passkeys?

    Only if they can also unlock the device. The private key is released by your biometric or device PIN, so a locked phone is not usable for authentication. This is why a weak device PIN undermines the whole arrangement.

    Do passkeys work across different ecosystems?

    Increasingly, yes — through cross-device sign-in, where you approve on your phone to sign in on another machine, and through third-party password managers that sync passkeys everywhere. It is smoother within one ecosystem than across several.

    Is a passkey the same as two-factor authentication?

    It replaces both factors at once. A passkey requires possession of the device and a local unlock, so it is inherently multi-factor. Layering an SMS code on top of a passkey usually weakens it rather than strengthening it.

  • How to Read a Laptop Spec Sheet Without Getting Fooled

    How to Read a Laptop Spec Sheet Without Getting Fooled

    A laptop spec sheet is a marketing document that happens to contain facts. The numbers printed largest are the ones with the best ratio of impressiveness to cost, and the numbers that decide whether you will still like the machine in eighteen months are usually in the footnotes, if they appear at all.

    The short version

    • Screen and keyboard matter more than the processor. You touch them every second; you notice the CPU a few times a day.
    • Sustained performance beats peak performance. Ask what the machine does after ten minutes of load, not in the first thirty seconds.
    • Soldered RAM sets a permanent ceiling. Buy the memory you will need in three years, because you cannot add it later.
    • Watt-hours, not vague ‘all-day battery’ claims, is the only battery figure that compares across brands.

    Start at the panel, not the processor

    The display is the part of a laptop you look at continuously, and it is the part most commonly cheapened. Four numbers describe it honestly:

    • Resolution and size together. Pixel density is what your eye reacts to. A 1920×1080 panel is crisp at 13 inches and visibly coarse at 17.
    • Nits. Brightness determines whether the machine is usable near a window. Roughly 300 nits is the floor for indoor comfort; outdoors or in bright rooms you want considerably more.
    • Panel type. IPS and OLED hold colour and contrast off-axis. Cheaper TN panels shift colour the moment your head moves.
    • Refresh rate. Above 60 Hz, scrolling and cursor movement feel smoother. It is a comfort feature, not only a gaming one.

    If a listing omits the nit rating and the panel type, assume both are unflattering. Manufacturers publish good numbers.

    Peak performance is a marketing number

    Modern processors advertise a boost clock they can hold only while the chip is cold. In a thin chassis, that lasts seconds. What determines whether a machine feels fast during real work is the power it can sustain once the heatsink is saturated — and that figure is a property of the cooling design, not the chip.

    Two laptops with the same processor can differ enormously in sustained performance. The spec sheet cannot tell them apart. Only a review that ran a long load can.

    This is why the same chip name appears in a fanless tablet and a thick workstation. The name is shared. The behaviour is not. When you read reviews, look for a sustained load test — and treat any review that only quotes a short synthetic score as incomplete. We cover the same failure mode in AI hardware claims in how to read an AI benchmark.

    Memory and storage: one is permanent, one is not

    In most thin laptops the RAM is soldered to the board. Whatever you buy is what the machine has for its entire life. Storage, by contrast, is often a standard M.2 drive you can replace in ten minutes with a screwdriver, and external storage is cheap.

    The practical consequence: spend on memory at purchase, and be relaxed about storage. Buying less RAM to afford a bigger SSD is an optimisation in exactly the wrong direction, because you can fix the SSD later and you can never fix the RAM.

    How much memory is enough?

    It depends entirely on what you keep open, not on what you install. A browser with forty tabs, a chat client and a video call will consume more memory than most people expect. If your honest answer is ‘I do not know’, buy one tier above the base configuration — that is the cheapest insurance on the sheet.

    Ports, and the quiet cost of dongles

    Port count is easy to read and easy to underestimate. Check three things: how many ports there are, what each one can actually do, and whether charging occupies one of them. A machine with two USB-C ports where one is permanently holding the charger is a one-port machine.

    USB-C in particular hides enormous variation — two identical-looking ports on the same laptop can differ in data speed, display output and charging capability. That confusion extends to the cables, which we untangle in the USB-C cable buyer’s guide.

    Battery: insist on watt-hours

    ‘Up to 18 hours’ is a claim measured under conditions no one works in — usually local video playback at low brightness with radios off. It cannot be compared between manufacturers because they each choose their own test.

    Watt-hours (Wh) is a physical measurement of stored energy, and it can be compared. Pair it with the panel’s brightness and the chip’s sustained power draw and you have a real estimate. A large battery behind a dim, efficient screen lasts a long time; the same battery behind a bright high-refresh panel does not.

    What the spec sheet will never tell you

    • Keyboard feel and layout. Key travel, stabiliser quality and whether the arrow keys are half-height. Unquantified, and you will notice daily.
    • Fan behaviour. Not just loudness, but whether the fan surges up and down, which is far more distracting than constant noise.
    • Hinge and chassis flex. The first thing to degrade on a cheap machine.
    • Repairability. Whether the battery is glued, whether the SSD is standard, whether service manuals exist.
    • Software support window. How long firmware and driver updates will keep arriving.

    These are exactly the things a review exists to establish, which is why we publish our testing method alongside every verdict.

    Frequently asked questions

    Is a faster processor worth paying for?

    Usually less than you would expect. Beyond a competent mid-range chip, most people are limited by memory, storage speed and thermal headroom rather than raw processor performance. Spend the difference on memory or a better screen.

    Does a dedicated graphics card matter if I do not play games?

    For most work, no — and it costs battery life, weight and heat. It matters for 3D work, sustained video encoding and some machine-learning workloads. If you cannot name the application that needs it, you do not need it.

    How long should a laptop last?

    Physically, most well-built machines last far longer than their software support. The realistic limit is the manufacturer’s update window and the memory ceiling you chose at purchase — which is the argument for buying more memory than you need today.