DEV Community: David Timothy

How Much Can Websites Really Detect About Brave Users?

David Timothy — Tue, 22 Sep 2026 01:37:21 +0000

People install Brave because they want websites to know less about them. That expectation is reasonable. Brave blocks ads and trackers by default, restricts cross-site storage, modifies fingerprintable APIs, and has spent years building defenses that stock Chromium does not provide.

Then a website runs this:

const isBrave = await navigator.brave?.isBrave?.();

Or reads this request header:

Sec-CH-UA: "Brave";v="153", "Not_A Brand";v="8",
  "Chromium";v="153"

Or asks JavaScript for the visitor’s default timezone:

Intl.DateTimeFormat().resolvedOptions().timeZone;

The result might be Europe/Zurich, America/New_York, or Asia/Tokyo.

None of those observations makes Brave a bad privacy browser. They do expose an important distinction that gets lost in browser marketing: privacy protection does not mean making the browser invisible.

As of September 22, 2026, the current stable desktop release is Brave 1.95.104, based on Chromium 153. This article focuses mainly on Brave’s Chromium-based desktop and Android versions. Brave on iOS runs on Apple’s WebKit stack, does not support User-Agent Client Hints, and has different technical constraints.

So, how much can an ordinary website actually learn about a Brave user?

The short answer is: quite a bit about the browser environment, but much less stable identifying information than it would receive from an unprotected Chromium browser.

A first-party website can generally determine that the browser is Brave. It can learn the Chromium major version, operating-system family, exact IANA timezone, language information, viewport dimensions, and broad hardware characteristics. With User-Agent Client Hints, it can request additional details such as platform version, architecture, and bitness.

At the same time, Brave blocks many third-party tracking scripts before they execute, partitions storage, and deliberately modifies signals such as canvas output, Web Audio output, screen characteristics, CPU count, memory estimates, font availability, WebGL extensions, and GPU identification.

That combination is where Brave’s privacy model gets interesting.

Brave is detectable, and that is intentional

There are at least three direct, current mechanisms for detecting Brave on a normal website:

The Brave brand in User-Agent Client Hints
The navigator.brave.isBrave() JavaScript API
Brave-specific generic GPU strings exposed by its WebGL protections

Brave’s own documentation is unusually direct about the first two. Hiding the fact that someone uses Brave is not a general privacy goal.

That decision deserves more attention than either side of the usual debate gives it.

Browser identification is not the same as identifying a person. Knowing that a visitor uses Brave 153 places them in a group. It does not reveal their name, account, browsing history, or a persistent browser identifier.

Still, reducing a visitor from “some Chromium user” to “a Brave user” narrows the anonymity set. It also gives websites an easy condition they can incorporate into analytics, fraud scoring, content decisions, or browser-specific blocking.

Brave accepts that trade-off, while maintaining compatibility exceptions for sites that break or discriminate against Brave users.

Why the traditional User-Agent string often looks like Chrome

On desktop and Android, Brave uses a Chrome-compatible User-Agent request header. A current macOS string looks roughly like this:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/153.0.0.0 Safari/537.36

There is no Brave token.

This is deliberate. User-Agent strings have accumulated decades of compatibility baggage. Websites frequently parse them using brittle regular expressions and assumptions about token order. Adding a new browser token can result in unsupported-browser pages, incorrect downloads, or entire applications refusing to load.

The string is also reduced. It exposes the Chromium major version but replaces the minor and patch components with zeros. On macOS, the operating-system token is frozen at 10_15_7, even on much newer systems.

At first glance, Brave therefore looks like Chrome to traditional server-side User-Agent parsers.

That does not mean the browser is trying to remain indistinguishable from Chrome everywhere.

`Sec-CH-UA` says Brave explicitly

Chromium’s replacement for much of the old User-Agent machinery is User-Agent Client Hints, commonly shortened to UA-CH.

On an ordinary secure request, Brave can send low-entropy hints such as:

Sec-CH-UA: "Brave";v="153", "Not_A Brand";v="8",
  "Chromium";v="153"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "macOS"

The first value is the important one:

"Brave";v="153"

It tells the server that Brave is one of the browser’s brands. The version is the Chromium-aligned major version, not the Brave application version 1.95.104.

"Chromium";v="153" describes the shared browser engine lineage.

"Not_A Brand";v="8" is an intentionally fake GREASE brand. It exists to discourage developers from assuming that the first item is always the real browser or that every brand will be recognized. The spelling, version, and ordering can change.

Do not parse Sec-CH-UA with a fixed substring position. Treat it as a structured list of brands:

function hasBrand(name) {
  return (
    navigator.userAgentData?.brands?.some(
      ({ brand }) => brand === name,
    ) ?? false
  );
}

console.log(hasBrand("Brave"));

Unlike many higher-entropy Client Hints, Sec-CH-UA is normally sent without a server first opting in through Accept-CH. JavaScript can obtain the equivalent low-entropy list from navigator.userAgentData.brands.

This produces an interesting split:

The legacy User-Agent string prioritizes Chrome compatibility.
The newer Client Hints interface identifies Brave directly.

That is not an accidental failure to hide. It is Brave’s documented design.

JavaScript can ask Brave directly

Brave also exposes a browser-specific API:

async function detectBrave() {
  const brandMatch =
    navigator.userAgentData?.brands?.some(
      ({ brand }) => brand === "Brave",
    ) ?? false;

  let apiMatch = false;

  try {
    apiMatch = Boolean(await navigator.brave?.isBrave?.());
  } catch {
    apiMatch = false;
  }

  return { brandMatch, apiMatch };
}

console.log(await detectBrave());

navigator.brave.isBrave() returns a promise resolving to true in Brave. This is not a standard Web API. It is an intentional Brave extension implemented in the browser’s Blink integration.

A website might use it to:

Offer installation instructions for another Brave component
Avoid presenting a “download Brave” banner to existing users
Diagnose browser-specific compatibility problems
Measure Brave usage more accurately
Apply a workaround for a known Brave interaction

It can also be used less constructively, such as placing Brave users into a separate risk bucket or denying them access.

Brave maintains compatibility exceptions where this API and its Client Hints identity may be hidden because a site breaks or discriminates against Brave. Users can also apply a custom content-filter rule to suppress navigator.brave for a particular domain.

The ordinary behavior remains clear: a website is allowed to know that the visitor uses Brave.

Brave’s GPU protection is another detectable marker

There is now a third, less obvious signal.

Older Brave releases allowed WebGL’s debugging extension to expose detailed GPU strings such as an Apple M-series model, an NVIDIA GPU, an AMD adapter, or an ANGLE renderer and driver combination.

Brave addressed this in versions 1.92 and 1.93. With fingerprinting protection enabled, current Brave desktop and Android builds replace the WebGL unmasked vendor and renderer with a generic value:

function getWebGlIdentity() {
  const canvas = document.createElement("canvas");
  const gl = canvas.getContext("webgl");

  if (!gl) {
    return null;
  }

  const debug = gl.getExtension("WEBGL_debug_renderer_info");

  if (!debug) {
    return null;
  }

  return {
    vendor: gl.getParameter(debug.UNMASKED_VENDOR_WEBGL),
    renderer: gl.getParameter(debug.UNMASKED_RENDERER_WEBGL),
  };
}

console.log(getWebGlIdentity());

Under current default protection, those unmasked fields can return Brave instead of the real GPU vendor and model.

From a fingerprinting perspective, this is a very good trade. Replacing thousands of possible hardware and driver combinations with one common value removes a large amount of entropy.

From a browser-identification perspective, it is another Brave marker.

That distinction matters. A value can make the browser family easier to identify while making the individual device much harder to identify. Calling both effects a “privacy leak” would be technically sloppy.

Brave reveals the default IANA timezone

The timezone case is more difficult to dismiss as mere browser branding.

A normal website can run:

const options =
  Intl.DateTimeFormat().resolvedOptions();

console.log({
  locale: options.locale,
  timeZone: options.timeZone,
  calendar: options.calendar,
  numberingSystem: options.numberingSystem,
});

On current Brave, timeZone can contain the runtime’s default IANA timezone identifier:

Europe/Zurich
Europe/Vienna
America/New_York
Asia/Tokyo
America/Buenos_Aires

This is not just a UTC offset.

As of the current Brave release, the browser does not generally replace this value with UTC, randomize it per site, or reduce it to a generic numeric offset. Brave’s public fingerprinting test matrix does not list timezone as a protected surface, and an open Brave issue continues to track the fact that the real zone is observable.

A September 2026 diagnostic report in Brave’s issue tracker also recorded the browser returning America/Buenos_Aires alongside the current Brave 153 Client Hints data.

An IANA timezone contains more information than an offset

Consider these two values:

UTC+1

Europe/Zurich

UTC+1 describes an offset at a moment in time. Many countries and regions can share that offset.

Europe/Zurich identifies a named set of civil-time rules. It carries information about daylight-saving transitions, historical changes, and the region whose timezone database entry is being used.

The same distinction applies to:

UTC-5

and:

America/New_York

New York is not always UTC-5. During daylight-saving time it uses UTC-4. Other regions may currently share one of those offsets while following different transition rules.

This is why websites and calendar applications prefer an IANA identifier. It allows them to schedule a recurring event at 9:00 AM local time across future daylight-saving changes. A numeric offset alone cannot reliably do that.

That legitimate use is also what makes the value more informative for fingerprinting.

A timezone is a regional clue, not proof of location

Europe/Zurich does not prove that someone is physically in Zurich. The user could be:

Elsewhere in Switzerland
Traveling with an unchanged system timezone
Using a remote desktop
Running a virtual machine
Manually overriding the system timezone
Using a VPN whose endpoint does not match the device timezone

A website also cannot derive a street address or GPS position from Intl.DateTimeFormat.

Precise geolocation remains separately permission-gated.

Timezone should instead be understood as a regional signal. Its significance depends heavily on the zone.

America/New_York covers a large population across multiple states and areas. It is a relatively broad clue.

Europe/Vienna, Europe/Zurich, and Asia/Tokyo are more strongly associated with particular countries or small groups of jurisdictions. For users in smaller countries or distinctive timezone regions, the identifier can narrow the likely area more substantially.

The value becomes more useful when combined with other signals:

IP-derived country or region
Browser language
Locale and formatting preferences
Operating-system family and version
Keyboard and font availability
Screen and device characteristics
Browser brand and major version

A timezone and IP address that agree can increase confidence in a geographic inference. A mismatch can suggest travel, a VPN, remote access, or a misconfigured clock. It should not automatically be treated as evidence of fraud.

Why Brave may be reluctant to mask it

It is tempting to say Brave should return UTC or a representative city for each current offset. Technically, neither solution is free.

Returning UTC would change how existing applications display dates unless every application explicitly asked for another zone.

Replacing Europe/Zurich with another zone that currently has the same offset can create incorrect results when daylight-saving rules diverge. It can also change historical date calculations.

Permission-gating the value would be cleaner in privacy terms, but it would introduce prompts and break the long-standing assumption that local date formatting works without permission.

Brave could theoretically apply different policies in first-party and third-party contexts, reduce the value only when used for passive inspection, or introduce an explicit site permission. Each option has compatibility and implementation consequences.

The criticism is still fair: exact timezone identifiers are stable, geographically meaningful fingerprint inputs, and current Brave leaves them available. The reason is not that timezone masking is obviously impossible. The reason is that a correct replacement has to preserve calendaring behavior, daylight-saving rules, and existing application expectations.

What else can a website observe?

The following table summarizes important surfaces on current Chromium-based Brave releases with default fingerprinting protection enabled.

Signal	How a site obtains it	Current Brave treatment	Privacy significance
Brave identity	`Sec-CH-UA`, `navigator.userAgentData.brands`, `navigator.brave.isBrave()`	Intentionally exposed, with site-specific compatibility exceptions	Identifies the browser family, not the user
Chromium major version	User-Agent and Client Hints	Exposed	Useful for compatibility and fingerprint classification
OS family	`Sec-CH-UA-Platform`, `navigator.userAgentData.platform`	Exposed	Broad platform signal
OS version	High-entropy Client Hints	Available when requested on supported builds	Can narrow the device population
CPU architecture and bitness	High-entropy Client Hints	Available when requested	Can distinguish ARM, x86, 32-bit, and 64-bit environments
IANA timezone	`Intl.DateTimeFormat().resolvedOptions().timeZone`	Exposed unchanged	Stable regional and fingerprinting signal
IP address	Normal network connection	Not hidden by ordinary Brave browsing	Strong network and approximate-location signal
WebGL GPU vendor and renderer	`WEBGL_debug_renderer_info`	Replaced with generic Brave values by default	Exact hardware hidden, browser becomes more obvious
WebGPU adapter descriptors	`GPUAdapter.info`	Vendor, architecture, device, and description scrubbed	Removes direct GPU identification
WebGL extension list	`getSupportedExtensions()`	Randomized per site and session	Reduces stable GPU and driver fingerprints
Canvas and Web Audio output	Canvas and audio readback APIs	Farbled	Poisons hashes that expect stable output
Screen characteristics	`screen`, CSS media queries	Several screen-size surfaces are modified	Reduces stable display fingerprints
Viewport dimensions	`innerWidth`, `innerHeight`, layout APIs	Generally available for page layout	Dynamic but still useful as a supporting signal
CPU count	`navigator.hardwareConcurrency`	Farbled	Preserves performance hints while reducing stability
Memory class	`navigator.deviceMemory`	Farbled or reduced	Broad hardware-capability signal
Fonts	Font probing and text measurement	Availability is restricted or randomized	Reduces installed-font fingerprinting
Language preferences	Headers and navigator properties	Partially reduced or modified	Still useful for localization and regional inference
Browser capabilities	Feature detection	Available	Reveals engine generation and enabled features

The exact result can change if the user lowers Shields, disables fingerprinting protection for a site, installs extensions, changes browser flags, or uses a platform where Brave has fewer implementation controls.

High-entropy Client Hints deserve more scrutiny

Low-entropy Client Hints include the browser brands, mobile status, and platform. More detailed fields are available through the high-entropy interface:

async function getDetailedUaData() {
  const uaData = navigator.userAgentData;

  if (!uaData?.getHighEntropyValues) {
    return null;
  }

  return uaData.getHighEntropyValues([
    "architecture",
    "bitness",
    "fullVersionList",
    "model",
    "platformVersion",
  ]);
}

console.log(await getDetailedUaData());

A supported Brave build may return an object containing data such as:

{
  architecture: "arm",
  bitness: "64",
  mobile: false,
  platform: "macOS",
  platformVersion: "27.0.0",
  brands: [
    { brand: "Brave", version: "153" },
    { brand: "Not_A Brand", version: "8" },
    { brand: "Chromium", version: "153" }
  ]
}

Returned values vary by platform, browser policy, and Chromium version. “High entropy” is not a promise that every field will contain maximum detail. The browser remains free to reduce or omit data.

Servers can request corresponding HTTP headers through Accept-CH, including:

Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness,
  Sec-CH-UA-Platform-Version

The browser can then send those hints on subsequent requests.

Client Hints are an improvement over broadcasting every detail in every User-Agent string. They make granular information structured and, for higher-entropy fields, request-driven.

They do not make the information harmless.

For developers, the right rule is simple: request only the fields the application actually needs. Architecture may be justified on a native-software download page. It is hard to justify on a blog, documentation site, or ordinary account dashboard.

Display and window information cannot simply disappear

Websites need the viewport size to perform layout. CSS media queries, responsive images, canvas sizing, and virtualized interfaces all depend on display-related information.

A page can observe values such as:

const display = {
  screenWidth: screen.width,
  screenHeight: screen.height,
  availableWidth: screen.availWidth,
  availableHeight: screen.availHeight,
  colorDepth: screen.colorDepth,
  pixelRatio: devicePixelRatio,
  viewportWidth: innerWidth,
  viewportHeight: innerHeight,
};

console.log(display);

Brave modifies several screen-size surfaces to make them less reliable for fingerprinting. The viewport still has to correspond closely enough to the actual page area for layout to work.

This is a recurring pattern in browser privacy engineering. A value does not need to be perfectly accurate to support benign use, but changing it too aggressively can produce visible breakage.

The useful privacy question is therefore not, “Can a website read a number?” It is, “Does the website receive a stable, sufficiently precise value that helps link this browser across contexts?”

Memory and processor APIs reveal broad hardware classes

Two common examples are:

console.log(navigator.hardwareConcurrency);
console.log(navigator.deviceMemory);

hardwareConcurrency exists so applications can choose a sensible number of workers. deviceMemory helps a site avoid delivering an unnecessarily expensive experience to a low-memory device.

Both can also classify hardware.

A high-end ARM Mac, an older dual-core laptop, and an inexpensive Android phone may produce different combinations. Brave farbles these values so they remain useful as rough performance hints without consistently exposing the true machine configuration.

This is a stronger defense than simply reducing every device to the same hard-coded value. A universal value is easy for scripts to detect, can break workload tuning, and may itself identify the browser’s privacy mode.

GPU information has improved substantially

GPU information used to be one of Brave’s clearest remaining fingerprinting weaknesses.

The 2026 WebGL and WebGPU changes materially improved that situation:

WebGL unmasked vendor and renderer strings are replaced with generic values.
WebGPU adapter descriptors are emptied.
WebGL supported-extension lists are randomized.
Existing canvas and WebGL rendering farbling remains active.

For current WebGPU code, GPUAdapter.info is the relevant interface:

async function inspectWebGpu() {
  if (!navigator.gpu) {
    return null;
  }

  const adapter = await navigator.gpu.requestAdapter();

  if (!adapter) {
    return null;
  }

  return {
    info: adapter.info,
    features: [...adapter.features],
    limits: adapter.limits,
  };
}

console.log(await inspectWebGpu());

Older examples using requestAdapterInfo() are outdated for the current API.

In Brave, direct fields such as vendor, architecture, device, and description are scrubbed. WebGPU features and limits still have to describe what the implementation can support. Those capability sets may reveal a broad GPU class even when the model name is gone.

Brave has discussed further protection for WebGPU’s supported capabilities. Proposed or planned work should not be confused with shipped behavior. The currently shipped improvement is the removal of direct adapter identification.

Fingerprinting is not one thing

A lot of privacy writing collapses several distinct concepts into “tracking.” That makes technical discussions harder than they need to be.

Browser identification

Browser identification answers:

Is this Brave, Chrome, Safari, or Firefox?

Sec-CH-UA and navigator.brave.isBrave() do this directly.

It classifies software. By itself, it does not distinguish one Brave user from another.

Device fingerprinting

Device fingerprinting combines browser and environment characteristics into a representation of the client.

Possible inputs include:

timezone
+
browser brand and version
+
OS and platform version
+
architecture
+
language and locale
+
screen and viewport characteristics
+
GPU capabilities
+
CPU and memory hints
+
font behavior
+
browser-specific APIs

Some values may be shared by millions of devices. The combination can be more distinctive than any individual input.

A fingerprint does not have to be globally unique to be useful. It can help a site recognize a returning visitor with some probability or divide traffic into smaller groups.

Geographic inference

Geographic inference estimates where the user may be.

An IP address is usually much more informative than a timezone. Language and locale can add supporting evidence. An IANA timezone can narrow the possibilities, particularly in geographically distinctive regions.

None of those signals necessarily proves the user’s physical location.

Tracking

Tracking is the act of linking activity across time, pages, accounts, or websites.

A fingerprint is one possible tracking mechanism. Cookies, URL identifiers, login accounts, redirect parameters, and server-side identifiers are others.

Brave’s tracker blocking and storage partitioning attack tracking at several layers. Even if a first-party page can read the timezone, a blocked third-party script cannot collect anything because it never executes.

Personal identification

Personal identification connects browser activity to a real person.

A website can do that trivially after the user logs in, provides an email address, completes a purchase, or submits identifying information. A timezone is not personal identification.

This distinction is why “Brave exposes my timezone” and “Brave tells websites who I am” are not equivalent claims.

What Brave’s privacy model is actually trying to do

Brave does not attempt to make every API return nothing.

Its architecture combines several defenses:

Block known ads and trackers at the network layer
Block or partition third-party storage
Remove known tracking parameters from URLs
Limit referrer information
Partition network state
Modify or remove especially identifying API results
Randomize fingerprint inputs using farbling
Preserve enough API behavior for normal sites to work

Farbling is particularly important.

Instead of forcing every Brave installation to return the same value, Brave derives modifications from a seed associated with the site, session, and storage area. A value remains consistent enough for a page to function during that context, but can differ for another site or a later session.

That design attacks fingerprint stability.

Suppose a fingerprinting library hashes 20 attributes together. If even one important input changes when the user restarts the browser or visits from another site context, the final hash changes too. Brave does not have to make every attribute invisible to disrupt that fingerprint.

This is also why finding an unmodified property does not automatically prove the entire protection has failed. The relevant question is whether the complete collection remains stable and linkable.

Older Brave documentation refers to a separate Strict fingerprinting mode. Brave retired that mode beginning with version 1.64. Current articles should not tell users to enable a legacy Strict setting that no longer exists.

The unresolved tension: privacy versus compatibility

Brave’s most defensible disclosures are those needed for interoperability.

A site may reasonably need to know:

Whether a browser supports a feature
Whether it is running on a mobile form factor
Which installer architecture to offer
Which timezone rules to use for a calendar
How large the viewport is
Roughly how much parallel work the device can handle

The harder question is whether each use case needs the most precise available value.

Does a documentation site need the exact operating-system version? Probably not.

Does an event calendar need a real IANA timezone? Often, yes.

Does a 3D application need GPU features and limits? Yes.

Does it need a human-readable GPU model and driver string? Usually not.

Does a website need to know the browser is Brave? Sometimes useful, but feature detection is generally more robust.

Brave’s 2026 GPU changes are a good example of the model working as intended. WebGL and WebGPU remain usable, but highly identifying strings are removed. The site gets capabilities without receiving the exact device name.

Timezone remains a harder case because the precise identifier is itself the capability calendar software wants.

Browser identity is mostly a policy decision. Brave wants to be measurable, supportable, and compatible as its own browser. It also wants the ability to suppress that identity when sites misuse it.

Those goals are reasonable. They are not the same as maximizing indistinguishability.

What developers should do with this information

The fact that Brave can be detected does not mean application code should branch on it.

Prefer feature detection:

if ("gpu" in navigator) {
  // Offer a WebGPU path.
}

if ("showOpenFilePicker" in window) {
  // Offer the File System Access integration.
}

Avoid logic like this:

if (isBrave) {
  disableFeature();
}

A Brave user may have Shields lowered. A Chrome user may have restrictive extensions. Enterprise policies can alter both browsers. Browser identity is a weak proxy for actual capability.

If you collect timezone information, collect it because the product needs timezone semantics:

const timeZone =
  Intl.DateTimeFormat().resolvedOptions().timeZone;

Good uses include:

Scheduling events
Displaying account activity in local civil time
Calculating recurring reminders
Selecting an initial timezone in a user-editable form

Poor uses include silently adding the timezone to an unnecessary device fingerprint.

For systems that genuinely need a durable timezone, an explicit account setting is often better than repeatedly inferring it from the device. Users travel, use remote machines, and change system settings.

Treat high-entropy Client Hints the same way. Request architecture on a download page if you need to choose between ARM64 and x86-64 binaries. Do not request it across every route merely because the API exists.

Fraud and abuse systems also need to account for privacy browsers. Farbled CPU counts, generalized GPU details, blocked storage, or a mismatch between IP and timezone are not proof of automation or malicious behavior. Privacy protection can look like environmental inconsistency to systems trained exclusively on stock browsers.

Finally, remember the first-party boundary. Brave is strongest against the web’s background machinery: third-party trackers, cross-site storage, fingerprinting scripts, tracking parameters, and stable hardware identifiers. It does not prevent a site the user intentionally visits from seeing everything necessary to serve that page.

Privacy is not binary

Brave is a strong privacy-focused browser precisely because it does more than change a preference or install an ad-blocking extension. Its protections operate in the network stack, storage model, rendering APIs, JavaScript environment, and Chromium integration.

The browser still reveals meaningful information.

A website can identify Brave through Client Hints and JavaScript. The new generic WebGL strings may identify Brave while hiding the underlying GPU. High-entropy Client Hints can provide platform details. The exact IANA timezone remains available and can contribute to regional inference and fingerprinting.

Those facts do not cancel out Brave’s protections.

They show what modern browser privacy actually looks like: reducing stable, unnecessary identifying information while keeping enough of the web platform intact for applications to work.

Brave’s decision to expose its own identity is debatable, but transparent and intentional. Its timezone behavior is a more surprising limitation and a reasonable target for further privacy work. Its recent GPU changes show that the project is willing to revisit exposed surfaces when a useful, compatible mitigation becomes practical.

For developers, the useful lesson is not that Brave is undetectable. It is that Brave changes the economics and reliability of tracking.

A website can learn that a visitor uses Brave. It can learn their timezone, platform class, viewport, and a collection of capabilities. What it has a much harder time obtaining is a precise, stable hardware profile that works unchanged across sites and sessions.

That is not perfect invisibility. It is still a meaningful privacy improvement.

Sources

When Regular VPNs Fail, Run Your Own With Outline

David Timothy — Mon, 21 Sep 2026 02:18:04 +0000

A VPN can be fast, secure, affordable, and completely useless if the network refuses to connect to it.

That is the problem developers run into in restrictive network environments. The VPN subscription is active. The client is installed. Every setting looks correct. But the provider’s domain is filtered, its API cannot be reached, its server IPs are blocked, or its protocol is identified and disrupted before the tunnel finishes connecting.

Switching to another commercial VPN sometimes helps.

Then that service gets blocked too.

This is why GetOutline is interesting. Outline is not simply another company selling access to a large collection of VPN servers. It is an open-source system for creating, managing, and sharing access to a server you control.

That distinction sounds minor until centralized VPN infrastructure becomes the thing a network is targeting.

Outline does not make blocking impossible. It does not make encrypted traffic invisible, and it does not guarantee connectivity in Russia, China, or anywhere else with aggressive network filtering.

What it changes is the architecture.

Instead of joining thousands of customers on a provider’s well-known infrastructure, you can run a private VPN server on a VPS, create separate access keys for people you trust, and replace the server if its address stops working.

For developers and small technical teams, that can be a much more useful model.

The problem is not always the VPN protocol

When people say a VPN is “not working,” they can mean several completely different failures:

The provider’s website or download page is blocked.
The client cannot reach the provider’s authentication API.
DNS manipulation prevents service discovery.
Known VPN server IP addresses are blocked.
Traffic on common VPN ports is filtered.
Deep packet inspection identifies a protocol fingerprint.
Connections are reset or throttled after detection.
Active probing is used to investigate suspected proxy servers.
The VPN works on one ISP but not another.
The service connects today and fails tomorrow.

These failures do not necessarily mean the VPN encryption has been broken.

A censor does not need to decrypt a tunnel if it can identify the destination and drop every packet going there.

Commercial VPN providers are especially exposed to this problem because they are centralized and discoverable. They publish applications, domains, support pages, API endpoints, and server locations. Their users repeatedly connect to overlapping pools of IP addresses.

That scale is useful under normal conditions. It gives customers many locations and lets the provider operate optimized infrastructure.

It also creates obvious blocking targets.

A restrictive network can acquire a subscription, enumerate available servers, correlate traffic patterns, block known IP ranges, interfere with account authentication, or prevent users from downloading configuration updates.

The provider responds by rotating addresses, changing protocols, adding obfuscation, or deploying new infrastructure. The censor adjusts. Reliability becomes an ongoing contest rather than a permanent technical property.

The uncomfortable fact is simple:

A VPN can use strong cryptography and still be easy to disrupt.

Encryption protects the contents of traffic. It does not automatically conceal that a particular host is receiving VPN-like connections.

What GetOutline actually is

Outline’s own FAQ makes a useful distinction: Outline is not itself a VPN service. It is software that lets someone create and manage a private VPN server.

The project has three major pieces:

Outline Server runs on a Linux server and handles encrypted proxy traffic.
Outline Manager deploys and administers servers, creates access keys, revokes users, and configures data limits.
Outline Client imports an access key and routes device traffic through the configured server.

There is also the open-source Outline SDK, which exposes networking components for developers building applications that need protection against network-level interference.

Outline was launched by Jigsaw, an incubator within Google. According to the project’s FAQ, ownership transitioned in 2026 to the independent nonprofit Outline Foundation. The software remains open source.

The normal data path looks like this:

flowchart LR
    A[Developer device] -->|Encrypted connection| B[Outline server on VPS]
    B -->|Regular internet traffic| C[Documentation, APIs, Git hosts]
    D[Outline Manager] -->|Server administration| B
    D -->|Creates access key| A

The Manager is the control surface. The Client handles the user connection. The server is the exit point visible to destination services.

If you deploy the server in Germany and connect from another country, websites generally see the German server’s IP address. Your local ISP sees an encrypted connection to that server, not the final contents of the traffic passing through it.

The VPS provider still occupies an important trust position. It controls the infrastructure hosting the server and can observe metadata around it. Destination websites can identify or log the server’s public IP. Outline improves control over who operates the VPN layer, but it does not remove every intermediary from the network.

Outline is built around Shadowsocks, not a conventional VPN tunnel

Outline Server runs a Shadowsocks-based service. Shadowsocks is an encrypted proxy protocol originally designed for use in censored network environments.

This matters because protocols have recognizable behavior.

Traditional VPN protocols may expose distinctive handshakes, packet structures, timing behavior, port usage, or other characteristics that filtering systems can classify. Some protocols are secure but were not designed to blend into arbitrary internet traffic.

Outline describes its protocol as “handshake-less” and “look-like-nothing.” In practical terms, the server does not begin with the kind of obvious unauthenticated negotiation that gives a filtering system a simple protocol banner to match.

An invalid connection does not receive a helpful response announcing that an Outline server is present.

That raises the cost of identification.

It does not make Outline undetectable.

Traffic classification can use more than a handshake. A sufficiently capable observer can examine packet sizes, timing, connection behavior, endpoint reputation, hosting-provider ranges, and repeated failed connections. It can also block an IP address without identifying the exact application behind it.

China’s Great Firewall has used combinations of deep packet inspection, endpoint blocking, and active probing against circumvention protocols. Research from the GFW Report has documented evolving detection and blocking behavior rather than one static filter.

Russia has also expanded technical restrictions on VPN and circumvention services. OONI measurements have documented blocking that varies by service, protocol, network, and period. Russian authorities and network operators have used website blocking, IP-based interference, protocol disruption, and restrictions against services including VPN products and encrypted communication tools.

So the responsible answer to “Does Outline work in China or Russia?” is not yes or no.

Outline may work where a public commercial VPN does not because:

Its server address is privately distributed.
It is not necessarily listed in a provider’s public server catalog.
Fewer unrelated users connect to the same address.
Its Shadowsocks-based traffic is designed to avoid an obvious handshake.
The operator can choose another host, port, provider, or region.
A blocked server can be replaced without waiting for a VPN company.

The same server can still be discovered, fingerprinted, throttled, or blocked. Conditions can differ between ISPs and change without warning.

Outline is more accurately described as blocking-resistant, not unblockable.

The architecture is the real feature

The easiest way to understand Outline is to compare who controls the infrastructure.

Question	Commercial VPN	Self-hosted Outline server
Who chooses the server IP?	VPN provider	You
Who shares the server?	Potentially many customers	Only users you authorize
Are server addresses broadly advertised?	Often	Usually not
Who creates user credentials?	Provider	You
Who replaces blocked infrastructure?	Provider	You
Who maintains the VPN software?	Provider	You, with help from Outline tooling
Who pays for bandwidth?	Included in subscription terms	You through the hosting provider
Who receives abuse complaints?	Provider	Potentially you or your VPS provider

A large commercial provider has more staff, more servers, better monitoring, and more capacity to absorb attacks. Self-hosting does not magically outperform a professionally operated network.

But centralization creates correlated failure.

If a commercial provider has 50,000 users connecting to a known server fleet, blocking that fleet affects everyone at once. If 1,000 Outline operators each use independently selected servers, the censor faces 1,000 smaller targets that may not be publicly related.

Outline is not a decentralized peer-to-peer network. Each server remains an ordinary, individually controlled endpoint. The broader ecosystem is distributed only in the practical sense that different operators deploy unrelated servers across different providers and addresses.

That is enough to change the blocking economics.

Blocking one private IP may affect a few people. Blocking an entire cloud provider could cause far more collateral damage because legitimate businesses use the same network ranges. Some filtering systems will accept that collateral damage. Others will not.

The advantage is not invisibility.

It is reduced central coordination and easier infrastructure replacement.

Access keys make small-team administration practical

Running a proxy is easy enough. Running one for several people without sharing a single permanent secret is where administration usually becomes annoying.

Outline Manager generates unique access keys. Each key contains the connection information and credentials required by an Outline Client. Keys can be named, revoked individually, and assigned data limits.

That gives a small team a reasonable lifecycle:

Deploy one server.
Create a key for each person or device.
Distribute each key through a trusted channel.
Revoke a key when a device is lost or someone leaves.
Apply a data limit if one user is consuming too much bandwidth.
Replace the server and redistribute keys if the endpoint is blocked.

Do not create one key called team and send it to everyone.

Individual keys make revocation possible without disconnecting the rest of the group. They also make usage easier to manage. An access key should be treated like a password because anyone who obtains it can use the associated server allocation until the key is revoked.

Outline Server also exposes a management REST API used for access-key administration. That can be useful to a service provider or a team automating provisioning, but the management API URL contains a secret path and must be protected accordingly. It should not be published, committed to a repository, or exposed casually to the internet.

For most individuals, the Manager application is the safer and simpler interface.

Running your own Outline server

Outline Manager is available for Windows, macOS, and Linux. The Client is available across desktop and mobile platforms, including Windows, macOS, Linux, ChromeOS, Android, and iOS.

Deployment usually follows one of two paths.

Use an integrated cloud provider

The Manager can guide users through creating infrastructure with supported cloud providers. The exact onboarding flow depends on the provider and may require a provider account, payment method, and authorization.

This is the easiest approach because the application handles much of the server setup.

Bring your own Linux server

Outline can also be installed on compatible Linux infrastructure you already control. This is useful when:

You prefer a particular VPS provider.
You need a region not offered through an integrated flow.
You already operate Linux servers.
You want billing separated from the Manager.
A widely used provider or IP range performs poorly on your target network.

The official server repository documents a Linux installation command. Since installation commands can change, copying the current command from the repository is safer than relying on an old blog post.

The installer uses Docker, configures the Outline server components, and returns management information that can be imported into Outline Manager.

That convenience is valuable, but it does not remove systems administration. The VPS still needs a maintained operating system, restricted SSH access, timely security updates, firewall rules, monitoring, backups of essential configuration, and some plan for replacing the machine.

If the server is compromised, the fact that it was “self-hosted” will not help.

What does an Outline server actually cost?

The Outline software is free and open source. The recurring cost is normally the VPS and its bandwidth.

Outline’s official getting-started documentation says many cloud providers offer suitable plans for USD 5 per month or less. At USD 5 per month, the simple annual infrastructure cost is USD 60 before taxes, overage charges, backups, snapshots, or additional servers.

That is in the same general range as many consumer VPN subscriptions, but the billing model is different.

A conventional VPN subscription usually includes:

A large server network
Multiple regions
Provider-managed maintenance
Customer support
Bandwidth under the provider’s fair-use terms
Rapid switching between existing endpoints

A small VPS usually includes:

One public server
One geographic region
A defined traffic allowance
An operator-controlled IP address
Your responsibility for maintenance
Possible transfer overage charges

For one developer, a small server may be inexpensive but not necessarily cheaper than a discounted multi-year VPN plan.

For a trusted group of five people, the same USD 5 server may be economical, assuming its CPU, memory, network performance, and transfer allowance are adequate. If the group consumes several terabytes of traffic, bandwidth becomes the real price.

A better calculation is:

monthly cost =
    VPS plan
    + outbound transfer overages
    + backups or snapshots
    + replacement infrastructure
    + administrator time

The final item is easy to ignore.

If you spend two hours every month maintaining a USD 5 server, this is no longer a USD 5 solution in any meaningful business sense.

Where Outline makes sense for developers

Outline is a particularly good fit when the problem is not “I want 100 countries in a location menu.”

The problem is “I need one connection I can control.”

A developer working from a filtered network may need stable access to package registries, source repositories, documentation, issue trackers, AI tools, or an API that is unreachable locally. A private server gives that developer a known exit point without depending entirely on a commercial VPN’s public fleet.

A small engineering team can create one key per member, set limits, and revoke access individually. If the address becomes unusable on a particular network, the administrator can move the server and issue new credentials.

A technical founder may also prefer not to place the team’s browsing traffic through an unknown free VPN or a public server used by thousands of strangers. A private server reduces unrelated users sharing the same exit IP, which can also mean fewer reputation problems and fewer CAPTCHA storms.

There is one important boundary.

Outline is primarily an internet access and circumvention tool. It is not automatically a complete corporate secure-access platform.

If engineers need access to private production subnets, device posture checks, identity-based policy, SSO, audit trails, application-level authorization, or site-to-site routing, a system designed for zero-trust access or enterprise networking may be more appropriate.

“Secure remote access” can mean two different things:

Safely reaching the public internet through a controlled exit server
Reaching internal company resources under corporate access policy

Outline is much closer to the first.

Privacy improves in some places and gets worse in others

With a commercial VPN, trust moves from the ISP to the VPN provider.

With Outline, trust moves from the ISP to infrastructure you administer, plus the hosting company providing the server.

Your ISP can see that you are communicating with the VPS. The hosting provider can associate the server with your account and payment details. Websites see the server’s IP address. Applications can still identify you through logins, cookies, browser fingerprinting, telemetry, and account activity.

Outline encrypts traffic between the client and the server. It does not make you anonymous.

It also does not protect traffic after it leaves the server except where the application itself uses end-to-end encryption such as HTTPS. Fortunately, most developer services use HTTPS, but the distinction still matters.

Self-hosting gives you control over access keys and server selection. It also gives you responsibility for:

Protecting the cloud account
Using strong SSH authentication
Installing security updates
Restricting the management interface
Rotating compromised keys
Monitoring unusual bandwidth use
Handling abuse reports
Deleting abandoned infrastructure
Understanding the legal rules affecting the server location

This is control in the engineering sense.

You get more knobs because you also inherit more failure modes.

Why I think Outline is worth exploring

Most VPN comparisons obsess over server counts, streaming catalogs, and promotional subscription prices.

Those things matter to consumers. They matter much less when the actual failure is architectural.

If a restrictive network can identify a provider, enumerate its infrastructure, and block the same endpoints for millions of users, adding another city to the provider’s location list does not solve the core problem.

Outline takes a different approach:

Make small, private servers easy enough that people can operate their own infrastructure.

The project combines a blocking-resistant Shadowsocks-based transport, private distribution of server credentials, per-user access keys, manageable deployment, open-source clients, and replaceable infrastructure.

None of those features guarantees access. Together, they make adaptation more practical.

That is the strongest reason for a developer to consider GetOutline. Not because it is a magical VPN that cannot be blocked, and not because self-hosting is always better.

It is worth considering because it changes who owns the server, who knows its address, who controls access, and who can replace it when the network changes.

In an ordinary network, that may be unnecessary work.

In a network where conventional VPN services are repeatedly filtered or disrupted, it may be exactly the point.

Sources

Internet Regulation Is Making Users Easier to Track, Not Cybercriminals Harder to Stop

David Timothy — Sun, 06 Sep 2026 17:33:56 +0000

The modern internet safety pitch sounds reasonable enough: verify more identities, retain more metadata, monitor more content, require more accounts, and give platforms stronger obligations to identify risky users.

Then cybercrime will become harder.

At least, that’s the theory.

I’m not convinced the theory survives contact with the actual threat model.

The strongest internet controls are usually enforced at the compliant edge of the network. They affect people visiting mainstream websites, developers running legitimate services, businesses operating in regulated markets, and users who don’t want to break the law.

Professional cybercriminals don’t stay at that edge.

They use stolen accounts, compromised devices, encrypted channels, residential proxies, offshore infrastructure, disposable domains, synthetic identities, money mules, cryptocurrency laundering services, and crime-as-a-service marketplaces. When one route closes, they move to another. When one platform tightens its rules, they migrate. When identity checks become mandatory, stolen identity data becomes more valuable.

That doesn’t mean regulation never works. It means we’re often regulating the population that’s easiest to regulate while describing the result as a victory over the population that’s hardest to regulate.

The uncomfortable version is much simpler:

Cybercriminals adapt. Ordinary users get monitored.

That’s an editorial thesis, not a universal law. Some controls do stop abuse. Some investigations depend on retained records. Some age checks appear to deter minors from reaching harmful content. There are legitimate reasons to regulate online services.

But if the goal is reducing cybercrime, we should be brutally honest about who is bearing the cost, what threat is actually being addressed, and whether the control reaches determined adversaries at all.

We keep combining completely different threat models

A basic mistake runs through a lot of internet regulation: policymakers use “online safety” as a bucket for problems that have almost nothing in common technically.

Consider the differences:

A teenager trying to access age-restricted content
A ransomware affiliate exploiting an unpatched VPN appliance
A fraud ring running thousands of AI-assisted phishing messages
A person posting illegal material on a mainstream platform
A botnet operator controlling compromised home routers
An adult anonymously viewing lawful but sensitive content
A state-backed group stealing credentials from government employees

These aren’t variations of the same problem.

They involve different adversaries, capabilities, incentives, infrastructure, and failure modes. They require different defenses.

Age assurance might deter a teenager who reaches a mainstream site and sees a verification screen. It doesn’t stop a ransomware operator from buying initial access to a corporate network.

Mandatory accounts can make casual platform abuse more inconvenient. They don’t reliably identify an attacker using stolen credentials, fake documents, an infected machine, or a recruited account holder.

Mass data retention can give investigators useful historical records. It doesn’t patch vulnerable software, block credential theft, secure a supply chain, or prevent someone from authorizing a fraudulent wire transfer.

Content monitoring may remove illegal material from a cooperating platform. It doesn’t automatically eliminate the material from encrypted groups, self-hosted services, obscure forums, or infrastructure outside the regulator’s reach.

This distinction matters because governments can introduce a very visible control and then let the public assume it addresses a much broader security problem.

An identity prompt feels like security. A blocked page looks like enforcement. A removed account becomes a measurable platform action.

None of those things necessarily tell us whether serious cybercrime has declined.

Cybercrime is not showing signs of being regulated into submission

The FBI’s Internet Crime Complaint Center received more than one million complaints in 2025, with reported losses of roughly USD 20.9 billion. That represented a 26 percent increase in reported losses from 2024.

Those figures don’t measure all cybercrime. They’re based on reported complaints, reporting behavior can change, and the numbers don’t prove that internet controls caused or failed to prevent any particular crime.

Still, they make one point difficult to avoid: expanding digital regulation has not been accompanied by an obvious collapse in online fraud, phishing, extortion, data theft, or investment scams.

Europol’s 2026 cybercrime assessment describes a criminal environment built around encrypted communications, proxy services, cryptocurrencies, automation, specialized marketplaces, and rapidly shifting infrastructure. Dark web markets and forums remain resilient even after law enforcement disruptions because participants fragment, migrate, and regroup.

ENISA has reported a similar pattern around ransomware. Disrupted ransomware-as-a-service brands are quickly replaced, leaked builders lower the barrier to entry, and operators continuously update their tooling. Attackers now buy specialized services for access, malware delivery, credential theft, endpoint defense evasion, hosting, negotiation, and money laundering.

This is what an adaptive adversary looks like.

A cybercrime operation doesn’t need every component to survive. It needs replaceable components.

Take down a forum, and users move to another forum or an encrypted channel. Seize a domain, and the operator rotates domains. Block a hosting provider, and the infrastructure moves. Freeze one wallet, and laundering services split funds across new wallets, assets, exchanges, and jurisdictions.

Law enforcement operations still matter. Disruption imposes costs, generates intelligence, creates distrust inside criminal communities, protects potential victims, and sometimes leads to arrests. I’m not arguing that enforcement is pointless.

I’m arguing that a temporary disruption shouldn’t be confused with eliminating the ecosystem.

Meanwhile, the ordinary user isn’t operating a replaceable international infrastructure stack. That user has one phone number, one home connection, one government identity, a few mainstream accounts, and a limited willingness to fight an automated moderation or verification system.

The criminal can rotate infrastructure.

The user becomes the infrastructure being measured.

Age verification shows the problem in miniature

Age assurance is probably the clearest example of both sides of this debate being partly right.

Protecting children from pornography and other harmful content is a legitimate goal. Pretending that an “I’m over 18” button accomplishes that goal is obviously weak. If a service is legally restricted by age, some kind of meaningful age check can make sense.

The United Kingdom’s Online Safety Act brought major age-assurance requirements into force in 2025. Services covered by the rules must use highly effective methods to prevent children from accessing pornography and certain other harmful content.

Ofcom’s first major assessment, published in July 2026, found evidence that these checks can work. More than 69 million age checks were completed across a sample of 32 services between July and December 2025. By June 2026, all of the UK’s ten most popular pornography services and 64 of the top 100 had introduced age checks. Some children appeared to be deterred when they reached a protected service.

That’s real evidence in favor of regulation. It shouldn’t be dismissed.

But the same report exposes the displacement problem.

Almost half of the pornography services visited by children in Ofcom’s research had no age checks. Search engines continued to surface unprotected sites. Compliant services lost traffic while some services without checks gained popularity.

The control changed the path. It didn’t eliminate all alternate paths.

VPN usage also rose sharply after the requirements took effect. Ofcom estimated that daily UK VPN users increased from around 1.2 million before July 25, 2025, to 2.2 million afterward. The regulator correctly warned that this correlation doesn’t reveal how much of the increase was caused by age-check circumvention, or how many of those users were children.

That caveat is important. “VPN usage increased” is not the same as “everybody bypassed the law.”

Ofcom’s research found relatively low self-reported circumvention, though it also acknowledged possible response bias. It found that some determined children were using VPNs, borrowed credentials, spoofed images, and other techniques to get around controls. There wasn’t enough evidence to determine the full scale.

So the honest conclusion isn’t that age verification is useless. It’s that it works best against users who accept the default path.

That category includes plenty of minors, which may justify the intervention. It also includes practically every ordinary adult who now has to decide whether to give a website or verification vendor a face scan, payment signal, identity document, phone number, or reusable credential.

The bypass cost is unevenly distributed.

A determined user needs to find one weak site, one effective VPN, one reusable account, or one verification workaround.

A compliant platform has to verify everyone.

Identity verification creates a second security problem

There’s a recurring assumption that if an online account is connected to a real identity, abuse becomes easy to stop.

That’s far too optimistic.

Identity proofing answers a narrow question: does the person completing this process appear to control acceptable evidence associated with an identity?

It doesn’t answer:

Is this person acting voluntarily?
Was the identity evidence stolen?
Is someone controlling the device remotely?
Is the account being created for resale?
Is the user working as a money mule?
Will the account be compromised tomorrow?
Is the person legally identified but still malicious?

A verified identity is not the same thing as a trustworthy identity.

Banks already perform extensive know-your-customer checks, yet criminals continue to access financial systems through stolen identities, synthetic identities, compromised accounts, shell companies, recruited intermediaries, and legitimate account holders deceived into moving money.

The more identity checks we require, the more valuable the supporting data becomes.

Now the platform or its vendor may hold combinations of:

Government ID images
Facial images or biometric templates
Birth dates
Addresses
Phone numbers
IP addresses
Device attributes
Account histories
Verification results
Support conversations
Payment details

That collection becomes an attractive target because it can be used to defeat identity systems elsewhere.

This isn’t a hypothetical architectural concern. In October 2025, Discord disclosed that an attacker compromised a third-party customer service provider. Discord estimated that approximately 70,000 users may have had government ID photos exposed. Those images had been used for age-related appeals.

The verification system wasn’t intended to create a cybercrime opportunity. It was intended to support trust and safety. But the collected evidence became part of the attack surface anyway.

This is the part that too many policy debates skip. Every new requirement to collect sensitive information creates a new obligation to secure it, restrict access to it, define retention periods, audit vendors, process deletion requests, handle appeals, and respond to breaches.

Security teams understand this instinctively:

Data you don’t collect can’t be stolen from your database.

NIST’s current digital identity guidance treats privacy risk assessment, data minimization, retention, third-party processing, redress, and encryption as core requirements. That’s good engineering guidance, but it also confirms the underlying point. Identity proofing introduces risks serious enough to require an entire control framework of its own.

We’re creating sensitive data systems to enforce safety rules, then creating more safety rules to protect the sensitive data systems.

At some point, it’s fair to ask whether the architecture is reducing total risk or relocating it.

Metadata surveillance is still surveillance

Another popular argument says that retaining metadata is less invasive than inspecting content.

Technically, that distinction is real. The body of a message is different from the time, location, participants, device, account, and network information associated with it.

In practice, metadata can reveal an enormous amount.

Imagine a system that records:

Which IP address used an account
When each session started
Which device identifiers were present
Which phone number recovered the account
Which accounts interacted
Which locations appeared over time
Which services received authentication requests

No individual record tells the whole story. Correlation does.

Put those records into a graph and patterns emerge: relationships, routines, workplaces, travel, medical visits, political activity, religious participation, romantic connections, and anonymous accounts tied to known identities.

The privacy risk doesn’t begin when a government employee manually opens a file. It begins when the dataset is created and made linkable.

European courts have repeatedly wrestled with this issue. The Court of Justice of the European Union has restricted general and indiscriminate retention of traffic and location data, while allowing more targeted retention and certain carefully constrained treatment of IP addresses and civil identity data.

The legal details are complicated, but the technical concern is straightforward. Large collections of communications metadata can support precise conclusions about private life, especially when multiple categories of data are combined.

There is a legitimate counterargument here. Investigators often need historical records. A victim may report an attack weeks after the initial intrusion. Infrastructure logs can connect accounts, domains, IP addresses, payments, and devices. Without preserved evidence, attribution may be impossible.

The choice, though, isn’t simply “retain everything” or “delete every log immediately.”

There’s a meaningful difference between:

Targeted preservation tied to an investigation
Time-limited operational security logs
Emergency preservation orders
Retention based on documented risk
General collection covering an entire population
Indefinite cross-platform identity correlation

A democratic government can have lawful investigative powers without treating every user as a future query result.

The standard should be necessity and proportionality, not “this data might be useful someday.”

Developers are becoming an unofficial enforcement layer

Internet regulation doesn’t execute itself. Developers turn policy into databases, APIs, classifiers, logging pipelines, review queues, account states, geolocation rules, and access-control decisions.

That creates consequences far beyond large platforms.

A major company can hire policy teams, trust and safety specialists, privacy lawyers, vendor auditors, appeals staff, and regional compliance engineers. A small forum, open-source community, indie service, or niche social application may have none of that.

When compliance becomes too expensive or legally uncertain, smaller services tend to choose from a short list of bad options:

Block users in the affected jurisdiction
Require accounts where none were previously needed
Outsource identity checks to another company
Collect more data to prove compliance
Remove broad categories of lawful content
Shut down user-generated features
Close the service

That shifts power toward the largest platforms because they’re the organizations most capable of operating a global verification and surveillance stack.

It also encourages over-enforcement.

If a platform faces severe penalties for under-blocking but little consequence for over-blocking, the rational engineering decision is predictable. Set conservative thresholds. Collect additional signals. Restrict ambiguous content. Lock questionable accounts. Make users appeal.

False positives become somebody else’s problem.

For an ordinary user, “somebody else” means being unable to access an account, publish lawful content, use a privacy tool, or participate without providing more personal information.

For a criminal operation, a false positive means burning one account and loading another.

Again, the burden isn’t symmetrical.

Safety controls aren’t useless, but they need to match the adversary

It would be easy to turn this into an argument against all regulation, all logging, or all identity verification. I don’t think that position holds up.

Age checks can deter access.

Platform moderation can remove abusive material.

Financial identity requirements can make laundering more difficult.

Logs can help investigators reconstruct attacks.

Infrastructure seizures can interrupt criminal operations.

Account verification can increase the cost of spam and coordinated abuse.

The problem is not that controls never work. The problem is expanding them without measuring substitution, displacement, privacy loss, market concentration, and adversarial adaptation.

A useful security control should be evaluated against the attacker’s next move, not just the attacker’s current move.

If a regulated site introduces age checks, do users migrate to unregulated sites?

If a platform requires government ID, does the market for stolen verified accounts expand?

If a country blocks a service, do users move to encrypted or offshore alternatives?

If providers retain more identifying data, does that dataset become a new extortion target?

If automated monitoring produces large numbers of false positives, can users realistically appeal?

If a ransomware brand is disrupted, how quickly are its affiliates absorbed by another operation?

These aren’t arguments for doing nothing. They’re the questions that should determine whether a control is actually working.

We can verify eligibility without building an identity panopticon

From a developer’s perspective, one of the most frustrating parts of this debate is that privacy and verification aren’t always opposites.

A service may need to know that a user is over 18. It usually doesn’t need the user’s full name, exact birth date, home address, document number, and identity photo.

That difference should drive the architecture.

W3C’s Verifiable Credentials model explicitly recommends abstract claims such as ageOver instead of exposing a date of birth. Selective-disclosure systems can allow a user to reveal a required attribute without handing every verifier the underlying identity record.

A more privacy-preserving age flow could look like this:

A trusted issuer verifies the user’s age.
The user receives a cryptographically protected credential.
A website requests proof that the user is above a threshold.
The user presents only that age claim.
The website validates the proof without receiving the original identity document.

That’s better than uploading a passport to every site.

It still isn’t magically anonymous. Long-lived identifiers can allow correlation. Centralized status checks can reveal where credentials are used. Browser fingerprinting, account cookies, IP addresses, and payment data can reconnect a supposedly minimal credential to a persistent profile.

Cryptography can reduce disclosure. It can’t compensate for a system designed to correlate people everywhere.

Privacy-preserving regulation therefore needs both technical and legal limits:

Collect the minimum attribute required
Avoid persistent cross-site identifiers
Prohibit unrelated reuse of verification data
Keep identity documents away from content platforms
Use short retention periods
Require independent security testing
Publish false-positive and appeal statistics
Make vendors directly accountable for breaches
Support anonymous or pseudonymous access where identity isn’t necessary
Require evidence that a measure reduces the targeted harm
Add sunset clauses when that evidence never appears

Most importantly, governments should focus more aggressively on the infrastructure and economics of cybercrime itself.

That means faster patching of public systems, secure software procurement, ransomware-resistant backups, disruption of bulletproof hosting, action against laundering networks, international evidence sharing, recovery of stolen funds, stronger authentication, anti-spoofing improvements, and support for victims.

Those measures aren’t as politically visible as an ID screen. They’re also much closer to the systems criminals actually depend on.

The safest internet is not automatically the most identifiable one

The debate over internet control is often framed as safety versus chaos.

That’s a false choice.

The real question is what kind of safety we’re buying, who pays for it, and what infrastructure of control remains after the original crisis has passed.

A narrowly designed age check may protect children. A targeted preservation order may help catch an attacker. A properly scoped platform rule may reduce abuse.

But those limited successes don’t justify turning identity collection, behavioral monitoring, metadata retention, and cross-platform enforcement into the default architecture of the internet.

Once that architecture exists, it won’t only be used against ransomware gangs and fraud networks. It will shape how everyone accesses information, speaks, builds communities, distributes software, and participates online.

Sophisticated criminals will keep searching for the weakest jurisdiction, the easiest victim, the next stolen account, and the newest bypass.

Ordinary users will keep using the services in front of them.

That’s the disconnect I think we need to confront. Governments can make the compliant internet dramatically more observable without making the criminal internet equally transparent.

So when the next safety proposal arrives, I don’t just want to hear how many identities it can verify, how much data it can retain, or how many accounts it can block.

I want a clear answer to the harder question:

Are we making cybercrime harder, or are we mainly making ordinary people easier to watch?

Sources

Windows Is Getting Worse. So Why Does Linux Still Suck in 2026?

David Timothy — Sun, 06 Sep 2026 03:02:20 +0000

It is 2026, Windows is becoming increasingly hostile to people who just want a predictable computer, and Linux still cannot close the deal.

That is absurd.

Windows 10 reached the end of normal support on October 14, 2025. Microsoft’s preferred answer is Windows 11, an operating system that increasingly feels like a delivery platform for Microsoft accounts, OneDrive, Copilot, recommendations, telemetry, subscriptions, and whatever AI feature was approved during last Tuesday’s product meeting.

Microsoft has openly described its goal as making every Windows 11 PC an AI PC.

Fine. Great. Wonderful.

But what if I do not want an AI PC?

What if I just want an operating system that launches applications, manages files, drives my hardware, stays out of the way, and does not treat every empty surface as an opportunity to recommend another Microsoft product?

This should be Linux’s moment.

Windows users are annoyed. Developers are tired of being nudged toward cloud accounts and ecosystem integrations. Power users are spending more time disabling things they never requested. Microsoft keeps adding layers to an operating system that already contains multiple generations of UI, configuration tools, compatibility systems, and historical baggage.

Linux should be standing there with a clean desktop, excellent hardware support, reliable applications, and a simple migration story.

Instead, it is standing there holding five package formats and asking which display server I use.

Windows is becoming the operating system nobody asked for

Windows is still extremely capable. That is part of what makes its current direction so frustrating.

It runs practically every mainstream desktop application. Hardware manufacturers target it first. Drivers generally arrive through a coordinated distribution channel. Gaming support is excellent. Development tooling is strong, and WSL gives developers a real Linux environment without leaving Windows.

The foundation is not the problem.

The problem is that Microsoft seems incapable of leaving the foundation alone.

Windows 11 increasingly wants to be involved in everything. It wants to connect your account, back up your folders to OneDrive, personalize recommendations, track application launches to improve Start, assign an advertising identifier, suggest content in Settings, and place Copilot at the center of the experience.

Many of these features can be disabled. Some are opt-in. Some have reasonable technical justifications. Recall, for example, now requires users to opt in, stores snapshots locally, encrypts its data, and uses Windows Hello protection.

That matters. Criticism should be accurate.

But the broader direction still sucks.

The problem is not that every individual feature is secretly evil. The problem is that the operating system has stopped acting like neutral infrastructure. It is becoming an opinionated client for Microsoft’s services.

Even the initial setup process makes the relationship clear. Windows 11 Home and Windows 11 Pro for personal use require internet connectivity and a Microsoft account during initial setup. Windows Backup is centered around that account and OneDrive. Device usage settings can influence the tips, recommendations, offers, and personalized ads shown to users.

You bought a computer. Microsoft sees an onboarding opportunity.

There is a difference between an operating system supporting cloud services and an operating system constantly trying to turn local computing into an extension of a cloud account. Windows keeps drifting toward the second model.

Developers notice this because developers tend to care about ownership, reproducibility, configuration, and boundaries. We know what a local file is. We know what a background service is. We know that “personalization” usually means data collection followed by somebody trying to sell us something.

We also know how ridiculous it is to buy a powerful machine and then spend the first hour removing widgets, disabling suggestions, rejecting cloud backup, changing privacy settings, uninstalling bundled applications, and making the Start menu less annoying.

The usual response is that power users can configure Windows however they want.

That misses the point.

A good operating system should not require a cleanup script before it becomes tolerable.

Linux should win this argument without trying

On paper, Linux is almost comically well positioned.

It is open source. It can run without a mandatory cloud account. It does not need an advertising identifier. It gives users meaningful control over updates, services, filesystems, networking, security, and the entire software stack.

For developers, the underlying environment is fantastic.

Package managers are scriptable. Containers fit naturally. SSH is normal rather than an optional feature somebody remembered to add. Filesystem behavior is predictable. Most deployment targets are already Linux. The shell is not treated like an embarrassing historical utility hidden behind a graphical interface.

Linux is also technically mature in ways that are easy to underestimate. The kernel supports an enormous range of hardware and workloads. Linux runs servers, cloud infrastructure, supercomputers, embedded systems, routers, phones, appliances, and a disturbing number of devices whose owners have no idea Linux is inside them.

This is not a toy operating system.

And yet the Linux desktop still feels like a collection of impressive components that occasionally agree to impersonate a product.

That is the gap.

Linux is technically powerful. A Linux desktop can be excellent. Neither statement means Linux is a genuinely great mainstream desktop operating system.

There is no Linux desktop

People talk about “the Linux desktop” as if it were one thing.

It is not.

Is the Linux desktop Ubuntu with GNOME and Snap?

Is it Fedora Workstation with GNOME, RPM, DNF, and Flatpak?

Is it Kubuntu with KDE Plasma?

Is it Linux Mint with Cinnamon?

Is it Arch with whatever the user assembled at 2:00 in the morning after reading six wiki pages?

Is it an immutable Fedora variant using image-based system updates, Flatpak applications, and containers for development tools?

These systems share a kernel and a lot of userspace technology, but that does not make them one desktop platform.

A Windows application developer targets Windows. A macOS application developer targets macOS. A Linux application developer targets a decision tree.

Which distributions?

Which versions?

Which package formats?

Which desktop environments?

Which display protocols?

Which portal implementations?

Which versions of system libraries?

Which filesystem layout assumptions?

Which sandbox permissions?

Which theme behavior?

Which installer story?

Linux supporters often call this choice.

Application developers call it support cost.

That distinction matters because fragmentation does not merely affect enthusiasts choosing a distribution. It affects every company deciding whether Linux desktop support is worth funding.

Adobe’s Creative Cloud desktop application still officially targets Windows and macOS, not Linux. That is not because Linux is technically incapable of editing an image. It is because “support Linux” means taking responsibility for a fragmented platform with a relatively small desktop market.

Linux users then blame Adobe, sometimes correctly, for refusing to support Linux. Adobe can blame the market and platform complexity. Distribution maintainers can say proprietary applications should use Flatpak. Flatpak developers can point to portals and sandboxing. Desktop projects can implement different portal backends.

Everyone has a technically defensible explanation.

The user still does not have Photoshop.

Choice becomes a tax when nobody owns the final experience

Choice is one of Linux’s greatest strengths. It is also one of the main reasons Linux has not produced an obvious Windows replacement.

Those two ideas are not contradictory.

Choice is excellent when I am intentionally building a system around my requirements. It is less excellent when I am trying to install an application and the official instructions begin with “Select your distribution.”

Even basic software installation can involve several parallel systems:

# Debian or Ubuntu
sudo apt install vlc

# Fedora
sudo dnf install vlc

# Arch Linux
sudo pacman -S vlc

# Flatpak
flatpak install flathub org.videolan.VLC

# Snap
sudo snap install vlc

A Linux enthusiast sees flexibility.

A normal user sees five answers to a one-answer question.

The commands are not the real problem. Most users can click an Install button in a graphical software center. The deeper issue is that these methods have different maintainers, update behavior, sandbox rules, integration details, permissions, dependency models, and failure modes.

Install the repository package and it may be old.

Install a third-party repository and now that repository participates in system updates.

Install a Flatpak and filesystem access may behave differently because the application is sandboxed.

Install a Snap and startup, theming, integration, or policy decisions may differ from the native package.

Download an AppImage and updates become the application’s problem.

Build from source and congratulations, you are now part of the package management system.

Flatpak is probably the closest thing Linux has to a credible cross-distribution desktop application model. Its runtimes, repositories, sandboxing, and portals solve real problems.

They also reveal how complicated the Linux desktop is.

XDG Desktop Portal exists partly because a sandboxed application needs a common way to request files, open links, print documents, capture screens, send notifications, and interact with the host desktop. The portal then relies on desktop-specific backends for GNOME, KDE, LXQt, wlroots, Cinnamon, and others.

That is smart engineering. It is also a compatibility layer designed to make several different desktops behave enough like one platform.

Linux keeps building infrastructure to compensate for the fact that nobody controls the whole experience.

Desktop environments are products built on shifting ground

GNOME and KDE Plasma are both serious desktop environments. They are not amateur projects stapled to a terminal. Both can provide attractive, productive, modern systems.

They also have different design philosophies, release schedules, extension models, configuration systems, default applications, and approaches to user customization.

GNOME tends to have strong opinions about how the desktop should work. KDE tends to expose enough settings to let users negotiate a peace treaty with every pixel.

Neither approach is inherently wrong.

The problem is that application behavior and integration can still depend on which environment is running underneath. File pickers, notifications, global shortcuts, screen sharing, theming, tray icons, window decorations, fractional scaling, and default application behavior can vary.

Standards exist. Freedesktop.org has spent years producing specifications for interoperability between desktop environments.

But it is not a formal standards body, and projects are not required to implement every specification.

That sentence explains a significant chunk of the Linux desktop experience.

There is a specification. Implementation varies. Your distribution packages a particular version. Your desktop environment supports most of it. Your application toolkit handles some of it. A portal handles another part. A compositor-specific protocol handles something else.

When it works, it is invisible.

When it does not, the user ends up searching for an issue containing the words “Wayland,” “portal,” “PipeWire,” “GTK,” “Qt,” and “environment variable.”

This is not what an obvious Windows alternative looks like.

Hardware support is excellent until it suddenly isn’t

Linux hardware support has improved enormously. On the right machine, installation can be almost boring. The kernel already contains drivers, the installer detects the hardware, Wi-Fi works, audio works, suspend works, and the desktop appears.

That is the good version.

The bad version is one component that technically works but not quite correctly.

Maybe suspend drains the battery.

Maybe the fingerprint reader is unsupported.

Maybe the webcam’s advanced features require vendor software available only on Windows.

Maybe switching between integrated and discrete graphics is awkward.

Maybe an external monitor behaves strangely after sleep.

Maybe the function keys do not map correctly.

Maybe the Wi-Fi chipset needs newer firmware than the distribution shipped.

Maybe the machine boots and runs perfectly, except the microphone array sounds terrible because the vendor’s audio processing stack only exists for Windows.

This is where Linux’s huge hardware support story becomes misleading.

Supporting a hardware device is not always the same thing as supporting the complete product experience.

A laptop is not just a CPU, GPU, storage device, and generic keyboard. It includes firmware, power management, thermal profiles, biometric devices, camera processing, audio tuning, docking behavior, special buttons, GPU switching, and vendor-specific quirks.

Windows benefits from an established hardware certification and driver distribution system. Manufacturers design, test, certify, and distribute Windows drivers through infrastructure built for that purpose.

Linux support often depends on drivers reaching the upstream kernel, firmware being redistributable, vendors participating in projects such as the Linux Vendor Firmware Service, and distributions shipping compatible versions at the right time.

The upstream kernel model has major advantages. A driver in the main kernel tree can be maintained alongside kernel changes. That is usually better than leaving users dependent on an abandoned binary blob.

But it also means out-of-tree drivers live a dangerous life. Linux intentionally does not promise a stable internal kernel interface for drivers. If a proprietary or external module is not kept current, a kernel update can expose the problem.

The usual advice is to buy hardware known to work with Linux.

That is sensible advice.

It is also an admission that Linux is not a drop-in alternative for the general PC market.

An operating system cannot become the default escape route from Windows if the migration checklist starts with researching whether the laptop’s sleep behavior is broken.

NVIDIA is not the whole hardware problem

Linux desktop discussions have spent years using NVIDIA as shorthand for every driver problem.

That is too simple now.

NVIDIA’s Linux support has changed significantly, and the company has increased its participation in Linux firmware infrastructure. AMD and Intel graphics can also provide excellent experiences. Modern distributions automate much more of the setup than they used to.

Still, graphics on Linux demonstrates the broader platform problem.

The user is not merely choosing a GPU. The final result can depend on the kernel, Mesa version, proprietary driver version, distribution packaging, display server, compositor, laptop GPU topology, firmware, and application.

When something goes wrong, every layer has just enough responsibility to make diagnosis annoying.

Windows has complicated graphics architecture too. The difference is that users usually experience it as one supported vendor path: install the vendor’s Windows driver or let Windows Update do it.

On Linux, the technically correct solution may depend on whether the driver is in the kernel, distributed as a package, built through DKMS, bundled in the distribution, delivered by a third-party repository, or waiting for a newer kernel.

That complexity is manageable for experienced users.

“Manageable for experienced users” is not the standard Linux needs to meet.

Linux gaming is a miracle, not a guarantee

Gaming on Linux is dramatically better than it used to be.

Valve deserves a ridiculous amount of credit for that. Proton allows many Windows-only games to run on Linux through Wine and a stack of related compatibility components. Steam’s Linux runtime also reduces distribution differences by running games against controlled runtime environments.

This is impressive engineering.

It is also worth noticing what had to happen.

Linux did not win broad native game support. Instead, Valve built increasingly sophisticated infrastructure to run Windows games and isolate them from differences between Linux distributions.

Again, Linux’s biggest desktop success stories often involve building a stable platform on top of the unstable boundaries beneath it.

Many games now work with almost no effort. Some run surprisingly well. But compatibility still depends on the game, graphics drivers, Proton version, launchers, copy protection, middleware, anti-cheat systems, and updates from publishers that may never test Linux.

A game working today through a compatibility layer is not the same promise as the publisher officially supporting the platform.

For some users, current Linux gaming support is more than enough. For others, one incompatible multiplayer game or peripheral utility makes the entire migration impossible.

That last ten percent matters.

Desktop operating systems are not evaluated by averaging every feature. They are evaluated by the one required thing that does not work.

Application compatibility is still the wall

Developers can do a huge amount on Linux.

The major browsers are available. Editors such as Visual Studio Code have Linux versions. JetBrains supports Linux. Container tooling is excellent. Git, compilers, language runtimes, databases, terminals, and infrastructure tools are at home there.

If someone’s work happens entirely in a browser, terminal, editor, and containers, Linux can be a fantastic development machine.

But developers do not use their computers only for compiling code.

They join video calls. They edit documents sent by clients. They use VPN software selected by an employer. They configure mice, keyboards, audio interfaces, capture cards, and other peripherals. They run design tools. They test commercial desktop applications. They interact with corporate security software.

This is where “there is an open-source alternative” becomes an inadequate answer.

An alternative application is not necessarily compatible with a required workflow.

GIMP existing does not make it Photoshop.

LibreOffice opening a document does not guarantee perfect behavior with a complex Microsoft Office workflow.

A browser version of an application is not always equivalent to the native desktop version.

Wine successfully launching an application does not turn it into an officially supported application.

The Linux community often responds to missing software by arguing that users should change software.

Sometimes that is reasonable. Sometimes the alternative is genuinely better.

But it is not a migration strategy.

A real desktop alternative has to adapt to users before demanding that users adapt to it.

Linux configuration is freedom with an invoice attached

Linux gives users extraordinary control.

That freedom has a cost, and the Linux community is often weirdly reluctant to admit it.

Configuration is not free just because it does not cost money. It costs time, attention, and cognitive energy.

The ability to replace a compositor, rebuild a package, override a systemd unit, patch a kernel parameter, select a different scheduler, or change the entire desktop environment is valuable.

It is not a substitute for good defaults.

There is a persistent idea that Linux problems are acceptable because they are fixable. If the fix exists in a wiki, forum post, configuration file, or shell command, then apparently the operating system has done its job.

No.

An operating system that requires users to discover and apply the fix is still providing a worse experience than one that works correctly by default.

The command might be trivial:

sudo systemctl enable --now some-service

But the user first has to know:

Which service is missing.
Why it is not running.
What package provides it.
Whether enabling it is appropriate for the distribution.
Whether the advice applies to the current release.
Whether the command creates a security or maintenance problem later.

The command is the easy part.

Knowing that the command is necessary is the product failure.

Stability depends on which Linux you mean

Linux can be extremely stable.

Linux can also turn a routine update into an educational weekend.

Both statements are true because “Linux” covers systems with completely different update philosophies.

An enterprise distribution may preserve older package versions and backport fixes for years. An LTS desktop distribution may prioritize stability but ship older applications. A rolling-release distribution may provide newer kernels, drivers, and desktops while exposing users to more frequent integration changes.

Immutable and image-based distributions try to improve this situation. Atomic updates, rollback support, containerized development environments, and Flatpak applications create cleaner boundaries between the base operating system and user software.

This is promising. It may be the most credible direction for a dependable Linux desktop.

It also adds another model users and developers need to understand.

Should a development tool be installed as a native package, layered onto the system image, run inside a container, installed through a language version manager, or downloaded as a standalone binary?

There are good technical answers.

There are several of them.

Windows users may hate the registry, installer leftovers, and random background updaters. Linux users get to debate the architectural purity of six different installation methods.

Nobody wins.

WSL is a devastating argument against desktop Linux

WSL might be Microsoft’s best developer feature and Linux desktop’s most embarrassing competitor.

With one command, Windows can install a real Linux environment:

wsl --install

Developers can run Bash, Linux binaries, package managers, databases, containers, language toolchains, and even Linux GUI applications while keeping Windows hardware support and commercial software compatibility.

WSL has trade-offs. File placement matters because crossing between Windows and Linux filesystems can hurt I/O performance. Networking, permissions, virtualization, and tool integration can still introduce complexity.

But the value proposition is brutally effective:

Keep Windows for the desktop. Use Linux for the parts Linux is good at.

That arrangement removes one of the strongest reasons developers once had to move entirely to Linux.

It also exposes the uncomfortable truth at the center of this whole argument.

Linux has won development infrastructure. It has not won the desktop.

Microsoft understood that developers wanted Linux tools more than they necessarily wanted a Linux desktop. So Microsoft brought the tools into Windows.

That was a smarter product decision than waiting for everyone to switch operating systems.

The Linux desktop does not have an engineering problem

Linux desktop projects contain plenty of strong engineers.

The problem is product ownership.

No single organization owns the complete Linux desktop experience across hardware, drivers, firmware, installation, updates, applications, packaging, support, documentation, and long-term compatibility.

Canonical owns Ubuntu, not Linux.

Red Hat and the Fedora community shape Fedora, not Linux.

Valve controls SteamOS on selected hardware, not the general-purpose Linux desktop.

GNOME controls GNOME.

KDE controls KDE Plasma.

The kernel community controls the kernel.

Hardware vendors control their firmware.

Application vendors decide which distributions, package formats, and environments they will support.

Freedesktop.org defines interoperability specifications, but it cannot force universal implementation.

Everybody owns a piece. Nobody owns the result.

Windows has plenty of organizational dysfunction, but Microsoft can decide what Windows is. It can define a driver model, ship an SDK, certify hardware, distribute updates, establish UI APIs, and tell application developers what platform they are targeting.

Apple takes this even further by controlling the operating system, hardware, processor roadmap, major frameworks, application distribution, and much of the ecosystem.

Linux has coordination rather than control.

That model is fantastic for open infrastructure. It is much harder for a consumer desktop product, where thousands of tiny integration details determine whether the system feels coherent.

SteamOS proves Linux works when somebody actually curates it

The success of Linux in tightly controlled products should tell us something.

Linux works extremely well when someone defines the hardware, controls the system image, chooses the update model, establishes the application runtime, tests the complete product, and limits the number of supported configurations.

That is why Linux succeeds in servers, appliances, embedded devices, Android phones, Chromebooks, and game consoles.

The kernel is not the problem.

The endless matrix is the problem.

A curated Linux desktop running on certified hardware can be excellent. The manufacturer can validate suspend, graphics, audio, firmware updates, input devices, power management, and recovery. The distribution can ship one desktop environment, one application format, one update mechanism, and one support path.

But that stops looking like the traditional Linux desktop dream, where users freely combine distributions, desktops, kernels, package sources, filesystems, and hardware.

The freedom remains possible underneath. It just cannot define the default product.

Linux does not need fewer possibilities.

It needs one boring, dependable path through them.

We need a Linux desktop that is willing to be a product

The obvious response is to recommend a beginner-friendly distribution.

That helps, but it does not solve the ecosystem problem.

A polished installer and pleasant desktop theme cannot fix missing commercial applications, inconsistent vendor support, packaging fragmentation, or the absence of a standard support target.

What Linux needs is not another distribution with a slightly different dock.

It needs a credible desktop contract.

That contract would probably include:

A stable, long-lived application platform.
One preferred desktop application format.
Reliable graphical updates with rollback.
Strong sandboxing that does not constantly break integration.
A standard permission model users can understand.
Certified hardware with complete firmware and power-management support.
Consistent handling of files, links, notifications, shortcuts, screen sharing, and default applications.
A clear compatibility policy across operating-system releases.
Documentation that does not assume the user already knows which subsystem failed.
Enough commercial incentive for major application vendors to treat the platform seriously.

None of this requires eliminating the distributions and desktops that already exist.

It requires someone to say, “This is the supported desktop platform,” and then do the unglamorous integration work for a decade.

Not for one release.

Not until the maintainers get bored.

Not until a newer packaging system becomes fashionable.

A decade.

Desktop trust is built slowly and lost quickly.

I do not want Windows to win by default

That is the part that bothers me.

I do not think Windows is becoming better for developers and power users. It is becoming more capable in some areas while becoming more intrusive, cluttered, and ecosystem-driven in others.

Those are not the same thing.

Adding another AI surface does not make file management better.

Adding personalized recommendations does not make the Start menu more predictable.

Connecting more folders to OneDrive does not improve local ownership.

Requiring an online account does not make the operating system feel like mine.

Microsoft keeps building a future where Windows is a smart, personalized, cloud-connected assistant.

I want an operating system.

Linux should be the answer. Technically, it has nearly everything required. Politically and structurally, it does not.

The Linux desktop still asks users to accept too many caveats:

It is great if your hardware is supported.

It is great if your applications are available.

It is great if your games work through Proton.

It is great if your employer’s tools support it.

It is great if you choose the right distribution.

It is great if you do not mind occasional configuration archaeology.

That is too many “ifs” for an operating system that is supposed to replace Windows.

Linux enthusiasts will correctly point out that millions of people use Linux desktops productively every day. Some systems are polished. Some hardware combinations work beautifully. Some developers would never willingly return to Windows.

I am not arguing that Linux is unusable.

I am arguing that “usable” is an embarrassingly low target in 2026.

The standard should be obvious, cohesive, predictable, and boring.

Linux is powerful enough. The kernel is mature enough. The desktop environments are capable enough. The packaging technology is sophisticated enough. The community has spent decades solving difficult engineering problems.

And somehow, after all of that, a developer escaping an increasingly irritating Windows experience still has to choose between Microsoft’s product agenda and Linux’s integration lottery.

Why the hell are we still having this conversation in 2026?

Sources

I Never Touched AWS and I Still Ship: The Internet Doesn’t Need One Giant Cloud Stack

David Timothy — Fri, 04 Sep 2026 18:33:19 +0000

At some point, hosting a website became embarrassingly complicated.

You can’t just put files on a server anymore. Apparently, you need a cloud strategy. You need containers. You need orchestration. You need serverless functions talking to managed services through an API gateway while six dashboards monitor the cost of the dashboards monitoring the application.

And obviously, all of this should live inside AWS, Microsoft Azure, Google Cloud, or another enormous cloud platform.

Otherwise, are you even doing infrastructure?

I’ve been building and hosting websites for more than 20 years. I use traditional shared hosting for smaller websites and VPSs or dedicated servers for larger projects, depending on what the project actually needs.

I have never used AWS for my projects.

I have never used Azure, Google Cloud, or a similar hyperscale cloud platform for them either.

My projects have never depended on one of those platforms, and somehow, everything still works. Websites go online. Blogs load. Company presentation sites do their job. Clients can visit pages. The internet does not reject my deployments because they lack a sufficiently complicated architecture diagram.

This approach has saved me time and money.

That does not mean the giant cloud platforms are bad. They are extraordinary pieces of infrastructure, and plenty of companies have excellent reasons to use them.

But the automatic assumption that every modern project belongs inside the same tiny group of giant cloud providers is bizarre.

More importantly, it is helping create an internet that depends far too heavily on far too few companies.

The cloud became the default before anyone asked why

There is a huge difference between asking:

What infrastructure does this project need?

And asking:

Which cloud services should we use?

The second question has already made the biggest decision for you.

It assumes that the project belongs on a hyperscale platform. Now all that remains is choosing the products, wiring them together, configuring permissions, estimating costs, and pretending the resulting pile of dependencies is simpler because nobody has to physically touch a server.

This is how a straightforward website ends up with object storage, edge functions, a managed database, a managed cache, a managed queue, centralized logging, proprietary identity, an API gateway, a container registry, and an infrastructure-as-code repository large enough to require its own maintenance schedule.

Every individual decision can sound reasonable.

Storage as a service? Convenient.

Managed database? Convenient.

Authentication platform? Convenient.

Serverless functions? Convenient.

Global CDN? Convenient.

Managed Kubernetes? Convenient, assuming the alternative was unmanaged Kubernetes and not simply avoiding Kubernetes.

Add enough convenient services together and you eventually build a system nobody fully understands, hosted by a company you cannot realistically leave.

That might be justified for a large, complicated application. It is harder to justify for a blog.

The strange part is that we barely distinguish between those cases anymore. “Put it in the cloud” has become the default answer whether the project is a multinational software platform or a company website with an about page and a contact form.

Those are not the same infrastructure problem.

My stack changes because projects are different

I don’t have one universal hosting architecture.

That is the point.

For a small website, traditional shared hosting can be perfectly fine. It provides a place to host the site without requiring a dedicated server or turning a simple project into an infrastructure hobby.

If the project needs more resources or control, a VPS may make sense.

If the requirements justify dedicated hardware, a dedicated server is still a perfectly legitimate option.

The decision looks something like this:

What does this project actually need?

Small, straightforward website
    -> Shared hosting may be enough

More control, resources, or flexibility
    -> Consider a VPS

Requirements that justify dedicated resources
    -> Consider a dedicated server

Unusual scale, global distribution, specialized managed services
    -> A large cloud platform may make sense

Notice that the cloud platform is still there.

It just has to earn its place.

I don’t begin with the assumption that every project needs hyperscale infrastructure. I start with the project and work outward.

Most of what I host consists of websites, blogs, company presentation sites, and similar web projects. These are real projects, but they are not pretending to be Netflix. They need suitable infrastructure, not infinite theoretical scalability.

Apache is perfectly capable of serving these kinds of websites. Traditional hosting is perfectly capable of running them. A VPS can provide plenty of control when more control is actually needed.

CentOS was my favorite Linux distribution for many years. It did not make the infrastructure exciting. It made the infrastructure understandable, which is far more useful.

I also generally recommend control panels, especially for quick administrative actions and less experienced users. They are not mandatory, and they are not appropriate for every server, but dismissing them because “real developers use the command line” is mostly macho nonsense.

If a tool makes a legitimate administrative task quicker and clearer, it is useful.

Infrastructure should be selected with that same practical attitude.

Boring infrastructure has one enormous advantage

You can understand it.

That sounds almost too basic to mention, but understandability has become an underrated technical feature.

A traditional server setup has a relatively direct mental model:

There is a physical or virtual machine.
It runs an operating system.
A web server such as Apache handles requests.
The website or application runs there.
The machine has finite resources.
If the project outgrows those resources, something needs to change.

There are still plenty of ways to get this wrong. Servers require maintenance. Software needs updates. Security matters. Hardware and networks fail. Backups do not magically happen just because the architecture is simple.

But the core model is visible.

A modern cloud application can exist across dozens of products, each with its own configuration, permissions, logs, limits, pricing model, and failure behavior.

The application is no longer just the code. It is the code plus IAM policies plus cloud resources plus deployment configuration plus provider-specific networking plus managed-service settings plus whatever undocumented assumptions are hiding in the account.

At that point, nobody really “runs” the application.

People negotiate with it.

Complexity is sometimes unavoidable. But when a simple architecture can satisfy the requirements, choosing the complicated one is not automatically better engineering.

Sometimes it is just more engineering.

Complexity looks impressive, so we keep buying it

The technology industry rewards visible complexity.

A developer who says, “I put the website on a server,” does not sound particularly impressive.

A developer who says, “We designed a cloud-native, event-driven platform using container orchestration and managed infrastructure primitives” sounds more serious, even if the end result is still a website displaying six pages and a contact form.

Complex systems produce diagrams.

Diagrams produce meetings.

Meetings produce job titles.

Simple infrastructure mostly produces a working website, which is apparently less exciting.

This creates a perverse incentive. We start solving problems we do not have because those solutions are culturally associated with mature engineering.

Nobody wants to be accused of building something outdated. Nobody wants to tell the team that a basic VPS might be enough when every conference talk is discussing platform engineering, service meshes, serverless architectures, and globally distributed systems.

So we plan for imaginary scale.

We design for millions of users before finding the first hundred.

We distribute applications that have no meaningful reason to be distributed.

We introduce orchestration before there is anything worth orchestrating.

Then we spend months operating the infrastructure required to operate the infrastructure.

That is not always sophistication. Sometimes it is fear wearing a technical vocabulary.

You do not need Kubernetes just because it exists

Kubernetes is useful.

It solves difficult problems involving container orchestration, scheduling, service discovery, deployment, scaling, resource management, and resilience. Large organizations with many services and teams can have completely valid reasons to use it.

But Kubernetes solves Kubernetes-shaped problems.

A personal website is not a Kubernetes-shaped problem.

A company presentation site is not a Kubernetes-shaped problem.

A blog is not a Kubernetes-shaped problem.

A straightforward web application does not become more professional because its HTTP requests pass through an ingress controller before reaching a container that replaced a process that could have run directly on a server.

Kubernetes also comes with an operating cost that does not disappear just because the cluster is managed.

Someone still needs to understand deployments, pods, services, ingress, storage, secrets, networking, resource limits, access control, upgrades, monitoring, and the collection of extensions that inevitably starts growing around the cluster.

Managed Kubernetes can remove part of the operational burden. It cannot remove the conceptual burden.

If you need what Kubernetes provides, that burden may be worthwhile.

If you don’t, congratulations. You have successfully created an entire category of work for yourself.

Containers have useful properties. Kubernetes is a powerful platform. Neither fact means every project needs either one.

Sometimes a normal process running on a normal server is not technical debt.

Sometimes it is the correct answer.

Serverless still has servers and now also has a pricing equation

Serverless infrastructure makes sense for certain workloads.

Short-lived tasks, event processing, unpredictable bursts, and workloads that benefit from scaling to zero can be good fits. The provider handles much of the underlying infrastructure, and that can save serious operational effort.

But “serverless” is one of those terms that quietly encourages people to stop thinking.

The servers did not disappear. Ownership and billing changed.

Instead of renting straightforward capacity, you may now pay according to requests, execution duration, memory allocation, storage operations, data transfer, logging, and the other services required to connect everything.

That can be efficient.

It can also turn a simple application into a distributed billing event.

A serverless function may be easy to deploy in isolation. A real serverless application is rarely one isolated function. It usually depends on triggers, permissions, gateways, managed storage, monitoring, deployment tooling, and provider-specific behavior.

The more of those pieces you use, the less portable the system becomes.

Again, none of this makes serverless bad.

It means “serverless” should be an architectural decision, not a fashion choice.

If a conventional application on a conventional server can perform the task reliably, I do not see a problem that needs fixing.

A long-running process is allowed to exist.

A cron job is allowed to exist.

A server is allowed to remain turned on.

Managed services manage you too

Managed services are attractive because they remove work.

A managed database can handle maintenance tasks that would otherwise require time and expertise. A managed identity service can save developers from implementing sensitive authentication systems. Managed queues, caches, storage, and monitoring can accelerate development substantially.

That is all real value.

But the word “managed” tends to emphasize what you stop managing while hiding what you give up.

You give up some control.

You accept a provider’s limits and operational behavior.

You build around its APIs.

You depend on its pricing.

You depend on its product roadmap.

You depend on its policies.

You depend on its account and permission systems.

You depend on the service continuing to exist in a recognizable form.

If several important parts of the application depend on proprietary services from the same provider, leaving becomes progressively more difficult.

Moving a conventional application between servers is not always easy, but at least the pieces are usually recognizable. A web server is a web server. Files are files. Common database engines are available from many providers.

Moving an application deeply integrated with one cloud company’s identity, database, messaging, storage, function runtime, monitoring, and deployment products is not moving a server.

It is a rewrite with luggage.

Vendor lock-in can be an acceptable trade. A proprietary service may provide enough value to justify it completely.

But developers should stop pretending the lock-in is not there simply because the service has a friendly SDK.

Convenience is not independence.

Cloud pricing is simple until you use the cloud

The basic cloud sales pitch is appealing: use what you need and pay for what you use.

That model can be excellent for workloads that change rapidly or need flexible capacity.

It can also create bills assembled from a strange collection of requests, execution time, storage classes, operations, transfer directions, reserved capacity, logs, metrics, gateways, addresses, and regional variations.

The application architecture becomes a pricing architecture.

Every technical decision can introduce another meter.

Run code? Metered.

Store data? Metered.

Read the data? Possibly metered.

Transfer the data? Definitely pay attention.

Keep detailed logs so you can understand the distributed architecture? That is another product.

Analyze why the logging product costs so much? This may require additional monitoring.

With traditional hosting or a VPS, the cost model is often more direct. You rent a defined amount of capacity. The project runs inside that capacity. If it outgrows the available resources, you optimize it or change the infrastructure.

That model is less elastic, but it is easy to understand.

Simple hosting can also be inexpensive. In some cases, a small personal website can even be hosted for free. The right cost depends entirely on the project and its requirements, so pretending there is one universal cheapest option would be dishonest.

Still, plenty of projects do not need a pricing calculator with 40 inputs.

Saving money is not just about finding the lowest monthly price. It is also about avoiding unnecessary engineering, avoiding unnecessary administration, and avoiding an architecture that requires specialized expertise to keep a simple website online.

For more than 20 years, choosing traditional hosting, VPSs, or dedicated servers according to actual project requirements has saved me both time and money.

That is not a theoretical possibility.

It is what I have done.

The deeper problem is not cloud technology

The deeper problem is concentration.

AWS is the most recognizable name in this conversation, which is why it works in the title. But this is not really about AWS.

It is about an internet where an enormous amount of compute, storage, networking, authentication, DNS, content delivery, and application infrastructure is increasingly concentrated around a small number of giant companies.

AWS, Microsoft Azure, and Google Cloud are the obvious examples. Other large platforms and infrastructure intermediaries add more layers to the same pattern.

Each company may run technically impressive infrastructure.

Each individual customer may have a perfectly good reason to use it.

But if everyone makes the same individually reasonable choice, we can still end up with a collectively fragile internet.

That is the part developer culture tends to ignore.

Centralization is convenient right up until the centralized thing fails.

Then thousands of supposedly independent services can start failing together.

One cloud problem can become everybody’s problem

Cloud providers experience outages. So do smaller hosting companies, private data centers, internet service providers, DNS operators, and individual servers.

The existence of an outage does not prove that a provider is incompetent.

It proves that infrastructure fails.

The concentration question is about the blast radius.

On December 7, 2021, AWS experienced a major service event in its Northern Virginia region. An automated capacity-scaling activity triggered unexpected behavior that overwhelmed networking devices connecting AWS’s internal network to its main network.

That internal network supported foundational capabilities such as monitoring, internal DNS, authorization, and parts of the EC2 control plane. The resulting congestion affected multiple AWS services and even impaired AWS’s ability to monitor the incident and handle support cases normally.

The important lesson is not that AWS had a bad day.

The lesson is that many separate-looking cloud services can share critical internal dependencies. When one foundational layer fails, the neat boxes in the architecture diagram stop looking quite so independent.

Microsoft Azure provided another example on January 25, 2023.

A networking change associated with adding capacity to Microsoft’s global wide area network caused widespread connectivity problems. From 07:08 UTC until 12:43 UTC, customers experienced latency and timeouts connecting to resources hosted in Azure regions.

The incident also affected other Microsoft services, including Microsoft 365 and Power Platform. Azure Government services that depended on the public Azure cloud were affected too.

One networking event did not remain one networking event.

It crossed services and customer boundaries because those systems shared major infrastructure underneath.

Google Cloud had a major global incident on June 12, 2025. A policy change triggered a failure in Google’s Service Control system, part of the infrastructure used to apply quota and policy checks to API requests.

The problematic policy data was replicated globally. A software path without appropriate error handling encountered the bad data and crashed, causing increased errors across many Google Cloud and Google Workspace products.

The status infrastructure was affected too, delaying Google’s first public incident report. Some customers also lost visibility because their own monitoring systems were running on the same cloud experiencing the outage.

That last detail should make every infrastructure engineer slightly uncomfortable.

Your application is down.

Your monitoring is down.

The system meant to tell you the cloud is down is also down.

Efficient.

Cloud dependencies do not stop at the cloud provider

The June 2025 Google Cloud incident demonstrated something even more important.

Cloudflare suffered a significant outage at the same time because part of the storage infrastructure behind its Workers KV service depended on a third-party cloud provider affected by the incident.

Cloudflare reported that the outage lasted 2 hours and 28 minutes and globally affected customers using several impacted services. Workers KV was a critical dependency for products involving configuration, authentication, and asset delivery, so failures spread into Cloudflare Access, WARP, Gateway, Turnstile, Workers AI, Pages, Stream, and other products.

This is what modern infrastructure dependency chains look like.

A developer depends on a platform.

That platform depends on another service.

That service depends on a cloud provider.

The developer may not even know which underlying company is ultimately hosting a critical part of the stack.

The service has a different logo, a different account, and a separate invoice. Architecturally, however, the dependency may still lead back to one of the same few giant infrastructure providers.

This is why buying services from several vendors does not automatically create independence.

Sometimes you have simply purchased the same cloud dependency through multiple layers of abstraction.

I use Cloudflare, and I’m still uncomfortable with Cloudflare

I occasionally use Cloudflare, and I think it is a good service.

It solves real problems well. Its scale, network, security features, DNS, and performance tools make it attractive for obvious reasons.

I also dislike how much Cloudflare has contributed to the centralization of the internet.

That may sound contradictory. It is not.

A service can be excellent and still occupy an unhealthy position in the broader ecosystem.

In fact, excellent services are exactly the ones most likely to become central points of dependency. People use them because they are good. Tooling starts assuming they are available. Tutorials make them the default. Competing at the same scale becomes harder.

Eventually, a service that was once optional becomes part of the internet’s unofficial plumbing.

On November 18, 2025, Cloudflare experienced significant failures delivering core network traffic after a database permissions change caused a Bot Management configuration file to unexpectedly double in size.

The oversized file propagated across Cloudflare’s network. Core proxy software had a size limit below the new file size, causing failures across the network.

Cloudflare said core traffic was largely flowing normally again by 14:30 UTC, with all systems functioning normally by 17:06 UTC.

Cloudflare itself acknowledged the significance of its position in the internet ecosystem.

That position is exactly what concerns me.

I can appreciate the product while questioning whether so much internet traffic should depend on one company.

We need more alternatives at that scale, not because Cloudflare is uniquely bad, but because no company should become too difficult for the internet to route around.

Smaller providers fail, but they fail smaller

Traditional hosting providers and independent VPS companies are not magically reliable.

Some are excellent. Some are terrible. Some will suffer hardware failures, network outages, security incidents, overloaded servers, bad support, or business problems.

A cheap VPS is not automatically resilient.

A dedicated server is still one physical machine unless the architecture accounts for that.

Shared hosting can have resource limitations and noisy neighbors. It can offer less control. It may not support unusual software requirements. Scaling may require migration rather than moving a slider in a dashboard.

Simple infrastructure has real limitations.

The point is not that small providers never fail.

The point is that they usually fail independently.

If one small hosting provider has a major incident, its customers are affected. That is serious for those customers, but it does not automatically take a huge collection of unrelated global services down with it.

Concentration changes the nature of failure.

When a dominant cloud, CDN, DNS operator, identity platform, or payment processor has a major incident, enormous numbers of businesses can be affected simultaneously.

That is systemic risk.

Moving every project to one of three giant clouds may improve the infrastructure available to each individual project. It can also make the wider internet more dependent on the same underlying systems.

Both things can be true.

Reliability is not only about how rarely one provider fails. It is also about how much fails with it.

Multi-cloud is not a magic spell

The industry’s answer to cloud concentration is often “multi-cloud.”

In theory, that means designing a system that can run across multiple major cloud providers.

In practice, it can mean paying several giant companies while multiplying your architecture, operational requirements, deployment tooling, networking complexity, security configuration, and staff expertise.

A genuinely portable multi-cloud application can be valuable for organizations that require that level of resilience or negotiating power.

It can also be spectacular overkill.

If avoiding dependence on one complicated platform requires building an abstraction layer across three complicated platforms, the cure may be worse than the disease.

For many smaller projects, provider diversity does not require an enterprise multi-cloud strategy.

It can mean keeping an application portable.

It can mean preferring common technologies.

It can mean choosing a hosting provider without deeply coupling every application component to proprietary services.

It can mean maintaining the realistic ability to move the project elsewhere.

Portability does not need a branded framework.

Sometimes it is simply the result of not making the application unnecessarily difficult to host.

The cloud is excellent when you actually need a cloud

There are plenty of projects for which a hyperscale cloud platform is the right answer.

Applications with unpredictable global traffic may benefit from elastic capacity.

Large companies may need geographic regions, compliance programs, sophisticated access controls, managed data platforms, global networking, machine learning infrastructure, or integration with an existing cloud ecosystem.

Teams running many services may benefit from orchestration.

Specialized workloads may be far easier to build with managed cloud products than with traditional infrastructure.

Fast-growing companies may reasonably decide that vendor lock-in is an acceptable price for speed.

I have no argument with any of that.

The problem begins when tools designed for extraordinary scale become the default recommendation for ordinary projects.

Most websites do not need the infrastructure capabilities of a multinational cloud provider.

They need to load.

They need reasonable security.

They need backups and maintenance appropriate to their requirements.

They need enough capacity for their real traffic.

They need an operator who understands where they are hosted and how to recover them.

A massive catalog of managed services does not automatically improve any of those things.

Sometimes it provides useful solutions.

Sometimes it provides tempting solutions to problems the project never had.

Choosing less is still an engineering decision

Using shared hosting is not refusing to make an infrastructure decision.

It is making one.

Using a VPS is not failing to adopt cloud-native architecture.

It is deciding that the project needs a virtual server.

Using a dedicated server is not being trapped in the past.

It is choosing dedicated resources when the requirements justify them.

Apache does not stop working because it lacks a venture-backed origin story.

Control panels do not become useless because somebody prefers managing everything through configuration repositories.

Traditional hosting is not obsolete because the cloud industry has better marketing.

These tools and infrastructure models still exist because they continue to solve real problems.

The useful question is not whether a stack looks modern.

The useful questions are much less exciting:

Does it meet the project’s requirements?
Is it reliable enough for the actual use case?
Can the people responsible for it understand and maintain it?
Is the cost reasonable?
Can the project be moved if necessary?
What external services does it depend on?
What happens when the provider changes its prices or policies?
What happens when the provider goes down?
Does each additional layer solve a real problem?
Are we building for actual users or hypothetical millions?

If the answers lead to AWS, Azure, Google Cloud, Kubernetes, or serverless infrastructure, fine.

Use them.

But make them win the argument first.

Do not hand them the project because developer culture has decided that renting a normal server is embarrassing.

The internet needs more than three landlords

The internet is not completely centralized. No single company controls all of it, and there are still many hosting providers, network operators, data centers, independent services, and infrastructure companies.

But too much critical infrastructure is moving into too few hands.

That deserves more concern than it currently gets.

When the same small group of companies increasingly provides compute, storage, networking, DNS, identity, content delivery, databases, AI services, and application platforms, developers become dependent on more than technology.

They become dependent on pricing decisions.

Policy decisions.

Account decisions.

Product roadmaps.

Geopolitical decisions.

Corporate priorities.

The continued willingness of a giant company to provide a product under conditions the customer can accept.

A diverse hosting ecosystem provides alternatives.

Small hosting companies matter.

Independent VPS providers matter.

Dedicated server providers matter.

Traditional shared hosting businesses matter.

Different providers using different networks and infrastructure matter.

Not every hosting company needs to become a miniature hyperscaler. In fact, I would prefer that they didn’t.

The internet is healthier when developers have real choices, including simple ones.

I don’t hate the cloud. I hate inevitability.

I am not trying to recreate the internet of 2003.

I do not think old technology is automatically better. I do not think new technology is automatically pointless. I do not believe every developer should manage physical servers or reject every managed service.

I am not even completely independent of large technology companies, and I have no interest in pretending otherwise.

I occasionally use Cloudflare because it is useful, while remaining uncomfortable with the degree of centralization it represents.

What I reject is the idea that the giant cloud ecosystem is inevitable.

I reject the assumption that serious infrastructure must belong to AWS, Azure, Google Cloud, or another hyperscale platform.

I reject the idea that complexity is proof of engineering maturity.

I reject the idea that a project should surrender portability and control before it has a reason to do so.

For more than 20 years, I have used traditional shared hosting for smaller websites and VPSs or dedicated servers for larger projects, based on actual requirements.

I have hosted websites, blogs, company presentation sites, and similar projects.

I have never used AWS or a similar hyperscale cloud platform for my projects.

That approach has saved me time and money.

It will not be right for every project. It does not need to be.

It only needs to prove one thing:

The giant cloud is an option, not a law of nature.

Sometimes the boring solution is the one you can understand, afford, maintain, and move.

Sometimes a website is just a website.

And sometimes the healthiest thing we can do for the internet is stop giving the same handful of companies every single piece of it.

Before opening another cloud account, ask one uncomfortable question:

What problem am I actually paying this giant company to solve?

You may have a very good answer.

You may also realize that what you really need is a server.

Sources

Firefox Is Down to 3% Worldwide: How Mozilla Turned a Browser Giant Into a Rounding Error

David Timothy — Thu, 03 Sep 2026 22:31:46 +0000

I used Firefox for years.

Brave was installed too, but it had a clearly defined role on my computer: it was the backup browser. The browser I opened when something did not work properly, when I wanted aggressive ad blocking without touching any settings, or when I needed a Chromium-based browser for compatibility.

Then, without making a conscious decision to switch, I started opening Brave more often.

At some point, Brave stopped being the backup. Firefox became the backup.

I did not rage-uninstall Firefox. Mozilla did not make one catastrophic decision that forced me out overnight. The switch happened gradually, almost invisibly. Brave simply solved more of my everyday problems with less effort.

That is probably the most uncomfortable part of Firefox's decline.

Most users did not dramatically quit. They just stopped clicking the icon.

Firefox is not literally a statistical error, but it is getting close

According to StatCounter's worldwide browser data for August 2026, Firefox holds about 2.98% of the global browser market across all platforms.

On desktop, the situation looks slightly less brutal. Firefox has around 5.31%. That is still enough to matter, especially among developers, Linux users, privacy-conscious users, and open-source communities.

But compare that with Firefox at its peak.

Around 2009, Firefox was used by roughly one-third of desktop internet users. It was not an alternative browser for enthusiasts. It was one of the main ways people accessed the web.

Firefox was the browser that proved Internet Explorer was not inevitable.

Now it is fighting to remain relevant in a market where Chrome controls most browsing, Safari owns Apple's ecosystem, Edge comes preinstalled with Windows, and smaller Chromium browsers can inherit compatibility from the dominant engine.

Calling Firefox a "statistical error" is obviously rhetorical. Three percent of global traffic still represents a massive number of people.

But in terms of influence, developer priority, extension availability, testing budgets, and platform power, 3% is dangerously close to irrelevance.

Once a browser becomes optional for developers to test, decline starts feeding itself.

Mozilla did not lose only to Chrome

It is easy to tell a simple story where Google arrived with Chrome, bundled it everywhere, spent billions on distribution, and crushed Firefox.

That story is not wrong. It is just incomplete.

Firefox faced structural disadvantages that Mozilla could never fully control:

Chrome was promoted on the world's largest search engine.
Android made Chrome the default browser for billions of users.
Safari owns the default position on iPhones, iPads, and Macs.
Edge ships with Windows and is aggressively promoted inside the operating system.
Google's web apps naturally receive first-class attention in Chromium.
Many companies test websites in Chrome first and everything else later.

Firefox is the only major browser in that group without an operating system, mobile platform, search monopoly, or trillion-dollar company pushing it.

That matters.

Still, Mozilla cannot blame the entire decline on defaults and Big Tech. Firefox also lost users through years of product decisions that repeatedly irritated the exact people most willing to defend it.

Mozilla kept redesigning Firefox while removing reasons to stay

Firefox built its reputation on customization.

It was the browser for people who wanted their browser to work their way. Toolbars could be moved. Buttons could be rearranged. Tabs could be transformed. Extensions could change almost every part of the interface.

Then Mozilla spent years simplifying and redesigning that experience.

Australis arrived with Firefox 29 in 2014. Mozilla presented it as a modern, streamlined, and highly customizable redesign. Many existing users saw something else: Firefox becoming visually closer to Chrome while removing parts of the interface they had customized for years.

The same pattern repeated with later redesigns.

The 2021 Proton redesign introduced floating tabs, larger interface elements, simplified menus, and reduced iconography. Mozilla described it as calmer and cleaner. Power users saw more wasted space and fewer visual cues.

Compact mode was removed from the normal customization interface in Firefox 89. It remained available through an unsupported about:config workaround, which is a very Firefox way of handling a feature loyal users wanted:

Remove it from the interface.
Leave it half-alive behind an advanced preference.
Mark it unsupported.
Make users feel unreasonable for asking where it went.

None of these redesigns destroyed Firefox by themselves. The problem was cumulative.

Firefox kept telling users it was the customizable browser while gradually narrowing the supported customization options.

The extension apocalypse broke Firefox's original promise

The transition to Firefox 57 and WebExtensions was technically understandable.

The old extension architecture was extremely powerful, but that power came with performance, security, and maintenance problems. Legacy extensions could reach deep into Firefox internals, making browser changes harder and updates riskier.

Mozilla needed a safer and more sustainable extension system.

But the way the transition happened was devastating for part of the user base.

Starting with Firefox 57 in November 2017, legacy extensions stopped loading. Extensions built using XUL, the Add-ons SDK, and other older technologies became incompatible. Some were ported to WebExtensions, some returned with reduced functionality, and many simply disappeared.

For regular users, the technical justification did not change the result.

They updated Firefox and their workflow broke.

The browser that had built its identity around extensions suddenly told users that their extensions were no longer supported. In some cases, the available replacement could not reproduce the same functionality because the necessary APIs did not exist.

Mozilla gained a cleaner technical foundation with Firefox Quantum, and Quantum itself was a major performance improvement. But Mozilla also burned a lot of goodwill.

The message users received was clear: even Firefox's biggest differentiator could disappear during an update.

Then came the 2019 certificate incident.

An expired certificate caused Firefox to disable existing extensions and block new installations. Mozilla had to distribute fixes, including an initial fix through its Studies system. For a browser whose most committed users depended heavily on extensions, this was an embarrassing operational failure.

Again, no single incident explains years of decline. But loyal users remember when the browser breaks the exact feature that made them loyal.

Mozilla abused trust with experiments that never should have shipped

The 2017 Looking Glass incident remains one of Mozilla's strangest decisions.

Mozilla remotely installed a Firefox add-on connected to the TV show Mr. Robot. The add-on was initially disabled and did not collect user data, but that was not the point.

A browser associated with privacy and user control silently installed a mysterious extension with a deliberately cryptic description.

Mozilla later apologized and admitted that the deployment violated its own advice about recognizing malware.

That incident revealed a larger problem. Mozilla had built remote experimentation systems that could install or change browser components, then used that infrastructure for a marketing stunt.

The technical risk may have been limited. The damage to trust was not.

In the same year, Mozilla tested Cliqz recommendations with a small percentage of new Firefox users in Germany. That build sent browsing activity, including visited URLs, to Cliqz servers after attempting to remove sensitive information.

Mozilla documented the experiment and allowed users to disable it. Cliqz was positioned as a privacy-focused company. Even so, shipping URL collection by default to a subset of Firefox users was an astonishing decision for a browser selling itself on privacy.

This became a recurring Mozilla problem: the company would design something it considered privacy-preserving, technically defensible, and transparent, while failing to understand how it looked to users.

Users were not evaluating cryptographic protocols or internal privacy reviews.

They were asking a simpler question:

Why is my privacy browser experimenting on me?

Firefox slowly turned its interface into ad inventory

Mozilla needs revenue. Browser development is extremely expensive, and users generally refuse to pay for browsers.

I understand the business problem.

What I do not understand is why Mozilla repeatedly acts surprised when Firefox users react badly to advertising inside the browser.

Firefox has included or experimented with:

Sponsored shortcuts on the home and New Tab pages
Sponsored stories and content recommendations
Sponsored suggestions in the address bar
Impression and click measurement
Contextual recommendations from commercial partners
Advertising and attribution experiments
Content personalization based on local interaction data

Mozilla emphasizes that these systems use aggregation, on-device processing, Oblivious HTTP, differential privacy, and other privacy-preserving techniques.

That is better than traditional behavioral advertising.

It still does not make the product direction appealing.

When I open a browser, I do not want "recommended content." I do not want sponsored shortcuts. I do not want the address bar becoming another surface waiting to monetize intent.

I want an empty, fast, predictable browser window.

Firefox users are especially sensitive to this because Mozilla has spent decades presenting Firefox as the alternative to surveillance-driven Big Tech. Once ads and sponsored suggestions appear in that product, the distinction becomes harder to explain.

The Privacy-Preserving Attribution prototype in Firefox 128 is another example. Mozilla later clarified that the experimental feature was never activated and was eventually removed. The technology was intended to give advertisers aggregated measurement without cross-site tracking.

Technically, that is a legitimate privacy research goal.

Strategically, putting advertising measurement technology anywhere near default Firefox settings was guaranteed to create suspicion. Mozilla may have had good intentions, but it once again underestimated its own audience.

The first Firefox Terms of Use were a completely avoidable disaster

In February 2025, Mozilla introduced formal Terms of Use for Firefox.

The initial language gave Mozilla a nonexclusive, royalty-free, worldwide license related to content entered through Firefox. Mozilla said the license was necessary to operate requested browser functionality and did not transfer ownership of user content.

Users saw broad legal language claiming rights over content entered into a web browser.

Mozilla revised the wording two days later after backlash.

The updated language more clearly limited the license to operating Firefox and doing what the user requested. Mozilla also stressed that users continued to own their data.

Maybe the lawyers were technically correct from the start. That does not make the rollout good.

Firefox is not a social network where users upload posts to Mozilla's servers. It is a web browser. Introducing broad content-license language into the Terms of Use for a browser was always going to trigger alarm.

Mozilla should understand trust better than almost any other technology organization.

Instead, it keeps learning the same lesson in public.

Mozilla became distracted by everything except making Firefox impossible to ignore

Over the years, Mozilla invested in a long list of products and experiments:

Firefox OS
Pocket
Fakespot
Mozilla VPN
Firefox Relay
Mozilla Monitor
Hubs
Mozilla Social and Mastodon
Mozilla.ai
Various advertising initiatives
Venture investments
AI browser experiments

Diversification is not inherently bad. Mozilla's dependence on search revenue is dangerous, so building additional businesses makes sense.

Mozilla's own strategy documents say search still accounts for around 85% of revenue. That creates a ridiculous dependency where the organization building the main alternative to Chromium receives most of its money from search partnerships connected to the dominant browser company.

Mozilla has to diversify.

The problem is its execution.

Pocket was acquired, integrated into Firefox, promoted on the New Tab page, and eventually shut down in July 2025.

Fakespot was acquired in 2023. Its Firefox Review Checker was shut down in June 2025, and the wider Fakespot service closed in July.

Mozilla Social and Hubs were scaled back or exited during restructuring.

Products arrive with ambitious mission statements, occupy engineering and management attention, get integrated into the Firefox story, and then disappear.

Meanwhile, basic browser features that users had requested for years arrived painfully late.

Mozilla's own strategy document is unusually blunt. It describes Firefox as widely viewed as outdated, acknowledges a mixed and slow execution record, and admits competitors are moving faster.

I could not summarize the problem better than Mozilla already has.

Firefox spent years arriving late to basic browser features

Firefox has improved significantly since 2024, but many improvements should have happened years earlier.

Vertical tabs officially arrived in Firefox 136 in March 2025.

Native tab groups followed in Firefox 138 in April 2025. They had been the most requested feature on Mozilla Connect.

A modern, user-friendly profile manager began rolling out in October 2025. Firefox technically had profiles long before that, but they were hidden behind tools such as about:profiles and the external Profile Manager instead of being treated as a normal user feature.

Desktop web apps finally appeared on Windows starting with Firefox 143. Support remains platform-limited, and Microsoft Store installations required an even newer version.

Firefox for Android only started rolling out tab groups in 2026, with iOS support planned for later.

These are not experimental features for a tiny niche. Profiles, vertical tabs, tab groups, and installable web apps are basic browser workflow features.

By the time Firefox ships something, the feature often feels like maintenance rather than innovation.

Firefox users waited years for tab groups, then Mozilla immediately started talking about AI-assisted tab grouping.

That captures Mozilla's priority problem perfectly.

The company is eager to participate in the next industry trend while still catching up on the previous one.

Firefox can be fast, but compatibility beats benchmarks

I do not buy the argument that Firefox is simply slow.

Modern Firefox can be fast. Gecko is a serious browser engine, and Mozilla has delivered major performance improvements over the years. Firefox can perform extremely well depending on the website, operating system, extensions, and workload.

The bigger problem is consistency.

Brave uses Chromium. That means it benefits from the engine most websites are already built and tested around.

A developer may care that a bug belongs to the website rather than Firefox. A regular user does not.

If a website works in Brave and acts strangely in Firefox, the user opens Brave.

If a video-conferencing app recommends Chrome, the user opens Brave.

If an extension is available for Chromium but not Firefox, the user opens Brave.

If an enterprise tool is primarily tested against Chrome and Edge, the user opens Brave.

Eventually, the user stops going back.

This creates a nasty feedback loop:

Firefox loses market share.
Developers spend less time testing Firefox.
More Firefox-specific bugs reach production.
Users encounter more compatibility friction.
Those users switch to Chromium.
Firefox loses more market share.

Mozilla cannot solve that problem with branding campaigns about independence. Firefox needs enough users to make ignoring Gecko expensive.

At around 3% global share, ignoring Firefox is becoming a rational business decision for some development teams.

That is terrible for the open web, but it is the predictable result of the numbers.

Brave won me over by requiring less work

Brave is not perfect. I will get to that.

But its core pitch is easy to understand.

Install Brave and you immediately get:

Built-in ad and tracker blocking
Fingerprinting protection
Third-party cookie protection
Chromium website compatibility
Access to the Chromium extension ecosystem
Vertical tabs
Tab groups
Profiles
Installable web apps
Cross-device sync
Per-site privacy controls
A familiar interface

Firefox has excellent tracking protection, Total Cookie Protection, Multi-Account Containers, and unusually strong extension support. It remains one of the best browsers for running uBlock Origin without Chromium's Manifest V3 limitations.

But Firefox's default setup does not block regular ads the way Brave Shields does.

To get something closer to Brave's out-of-the-box experience, a Firefox user usually installs uBlock Origin, possibly adds more privacy extensions, changes Enhanced Tracking Protection settings, disables sponsored content, reviews telemetry options, and modifies the home page.

A technical user can do that in a few minutes.

Most users will not.

Brave gives them a large portion of that experience immediately.

That convenience matters more than browser enthusiasts like to admit.

My move from Firefox to Brave was not a carefully planned migration. Brave was already installed as the Chromium-compatible backup. Over time, the backup browser became easier to reach for, and Firefox became the browser I opened only when I specifically wanted Firefox.

That is how products lose users.

Not with one explosion, but through thousands of tiny moments where the alternative is easier.

Brave has its own baggage

Switching to Brave is not a morally pure decision.

Brave is based on Chromium, so using it still contributes to Chromium's engine dominance. Brave removes and modifies plenty of Google functionality, but it does not provide an independent browser engine.

That distinction matters.

If Gecko disappears, Brave does not save browser-engine diversity. It becomes another Chromium browser competing through interface features, privacy defaults, and services.

Brave also ships plenty of things I can understand people wanting to disable:

Brave Rewards
Cryptocurrency features
Wallet integration
Sponsored background images
Brave News
Brave Leo
VPN promotions
Web3-related features

The difference, at least for me, is that Brave's core browsing proposition remains obvious underneath that clutter.

It blocks junk, works with Chromium-focused websites, and generally requires very little setup.

Firefox has a stronger philosophical reason to exist, but Brave often presents a clearer practical reason to use it.

That is a serious problem for Mozilla.

Firefox still matters more than its market share suggests

I am critical of Firefox because I do not want it to disappear.

Firefox remains one of the only meaningful defenses against a web controlled almost entirely by Chromium and WebKit.

Gecko gives web standards another independent implementation.

Firefox also has genuinely excellent features:

Multi-Account Containers
Total Cookie Protection
Strong uBlock Origin support
Extensive about:config controls
Good developer tools
Reader View
Local translation
Strong privacy protections
Open-source development
Native Linux support
A community that still cares deeply about browser independence

Firefox is not a bad browser.

That is what makes the decline so frustrating.

Mozilla did not spend 15 years building a useless product. It spent 15 years allowing a valuable product to become increasingly difficult to recommend to normal users.

"Use Firefox to protect the open web" is an important argument.

It is not a complete product strategy.

People install browsers to solve their own problems, not to fix browser-engine economics.

Can Firefox recover?

Firefox probably will not return to its old market share. The browser market is too tied to operating systems, mobile platforms, defaults, and corporate ecosystems.

But recovery does not require beating Chrome.

Mozilla first needs to stop treating existing users as a captive audience.

That means:

No surprise experiments
No vague legal language
No advertising systems enabled without clear consent
No unnecessary removal of customization options
No redesigns that prioritize visual trends over information density
No abandoning products shortly after forcing them into Firefox
No pretending users asked for AI when they asked for basic browser features
Faster delivery of features available elsewhere for years
Better communication before breaking extensions or workflows
More investment in compatibility, performance, and mobile
A default experience that demonstrates Firefox's privacy advantage immediately

Firefox should open for the first time and make its value obvious.

Not after installing four extensions.

Not after visiting about:config.

Not after disabling sponsored content.

Not after reading a Mozilla blog post explaining why an advertising feature is technically privacy-preserving.

Immediately.

Mozilla does not need another abstract mission statement. It needs a browser people miss when they use something else.

Firefox did not die. It faded.

Firefox's decline was not caused by one CEO, one redesign, one extension change, or one competitor.

Google had enormous distribution advantages. Mobile defaults changed the market. Websites standardized around Chromium. Mozilla needed revenue and had limited resources compared with its competitors.

All of that is true.

It is also true that Mozilla repeatedly weakened trust, removed functionality, chased side projects, shipped unwanted experiments, and arrived years late with features users were already using elsewhere.

Firefox went from a browser people selected because it was better to a browser people select because they believe the web needs it.

That is not sustainable.

I still have Firefox installed, just as I once kept Brave installed as a backup.

The roles have reversed.

And if Mozilla wants to understand why Firefox has fallen to roughly 3% of worldwide browser usage, it should pay attention to that kind of quiet switch.

The user who angrily uninstalls your product may eventually return.

The user who gradually forgets to open it probably will not.

Sources

GrapheneOS vs Stock Android: Privacy, Security and Control

David Timothy — Tue, 01 Sep 2026 00:09:50 +0000

Stock Android feels fine. Until you realize how much you are actually giving up.

I have spent a lot of time digging into mobile operating systems, what they do in the background, what permissions they really enforce, and how much control you actually have as a user. And the more I looked at Stock OS vs GrapheneOS, the more obvious it became that Stock OS is just not built for the user. It is built for Google, for carriers, and for data brokers. GrapheneOS is built for you.

This is not just another privacy nerd rant. This is a real breakdown of why GrapheneOS wins in basically every category that matters.

What We Mean By "Stock OS"

When I say Stock OS, I mean the Android that comes preinstalled on your Pixel, Samsung, OnePlus, whatever. Even "clean" Stock Android on a Pixel is still Google's Android.

It includes:

Google Play Services with privileged, unrestricted system access
Dozens of preinstalled Google apps you cannot fully remove
Default telemetry and tracking that you can only partially opt-out of
Carrier and manufacturer bloat if you are not on a Pixel
Security that is good, but intentionally limited to not break Google's business model

It works. It is smooth. But it was never designed to put you in control.

What GrapheneOS Actually Is

GrapheneOS is not some sketchy custom ROM you flash with a random tool from XDA. It is a hardened, open source Android fork built specifically for Pixels. It is Android, but rebuilt with security and privacy as the core features, not afterthoughts.

A few things to get straight:

It is not LineageOS. LineageOS is about customization and keeping old phones alive. GrapheneOS is about security.
It does not break your apps. You can still run Google Play Services, but sandboxed like a normal app, with no special privileges.
It is not just for journalists or paranoid people. It is for anyone who wants a phone that does what they tell it to do.

It is still Android. Your apps, your workflow, your UI - 95% the same. What changes is what happens under the hood.

Stock OS vs GrapheneOS: Head to Head

Let's break this down category by category.

1. Privacy: No Contest

This is where Stock OS completely falls apart.

On Stock OS, Google Play Services runs as a privileged system app. It has access to your location, your sensors, your phone identifiers, and it can run in the background whenever it wants. You cannot revoke its network access. You cannot revoke its sensor access. Turning off "Location History" in your Google account does not stop low level collection.

On GrapheneOS, everything is permission based and actually enforced.

Network permission toggle: You can deny any app network access completely. Stock Android has no such feature. On GrapheneOS you can have an offline calculator or photo editor that literally cannot phone home.
Sensors permission: GrapheneOS lets you deny sensor access to apps. No more apps reading your accelerometer and gyroscope to fingerprint you.
Contact Scopes and Storage Scopes: Instead of giving an app access to all your contacts or all your files, you give it access to only what it needs. Stock OS is all or nothing.
No advertising ID by default: GrapheneOS does not expose a resettable advertising ID to apps. Stock OS does, even if you "reset" it.

This is the difference between privacy theater and actual privacy.

# On Stock OS, you can't do this without root
# On GrapheneOS, this is a simple toggle in App Info -> Permissions
# But you can also manage it via ADB if you want to script it:

adb shell cmd appops set com.example.shadyapp INTERNET deny
adb shell cmd appops set com.example.shadyapp ACCESS_RESTRICTED false

On Stock, an app either gets internet or it does not get installed. On GrapheneOS, you decide.

2. Security: Stock Is Good, GrapheneOS Is on Another Level

People think Pixel Stock OS is secure, and it is, compared to Samsung or Xiaomi. But GrapheneOS takes the Pixel's already great hardware security and pushes it way further.

Here is what GrapheneOS adds that Stock just does not have:

Hardened kernel and hardened malloc: GrapheneOS uses its own hardened memory allocator that catches exploitation attempts that would succeed on Stock OS. This is huge for preventing zero-click exploits.
Hardened WebView and browser: Vanadium, the default browser, is Chromium but significantly hardened. No Google sync bloat, better exploit mitigations.
Exploit mitigations: Things like stricter SELinux policies, control flow integrity, and disabling of insecure legacy features.
Verified Boot with custom keys: Unlike most custom ROMs that break Verified Boot, GrapheneOS keeps it fully intact and re-locks the bootloader with its own keys. You get the same tamper protection as Stock. Most other ROMs leave your phone wide open.
Auto-reboot: GrapheneOS can automatically reboot after a period of inactivity, putting the device back into Before First Unlock state where data is fully encrypted and not accessible. This is a lifesaver against physical forensic tools. Stock does not have this.
PIN scrambling and duress password: You can set a secondary password that wipes the device if you are forced to unlock it.

Stock OS was built to be secure enough to not get sued. GrapheneOS was built to resist real attackers.

3. Google Services: The Smart Way vs The Forced Way

This is the part that finally convinced me. I am not anti-Google. I use Gmail and Maps. I just do not want Google baked into my OS kernel.

On Stock OS, Google Play Services is a system-level god. You cannot uninstall it, you cannot sandbox it, you cannot limit it.

On GrapheneOS, you install Sandboxed Google Play from their Apps repository if you want it. And it runs like any other app:

It has no privileged access
You can deny it location, sensors, contacts, network, whatever
You can put it in a separate user profile and keep your main profile completely Google-free
Apps that depend on Google Play Services still work, but they talk to the sandboxed version

This is genius. You get compatibility without compromise. I keep banking apps and push notifications working through sandboxed Play in a secondary profile, while my main profile has no Google code at all.

# GrapheneOS user profiles are isolated like separate phones
# You can create a "Google" profile just for Play Services:

# Settings -> System -> Multiple users -> Add user
# Install Sandboxed Google Play only in that profile
# Your main Owner profile stays clean

On Stock, you cannot do this. Google is everywhere, all the time.

4. Updates and Longevity

Stock Pixels get 7 years of updates now, which is great. But GrapheneOS is often faster.

GrapheneOS pushes security patches and hardened updates sometimes even before Google pushes them to Stock, because they do not need to wait for carrier approval. Updates are seamless in the background and can be installed without trusting Google's servers.

And when Google drops support for an older Pixel, GrapheneOS often extends its life with continued security updates. You are not abandoned just because Google moved on to the next phone.

5. Bloat, Control, and Ownership

Stock OS comes with 20+ Google apps preinstalled. Some can be disabled, almost none can be fully removed. They run background services, they update themselves, they collect analytics.

GrapheneOS comes with almost nothing. No bloat. No Google apps unless you choose to install them. What you get is:

Vanadium browser
Auditor app for hardware attestation
Secure Camera and Gallery
AOSP apps that are minimal and permission-clean

It feels like you actually own the phone. Because you do.

6. The "But Does It Break My Apps" Myth

This is the biggest lie about GrapheneOS. People think nothing will work.

Reality: 99% of apps work flawlessly.

Banking apps? Work fine, even with sandboxed Play. In fact, GrapheneOS often passes Play Integrity better than rooted Stock phones.
Push notifications? Work via sandboxed Play or via the app's own push.
Google Maps, YouTube, Gmail? Install them sandboxed and they work exactly like Stock, but without system privileges.
SafetyNet / Play Integrity? GrapheneOS has a compatibility layer that lets most apps think they are on a certified device.

The only apps that truly break are ones that intentionally try to detect and block custom OSes, and even those are rare.

Performance and battery are also basically identical to Stock, since it is the same hardware and same base. In my opinion, it even feels a bit snappier without all the background Google junk constantly running.

Who Should Not Use GrapheneOS?

To be fair, it is not for everyone.

If you need absolute seamless Android Auto, or you rely on some weird carrier RCS features that depend on deep Google integration, Stock might be less hassle. Also, GrapheneOS only officially supports Pixels. If you are not on a Pixel 7 or newer, you cannot use it. That is intentional, they only support phones with proper hardware security.

But if you are on a Pixel and you care even a little about who controls your device, there is no reason to stay on Stock.

My Honest Take

Look, I get why people stay on Stock OS. It is easy, it is what the phone came with, and it does not ask you to think. But once you understand what is happening in the background, you cannot unsee it.

Stock OS treats you like a product. It gives you toggles that do not really toggle anything, permissions that do not really restrict Google, and a sense of control that is mostly an illusion.

GrapheneOS treats you like the owner. It gives you real toggles. Real permissions. Real ownership. It does not preach, it just gives you the tools and gets out of your way.

In my view, if you already own a Pixel, keeping Stock OS is like buying a high security safe and leaving the key taped to the front door. GrapheneOS is just locking that door properly.

I switched and I am not going back. If privacy and security matter to you even a little, you should at least try it. The installer is web-based and takes like 5 minutes.

Sources and Further Reading

Google Just Made the Pixel 11 Less Secure: Removing ARM MTE Is a Huge Mistake

David Timothy — Mon, 31 Aug 2026 18:04:46 +0000

The Pixel 11 was supposed to move Google’s security story forward. Instead, one of the most important hardware protections introduced with recent Pixel generations has reportedly disappeared.

According to a GrapheneOS project discussion, the Pixel 11 generation does not provide ARM hardware Memory Tagging Extension support, better known as MTE. The missing feature is serious enough that the GrapheneOS team says the devices do not meet its security requirements and may be skipped entirely.

That is not a minor compatibility complaint. It is a warning from a project that has spent years hardening Android against real-world exploitation.

Google may point to newer security improvements, including quantum-resistant cryptography and other forward-looking protections. Those developments matter. I’m not arguing otherwise.

But quantum-resistant cryptography is mostly about preparing for a future threat. MTE helps defend the device in your pocket against memory corruption attacks today.

Removing it is bad. Really bad.

And no amount of futuristic security branding changes that.

What reportedly changed with the Pixel 11

Starting with the Pixel 8 generation, Google’s phones moved to newer ARM CPU cores with hardware memory tagging support. That allowed Android and alternative operating systems such as GrapheneOS to use MTE as a practical exploit mitigation.

GrapheneOS considers hardware memory tagging important enough to list it as a requirement for future supported devices. Its documentation specifically describes the feature as an “incredibly powerful” hardware security capability and says it is enabled by default to protect compatible operating system components and user-installed apps.

The Pixel 11 generation reportedly breaks that progression.

At the time of writing, the key public claim comes from the GrapheneOS project discussion. Google’s own detailed technical explanation for the missing MTE support is not available there, so I would be careful about inventing a motive. It could involve Google’s SoC choices, CPU core configuration, performance priorities, implementation cost, or something else entirely.

The reason matters, but the result matters more.

If the hardware does not support MTE, an operating system cannot add it later with a software update. GrapheneOS cannot patch around the missing CPU feature. Google cannot quietly enable it in a future Android release. A userspace allocator cannot emulate the same protection with the same security and performance properties.

The silicon either supports hardware tag checking or it does not.

That is why this is a hardware security regression rather than a missing launch feature.

MTE is not just another security acronym

Memory safety bugs have been one of the biggest sources of serious vulnerabilities for decades.

Languages such as C and C++ give developers direct control over memory. That control is useful for performance and low-level systems programming, but it also creates entire categories of bugs:

Buffer overflows
Buffer underflows
Use-after-free vulnerabilities
Invalid pointer accesses
Out-of-bounds reads and writes
Heap memory corruption

Android contains a huge amount of native code. The kernel, hardware abstraction layers, media components, graphics stack, drivers, networking services, vendor components, and many performance-sensitive libraries all operate close to the hardware.

A single memory corruption bug does not automatically equal a full device compromise. Modern Android has sandboxing, SELinux, control-flow protections, verified boot, address-space randomization, and many other defenses.

But memory corruption is often where an exploit chain begins.

An attacker finds a bug in a component that processes untrusted data. Maybe it is an image decoder, browser engine, GPU driver, Bluetooth implementation, baseband-related interface, or media service. The attacker then attempts to turn that bug into something useful, such as arbitrary code execution.

MTE makes that process harder.

How ARM Memory Tagging Extension works

At a high level, MTE associates a small tag with a region of memory and another tag with the pointer used to access that memory.

When the CPU performs a memory load or store, it checks whether the pointer tag matches the tag assigned to the memory.

Conceptually, it looks like this:

Pointer tag: 0xA
Memory tag:  0xA
Result:      Access allowed

If a stale or corrupted pointer carries the wrong tag, the hardware detects the mismatch:

Pointer tag: 0x4
Memory tag:  0xB
Result:      Tag mismatch

Depending on the configured MTE mode, the process can be terminated immediately or the fault can be reported asynchronously.

This is especially useful for two common classes of bugs.

Use-after-free

A program allocates an object and receives a pointer to it. Later, the object is freed, but some part of the program still holds the old pointer.

Without additional protection, that stale pointer might access memory that has since been reused for another object. An attacker may be able to manipulate that reuse and turn the bug into controlled memory corruption.

With MTE, the allocator can assign a new tag when the memory is reused. The old pointer still carries the previous tag, so the CPU notices that it no longer matches.

The stale pointer becomes much less useful.

Buffer overflows

Suppose code allocates a buffer and then writes beyond its boundary. If the neighboring allocation has a different tag, crossing into that allocation causes a mismatch.

Again, MTE does not magically prove that every memory access is correct. It has granularity and probability limitations, and some invalid accesses may remain within the same tagged region.

But it puts another hardware-enforced obstacle between a bug and a working exploit.

That is exactly what defense in depth is supposed to do.

MTE can stop exploitation, not just find bugs

MTE is sometimes discussed as if it were primarily a developer debugging feature. That undersells it.

Yes, MTE is excellent for finding memory bugs during development and testing. Android’s documentation strongly recommends synchronous MTE during development because it can stop the process at the invalid access and provide useful diagnostic information.

But MTE can also run in production.

Android documents three primary operating modes:

SYNC, which reports the fault precisely and terminates the process immediately
ASYNC, which reduces performance cost but reports the fault later
ASYMM, which uses synchronous checks for reads and asynchronous checks for writes

Google’s Android documentation recommends asynchronous MTE in production as a low-overhead memory safety defense. For especially sensitive processes, synchronous checking can be worth the additional cost.

GrapheneOS goes further by using hardware memory tagging as a real exploit mitigation, not merely a crash-reporting mechanism.

That distinction matters.

A debugging feature tells developers that something went wrong. A security mitigation tries to make sure an attacker cannot successfully exploit what went wrong.

MTE can do both.

It is not perfect, and that is not an excuse to remove it

No serious security feature provides absolute protection.

MTE uses a limited tag space. Depending on the allocation strategy, an attacker may have some probability of correctly guessing a tag. MTE also works at a defined memory granularity, so it cannot detect every small out-of-bounds access within the same granule.

It will not fix logical vulnerabilities.

It will not stop a developer from accidentally exposing sensitive data through a badly designed API.

It will not replace sandboxing, control-flow integrity, pointer authentication, safe languages, or timely security updates.

None of this makes MTE unimportant.

Security is not a search for one perfect shield. Modern exploit resistance comes from stacking independent defenses until turning a vulnerability into a reliable compromise becomes expensive, unstable, or impossible.

An attacker may have to:

Find a reachable memory corruption bug.
Bypass the application sandbox.
Defeat address-space randomization.
Work around control-flow protections.
Avoid MTE tag mismatches.
Escape into a more privileged process.
Survive additional kernel and hardware defenses.
Establish persistence despite verified boot.

Remove one of those layers and the attacker has less work to do.

It does not matter that the removed layer was not perfect. Seat belts are not useless because cars also have airbags. Sandboxing is not useless because sandbox escapes exist. MTE is not useless because a determined attacker may sometimes work around it.

The whole point is to make exploitation harder.

Software cannot fully compensate for missing hardware MTE

Android has other approaches for detecting memory corruption.

Tools such as AddressSanitizer, Hardware-assisted AddressSanitizer, and various allocator hardening techniques can catch bugs or make exploitation more difficult. GrapheneOS also has its own hardened memory allocator.

These are valuable, but they are not interchangeable with production-ready hardware tagging.

Traditional sanitizers often carry too much memory or performance overhead for broad use on a consumer phone. Software-based mitigations can also lack the direct, per-access CPU enforcement that makes MTE useful.

Rust and other memory-safe languages are another major part of the solution. Google has already been moving new Android code toward memory-safe implementations, and that is absolutely the right direction.

But rewriting a platform the size of Android takes years. Vendor drivers, native libraries, the Linux kernel, hardware interfaces, and third-party components do not suddenly become memory safe because Google wrote more new code in Rust.

Even in a mostly memory-safe system, unsafe boundaries still exist.

MTE protects the large body of native code that exists now. It also protects software that will not be rewritten anytime soon.

The choice should never have been “Rust or MTE.” We need both.

Use memory-safe languages to prevent new bugs. Use hardware tagging to catch and mitigate the memory bugs that remain.

Why the GrapheneOS reaction matters

GrapheneOS does not support a device simply because it can boot Android.

Its hardware requirements cover long-term firmware updates, verified boot, rollback protection, secure elements, hardware-backed key storage, radio isolation, virtualization, USB attack-surface controls, modern kernel support, and multiple processor-level exploit mitigations.

Hardware memory tagging is explicitly on that list.

The project also says Pixel 8 and later devices use MTE by default for the base operating system and known-compatible apps, with an option to enable it more broadly.

So when GrapheneOS says the Pixel 11 does not meet its standards and may be skipped, this is not a dramatic response to a missing checkbox. Supporting the phone without MTE would mean lowering a security requirement that the project has already established.

I think refusing to quietly lower that standard is the correct response.

Otherwise, hardware vendors learn that security features are optional. They can promote them for a few generations, remove them when inconvenient, and assume everyone will update the marketing slides instead of asking difficult questions.

Skipping a major Pixel generation would be painful for GrapheneOS. Pixels have historically been the main practical hardware platform for the project. A skipped generation could affect users, testing capacity, device availability, and the project’s long-term support planning.

That makes the warning more credible, not less.

There is no obvious benefit for GrapheneOS in refusing to support popular new hardware. If the team is willing to consider doing that, the missing capability is clearly not viewed as cosmetic.

The Pixel 11 may still have strong security

This needs to be said clearly: the absence of MTE does not automatically make the Pixel 11 an insecure phone.

Security is not binary.

The Pixel 11 may still include:

A hardened Android security model
Strong application sandboxing
Verified boot and rollback protection
Hardware-backed key storage
A dedicated secure element
Pointer authentication
Branch target identification
Regular security updates
Improved baseband and subsystem isolation
Better virtualization
New cryptographic protections

Depending on the alternatives, it may still be more secure than many competing phones.

But “still secure overall” and “a meaningful security regression” can both be true.

That nuance often gets lost in product coverage. Reviews reduce security to the number of promised update years or whether a phone has a security chip with a cool name.

Those things matter, but they do not tell the whole story.

A device can gain new defenses while losing an existing one. If the lost defense addresses a major source of current vulnerabilities, users deserve to know.

Quantum-resistant security does not replace MTE

Google’s work on post-quantum cryptography is valuable. Powerful quantum computers could eventually threaten widely used public-key cryptographic systems.

The industry cannot wait until a cryptographically relevant quantum computer appears before starting the transition. New algorithms need standardization, implementation, testing, deployment, and years of compatibility work.

There is also a real “harvest now, decrypt later” concern. Attackers can collect encrypted data today and hope to decrypt it in the future once the required technology exists.

Preparing early is responsible engineering.

But post-quantum cryptography and memory tagging solve entirely different problems.

Quantum-resistant cryptography protects cryptographic operations against a future class of computational attacks. MTE helps prevent attackers from exploiting memory corruption vulnerabilities running on the device right now.

One protects keys, signatures, or encrypted communication against future quantum capabilities.

The other can stop a malicious input from turning a use-after-free bug into code execution today.

You cannot compensate for weaker memory safety by adding stronger cryptography.

If an attacker exploits a process and gains access to sensitive data after it has already been decrypted, the mathematical strength of the encryption algorithm is not the issue. Cryptography protects data in transit and at rest. It does not automatically protect data while compromised software is actively using it.

That is why presenting quantum-resistant features as a counterweight to losing MTE would be misleading.

It would be like removing the locks from your front door and proudly announcing that the basement will be protected against a new drilling technology that may become practical years from now.

Great work on the basement. I still want the front door locked.

MTE protects against the boring bugs attackers actually use

Security marketing loves exotic threats.

Quantum computers sound futuristic. AI-powered attacks sound inevitable. Satellite communication security makes for great launch-event material.

Memory corruption sounds old and messy.

That is exactly why it is dangerous to underestimate it.

Use-after-free bugs and out-of-bounds accesses are not hypothetical. They keep appearing in browsers, operating system kernels, media frameworks, drivers, and vendor components. Attackers do not care whether a vulnerability sounds exciting. They care whether it gives them execution.

A new phone should not trade a practical mitigation against current exploit techniques for a cleaner benchmark result, cheaper CPU configuration, or easier hardware integration.

To be clear, Google has not publicly established that any of those were the reason. I am not claiming to know why MTE is reportedly missing.

I am saying that the bar for removing it should be extremely high.

If there is another hardware mechanism providing equivalent or stronger protection, Google should document it in technical detail. It should explain which memory corruption classes are covered, whether enforcement works on every relevant load and store, how Android enables it, what the performance tradeoffs are, and whether alternative operating systems can use it.

A vague promise of “enhanced security” is not enough.

This also hurts developers

MTE does more than protect end users after a product ships.

When developers can run real software under synchronous hardware tagging, memory bugs become easier to reproduce and diagnose. Instead of discovering silent heap corruption several operations after the original invalid access, the process can stop close to the exact instruction that caused the problem.

That produces better crash reports and shorter debugging sessions.

More importantly, broad MTE use creates real-world coverage that internal testing cannot reproduce. Users exercise strange combinations of features, data, apps, locales, peripherals, network conditions, and timing behavior.

Google’s own Android documentation points out that development tests may not cover every user scenario. That is one reason production MTE is useful.

Removing hardware support does not just weaken exploit resistance on one phone. It removes that phone generation from the pool of devices capable of finding and containing these bugs through hardware tagging.

For an ecosystem as large as Android, that loss adds up.

The precedent worries me most

Hardware security features need continuity.

Developers need to know that a mitigation introduced today will still exist in the next hardware generation. Operating system projects need that continuity before making a feature part of their security architecture. App developers need enough compatible devices to justify testing and enabling it.

The Pixel 8 generation made MTE feel like the beginning of a stronger Android baseline. Pixel 9 and Pixel 10 devices continued to meet GrapheneOS requirements.

If Pixel 11 drops it, the message is awful: do not assume a valuable security primitive will survive even a few product cycles.

That discourages adoption.

Why should an app developer invest time testing MTE compatibility if Google may ship its flagship hardware without it? Why should operating system developers design stronger default policies around a feature that can disappear? Why should users believe claims about hardware-backed protection if those claims come with an invisible expiration date?

Security capabilities should become more common and more mature over time. They should not vanish without a technically convincing replacement.

What Google should do now

First, Google should clearly confirm or deny whether every Pixel 11 model lacks hardware MTE support.

If some models or CPU cores support it and others do not, that needs to be documented too. Partial support can create its own limitations, especially when processes move between heterogeneous CPU cores.

Second, Google should explain the technical reason.

Not in marketing language. Not with a statement about a “multi-layered approach.” Developers need the actual architecture-level explanation.

Third, if another mitigation replaces MTE, Google should publish enough information for independent security researchers and projects such as GrapheneOS to evaluate it.

The replacement should also be available to alternative operating systems. A hardware feature locked behind proprietary stock firmware is not equivalent if GrapheneOS cannot use it.

Finally, Google should restore MTE support in the next revision if there is no equivalent replacement.

Security regressions should be treated as regressions, even when the rest of the product gets faster.

Should you avoid the Pixel 11?

For an average user running stock Android, the answer depends on the complete security picture, update policy, competing devices, and the eventual technical details.

I would not claim that everyone who buys a Pixel 11 is immediately in danger. That would be irresponsible.

But security-conscious buyers should absolutely pause.

If you want to run GrapheneOS, do not assume Pixel 11 support is coming. Wait for an official decision from the project before buying the device. A bootloader that can be unlocked does not guarantee GrapheneOS support, and buying hardware based on an expected future port is always a gamble.

If hardware memory tagging matters to you, the existing Pixel generations supported by GrapheneOS may be the safer choice until the Pixel 11 situation is fully explained.

And if Google eventually confirms that MTE is gone without providing an equivalent mitigation, I would consider that a legitimate reason to skip the generation.

Not because the Pixel 11 has no security.

Because buyers of a premium security-focused phone should not have to accept fewer defenses against one of the most persistent classes of software vulnerabilities.

A shiny future does not excuse weaker security today

I like that Google is investing in quantum-resistant cryptography. The transition to post-quantum systems is necessary, difficult, and easy to postpone until it becomes an emergency.

But security engineering is not a choice between the future and the present.

We need cryptography that can survive tomorrow’s quantum attacks. We also need hardware defenses that make today’s memory corruption bugs harder to exploit.

MTE is not a theoretical feature waiting for a future threat model. It is usable now. Android supports it now. GrapheneOS uses it now. It addresses bug classes attackers target now.

That is why the reported Pixel 11 decision looks so bad.

A new generation of hardware should not force a security-focused operating system to choose between lowering its standards and abandoning the device. A flagship phone should not move backward on practical exploit mitigations while its marketing moves forward.

Until Google provides a convincing technical explanation or an equally strong replacement, removing hardware MTE deserves to be called what it is:

A serious security regression.

DEV Community: David Timothy

How Much Can Websites Really Detect About Brave Users?

Brave is detectable, and that is intentional

Why the traditional User-Agent string often looks like Chrome

Sec-CH-UA says Brave explicitly

JavaScript can ask Brave directly

Brave’s GPU protection is another detectable marker

Brave reveals the default IANA timezone

An IANA timezone contains more information than an offset

A timezone is a regional clue, not proof of location

Why Brave may be reluctant to mask it

What else can a website observe?

High-entropy Client Hints deserve more scrutiny

Display and window information cannot simply disappear

Memory and processor APIs reveal broad hardware classes

GPU information has improved substantially

Fingerprinting is not one thing

Browser identification

Device fingerprinting

Geographic inference

Tracking

Personal identification

What Brave’s privacy model is actually trying to do

The unresolved tension: privacy versus compatibility

What developers should do with this information

Privacy is not binary

Sources

When Regular VPNs Fail, Run Your Own With Outline

The problem is not always the VPN protocol

What GetOutline actually is

Outline is built around Shadowsocks, not a conventional VPN tunnel

The architecture is the real feature

Access keys make small-team administration practical

Running your own Outline server

Use an integrated cloud provider

Bring your own Linux server

What does an Outline server actually cost?

Where Outline makes sense for developers

Privacy improves in some places and gets worse in others

Why I think Outline is worth exploring

Sources

Internet Regulation Is Making Users Easier to Track, Not Cybercriminals Harder to Stop

We keep combining completely different threat models

Cybercrime is not showing signs of being regulated into submission

Age verification shows the problem in miniature

Identity verification creates a second security problem

Metadata surveillance is still surveillance

Developers are becoming an unofficial enforcement layer

Safety controls aren’t useless, but they need to match the adversary

We can verify eligibility without building an identity panopticon

The safest internet is not automatically the most identifiable one

Sources

Windows Is Getting Worse. So Why Does Linux Still Suck in 2026?

Windows is becoming the operating system nobody asked for

Linux should win this argument without trying

There is no Linux desktop

Choice becomes a tax when nobody owns the final experience

Desktop environments are products built on shifting ground

Hardware support is excellent until it suddenly isn’t

NVIDIA is not the whole hardware problem

Linux gaming is a miracle, not a guarantee

Application compatibility is still the wall

Linux configuration is freedom with an invoice attached

Stability depends on which Linux you mean

WSL is a devastating argument against desktop Linux

The Linux desktop does not have an engineering problem

SteamOS proves Linux works when somebody actually curates it

We need a Linux desktop that is willing to be a product

I do not want Windows to win by default

Sources

Sources

I Never Touched AWS and I Still Ship: The Internet Doesn’t Need One Giant Cloud Stack

The cloud became the default before anyone asked why

My stack changes because projects are different

Boring infrastructure has one enormous advantage

Complexity looks impressive, so we keep buying it

You do not need Kubernetes just because it exists

Serverless still has servers and now also has a pricing equation

Managed services manage you too

Cloud pricing is simple until you use the cloud

`Sec-CH-UA` says Brave explicitly