{"@attributes":{"version":"2.0"},"channel":{"title":"Ethan Plant","link":"https:\/\/ethanplant.ca","description":{},"generator":"Zola","language":"en_ca","lastBuildDate":"Tue, 30 Jun 2026 00:00:00 +0000","item":[{"title":"The Black Market of Minecraft Servers","pubDate":"Tue, 30 Jun 2026 00:00:00 +0000","author":"Ethan Plant","link":"https:\/\/ethanplant.ca\/notes\/minecraft-piracy\/","guid":"https:\/\/ethanplant.ca\/notes\/minecraft-piracy\/","description":"

The Entertainment Software Association has found the real threat to the video game industry.<\/p>\n

Not loot boxes. Not live service games that disappear after people pay for them. Not launchers, platform lock-in, mandatory online checks, anti-cheat rootkits, or the slow conversion of purchases into temporary revocable permissions.<\/p>\n

No.<\/p>\n

The threat is apparently Minecraft servers.<\/p>\n

During a California hearing on AB 1921, the Protect Our Games Act, ESA vice president Jennifer Gibbons responded to Assemblymember Chris Ward\u2019s point that games like Minecraft already have community servers by saying, \"They're illegal.\" When asked whether that made them the \"black market\" of video games, she said yes, and added, \"we consider it piracy,\".<\/p>\n

This is one of those moments where the most annoying possible response is also the correct one: no, that is not what those words mean.<\/p>\n

There are illegal private servers. Obviously. A server that copies proprietary code, bypasses authentication, avoids subscriptions, distributes copyrighted assets, or exists to let people play a paid online game without paying for it can raise real legal issues. Nobody serious has to pretend otherwise.<\/p>\n

But \"private server\" is not a synonym for \"pirate server.\"<\/p>\n

That distinction matters because Minecraft is perhaps the worst possible example the ESA could have chosen.<\/p>\n

The official Minecraft website has a page titled \"Download the Minecraft: Java Edition server\u2060\" that asks, \"Want to set up a multiplayer server?\" and then explains how to do exactly that. The same site links to Java Edition servers and Bedrock dedicated servers from its downloads menu. It also points users toward an official third-party server listing site.<\/p>\n

So the position cannot be \"private Minecraft servers are illegal.\"<\/p>\n

The official Microsoft-owned Minecraft site tells people how to run them.<\/p>\n

The more defensible industry argument would be narrower. Publishers could say that some games are not architected for private hosting. They could say releasing server software can be hard, expensive, or risky. They could say some live games involve moderation, anti-cheat, licensed content, payments, account data, or security-sensitive infrastructure. They could say private server support should depend on the game.<\/p>\n

That would still be debatable, but it would at least be an argument.<\/p>\n

Instead, the industry keeps sliding from \"some private servers are unlawful\" to \"private servers are piracy\" to \"letting people continue using a game after official support ends is unreasonable.\"<\/p>\n

That is the part worth paying attention to.<\/p>\n

Because AB 1921\u2060 is not simply a command that every publisher must host every online game forever. The bill applies to server-connected games published for sale on or after January 1, 2027. It defines an end-of-life plan as a plan that gives customers a reasonable expectation that they can continue running or repairing a server-connected game after support ends without further intervention from the publisher. It also requires end-of-life notifications and requires companies to provide information about what customers can do if they want to keep using the game in a secure and effective manner.<\/p>\n

You can oppose that.<\/p>\n

You can say the drafting is too broad. You can say the obligations are unclear. You can argue about multiplayer-only games. You can argue about licensed content, moderation, player safety, cheating, refunds, infrastructure, and whether \"ordinary use\" is precise enough.<\/p>\n

But that is not the same as saying the bill is asking the industry to do the impossible.<\/p>\n

The actual legislative fight is more basic than that framing admits.<\/p>\n

When a company sells a game whose core functionality depends on company-controlled servers, what obligations does it have when it turns those servers off?<\/p>\n

The industry answer is usually some version of: none, beyond notice.<\/p>\n

The consumer answer is usually some version of: then stop selling it like a product.<\/p>\n

That is why the Minecraft example is so revealing.<\/p>\n

Minecraft is not some obscure edge case. It is one of the biggest games in the world. It has official server software, third-party servers, community infrastructure, moderation tradeoffs, and a living example of what player-hosted continuity can look like.<\/p>\n

It does not prove every game can work that way.<\/p>\n

It does prove the category is not inherently absurd.<\/p>\n

And that is why the ESA had to make the category sound absurd.<\/p>\n

If \"private server\" means \"piracy,\" then the discussion ends before it begins. There is no need to talk about end-of-life plans. No need to talk about offline patches. No need to talk about documentation. No need to talk about limited server binaries, LAN mode, self-hosting, preservation builds, authentication removal, or any of the boring technical compromises that might actually keep games playable.<\/p>\n

Just call it piracy.<\/p>\n

Call it the black market.<\/p>\n

Treat the continued use of a purchased game as suspicious by default.<\/p>\n

That is the annoying thing here. Not that an industry lobbyist said something silly in a hearing, though that is very funny. The annoying thing is that the silly thing exposes the underlying worldview.<\/p>\n

The industry is not merely arguing that preservation is difficult.<\/p>\n

It is arguing that control is the product.<\/p>\n

The server is not just infrastructure.<\/p>\n

The dependency is the business model.<\/p>\n

The shutdown is part of the design.<\/p>\n

Once you understand that, the panic over private servers makes sense. A private server is not dangerous because it is always piracy. It is dangerous because it proves the obvious: sometimes the thing can keep working after the company leaves.<\/p>\n

And for an industry increasingly built around the idea that nothing you buy should survive the company\u2019s permission, that is the real black market.<\/p>\n"},{"title":"Adding a Town Square to My Website Because Apparently the Blog Needed a Front Porch","pubDate":"Tue, 30 Jun 2026 00:00:00 +0000","author":"Ethan Plant","link":"https:\/\/ethanplant.ca\/notes\/townsquare\/","guid":"https:\/\/ethanplant.ca\/notes\/townsquare\/","description":"

A website should not need a town square.<\/p>\n

This is, objectively, a ridiculous thing to say. My website is a static site. It has pages. It has notes. It has essays. It has an RSS feed, because I am correct about the web and everyone else simply needs to catch up.<\/p>\n

And yet, somehow, the blog now needs a front porch.<\/p>\n

The thing I am adding is called TownSquare<\/a>. The basic idea is very simple: you drop a small widget onto your site and visitors can see each other, move around a little, wave, say hello, and share the same tiny space for a moment.<\/p>\n

That is it.<\/p>\n

No accounts. No follower graph. No algorithm. No engagement-maximizing machine learning system trying to determine whether someone standing beside a pixel tree is more likely to click an ad for a mattress. Just people briefly existing on the same website at the same time.<\/p>\n

Naturally, I find this extremely charming.<\/p>\n

Part of what I like about the small web is that it does not have to behave like a product category. A personal site does not need to become a platform. It does not need onboarding flows, retention loops, growth teams, reaction buttons, streaks, push notifications, or a mascot that calls you \u201cbestie\u201d while quietly building an advertising profile.<\/p>\n

A personal site can just be a place.<\/p>\n

That sounds obvious, but the modern web has spent the last fifteen years trying to make places disappear. Everything became a feed. Everything became a profile. Everything became a dashboard. Even \"community\" became something you outsourced to Discord, Reddit, Substack comments, Slack, Telegram, or whatever platform happened to be squatting on that particular social pattern at the time.<\/p>\n

The result is that websites often feel strangely uninhabited. Not dead, exactly. More like showrooms. You can read the thing. You can click around. You can subscribe. But you do not really get the sense that anyone else is there.<\/p>\n

TownSquare pushes against that in the smallest possible way.<\/p>\n

It doesn't try to rebuild Twitter in the footer. It doesn't turn the comment section into a second job. It doesn't ask every visitor to create yet another account. It just says: what if, for a moment, the page felt occupied?<\/p>\n

That is a very small idea.<\/p>\n

It is also, annoyingly, a very good one.<\/p>\n

It fits almost too neatly with how I already think about this site. The site is the home. Platforms are edges. RSS is the mailbox. POSSE is the road system. The fediverse is the weird neighbourhood pub where half the regulars are running custom infrastructure and the other half are yelling about content warnings.<\/p>\n

It also fits neatly into an idea I've been circling around recently: a small suite of tools for making a personal website feel less like a static archive and more like an actual home on the web. TownSquare is not exactly one of those tools, at least not mine, but it belongs spiritually in the same world. It is the porch. It is the little public edge of the house. The part where a private website admits, briefly and deliberately, that other people are allowed to be there too.<\/p>\n

A place where someone can wander up, see that someone else is there, maybe wave, maybe say hello, maybe immediately leave because they were only trying to read a note about Canadian digital sovereignty and did not expect to encounter a small person standing near a bench.<\/p>\n

That's fine. The porch does not need to be the point of the house.<\/p>\n

It just changes the feeling of arrival.<\/p>\n

There is also something funny about adding this to a site that is otherwise extremely static. This website is mostly Markdown, Zola, Cloudflare Pages, and stubbornness. There is no database. There is no app server. There is no required JavaScript for reading. It is intentionally boring infrastructure.<\/p>\n

And now, at the bottom of it, there may be tiny people.<\/p>\n

This is exactly the right amount of stupid.<\/p>\n

Of course, because I am me, I cannot look at this without immediately thinking about the broader architecture of the web. TownSquare is interesting because it gestures at something bigger than itself. Not bigger in the startup pitch deck sense. Bigger in the \u201coh, right, websites used to be weird little places connected to other weird little places\u201d sense.<\/p>\n

A map of small public squares is not a social network in the usual sense. It is closer to a neighbourhood. You do not need one global platform if the interesting thing is the connective tissue between independent sites. You do not need to own the town if you can build roads between houses.<\/p>\n

That is the part that gets me.<\/p>\n

The web already has the primitives for this. Links. Feeds. Webmentions. Blogrolls. Search. Human curation. Personal domains. Tiny protocols. Weird experiments. Things that are allowed to be small.<\/p>\n

TownSquare belongs to that tradition. It is not important because it is technically massive. It is important because it remembers that the web can still be playful.<\/p>\n

That matters more than it sounds like it should.<\/p>\n

There is a certain kind of internet person who will see something like this and immediately ask what the business model is, or how it scales, or why anyone would add chat-adjacent behaviour to a static site in the year of our Lord 2026. These are all reasonable questions if your goal is to build a company.<\/p>\n

They are much less interesting questions if your goal is to make a website feel human.<\/p>\n

Not everything has to scale into a venture-backed prison.<\/p>\n

Sometimes the correct answer is: because it is nice.<\/p>\n

Because someone visiting a personal blog and seeing another person wave at them is a little bit delightful. Because the web has become too optimized, too centralized, too flattened, and too professionally unpleasant. Because a lot of what made the older web interesting was not that it was better engineered, but that it had texture.<\/p>\n

A town square is texture.<\/p>\n

I don't know yet how long I will keep it. Any public interaction surface eventually becomes a moderation surface, and I am not na\u00efve about that. If it becomes annoying, I will remove it. If it becomes spammy, I will shut it off. If it breaks the vibe, the vibe wins.<\/p>\n

But I want to try it, at least for a little bit.<\/p>\n

Because the web should have more little experiments like this. More things that make personal sites feel personal. More tools that treat websites as places rather than content delivery endpoints. More projects that make you smile for reasons that do not fit cleanly into a product roadmap.<\/p>\n

So yes, apparently the blog needed a front porch.<\/p>\n

Come stand around in the yard, I guess.<\/p>\n"},{"title":"Bill C-34 Answers Child Safety With Identity Infrastructure","pubDate":"Mon, 29 Jun 2026 00:00:00 +0000","author":"Ethan Plant","link":"https:\/\/ethanplant.ca\/writing\/bill-c-34\/","guid":"https:\/\/ethanplant.ca\/writing\/bill-c-34\/","description":"

\n

This is a long piece, so the short version is: Bill C-34 gets part of the problem right. Platforms should be held accountable for harmful design, weak safety systems, and failures to protect children. But sections 27 to 29 risk turning child safety into age-verification infrastructure for ordinary internet access. That architecture deserves explicit parliamentary debate, not future regulations and Commission guidance.<\/p>\n<\/blockquote>\n

Children should be protected online.<\/p>\n

That is such an obvious statement it feels stupid to write. Of course children should not be left to fend for themselves against harassment, sextortion, bullying, eating disorder pipelines, self-harm content, addictive design, synthetic sexual abuse material, non-consensual intimate imagery, and reccomendation systems that can take a normal moment of teenage vulnerability and turn it into a machine-fed spiral.<\/p>\n

Of course platforms should not be allowed to build engagement engines for children, profit from them, and then act as though the consequences are an unfortunate mystery.<\/p>\n

Of course, the answer is not \"do nothing\".<\/p>\n

But obvious statements are where bad digital policy loves to hide. Because Bill C-34<\/a>, Canada's approach to this problem, does not merely ask whether children should be protected online. It asks a different question: should access to major online spaces depend on age verification or age estimation? That is not really the same question, one is about child safety, the other is about infrastructure.<\/p>\n

Bill C-34, the Safe Social Media Act<\/em>, identifies a real problem. It contains several ideas that point in the right direction. Then it introduces a minimum-age regime that risks turning child safety into generalized age assurance for online public life.<\/p>\n

This is, once again, the same move Ottawa keeps making on digital policy<\/a>. Start with a real harm. Describe it in language no one reasonable wants to oppose. Reach for a broad technical or legal framework. Push the hard implementation details into regulations, guidance, and future discretion. Then act surprised when people who understand how systems behave ask: \"what exactly is being built?\"<\/p>\n

The details, apparently, are where democracy goes to die.<\/p>\n

The second question is the one that matters<\/h2>\n

The public debate around C-34 will be framed around the surface-level question: Should children be protected online?<\/p>\n

Yes. Obviously. That's easy. Next question.<\/p>\n

The harder question is the second one, hiding in the details. Should Canadians have to pass through age-verification or age-estimation systems before participating in online spaces? That's the question C-34 quietly creates.<\/p>\n

The government's own backgrounder<\/a> says online services shape how people in Canada communicate, access information, and participate in civic and cultural life. That is correct. Social media is not just entertainment. It's not just TikTok dances, Instagram filters, Reddit arguments, influencer slop, and whatever fresh hell is happening on X this week. It's also where politicians make announcements, journalists find sources, emergency information spreads, public agencies communicate, unions mobilize, artists publish, local communities organize, marginalized people find each other, and ordinary Canadians participate in public life.<\/p>\n

The modern public square is ugly. It's privately owned, algorithmically distorted, surveillance-funded, outrage-driven, and often terrible. It is still, perhaps unfortunately, a public square.<\/p>\n

That is why the minimum-age provisions in C-34 are so serious. The government cannot describe online services as part of civic and cultural life, and then casually create a legal path to age-gate access to them. If access to social media is access to public discourse, then access controls on social media are access controls on public discourse.<\/p>\n

That does not automatically make every restriction illegitimate. It does not mean children have an unlimited right to use every platform in every context. It does not mean platforms should be free to ignore harm. But it does mean that Parliament should treat this as a major change to how Canadians participate online.<\/p>\n

Instead, C-34 treats it as a minor implementation detail.<\/p>\n

The bill tries to do too much at once<\/h2>\n

The thing about Bill C-34, is it's not really one bill. It is a platform accountability bill, a child safety bill, an age-verification bill, a pornography access bill, an AI chatbot bill, and a Digital Safety Commission bill all stapled together under one title.<\/p>\n

Some of those pieces deserve serious debate on their own. Some are defensible. Some are dangerous. Some are underdeveloped. Some may be salvageable with amendments. But combining all of them into one sprawling framework makes the entire bill harder to understand, harder to scrutinize, and harder to support. This matters because the platform accountability parts of the bill aren't inherently absurd. There is a real case for duties on large social media services. There is a real case for digital safety plans, better reporting tools, blocking tools, age-appropriate design, synthetic content labelling, and obligations around child sexual exploitation material and non-consensual intimate imagery. A narrower bill focused on those duties could probably attract broad support, I'd probably throw my whole support to it and my entire schtick is complaining about Canadian digital policy.<\/p>\n

Instead, the government has bundled those ideas with a 16-year-old minimum age regime, age-verification and age-estimation powers, adult-content access restrictions, AI chatbot rules, and a powerful new regulator that will fill in much of the actual operating model later. That is how you take a broadly shared concern and turn it into a trust exercise.<\/p>\n

The government is asking Canadians to accept the general framework now and wait for the details later. Which services will be covered? Which age-verification methods will be acceptable? How will age estimation work? How will decentralized services comply? What counts as an AI chatbot? What safeguards are enough for an exemption? How will the Commission balance privacy, expression, safety, and access?<\/p>\n

All of that comes later. The regulations will come later. The guidance later. Commission decisions later. Technical standards later. Enforcement practice later.<\/p>\n

That is not good enough, and is honestly a really lazy approach to legislating.<\/p>\n

The implementation details are not administrative trivia. They are the policy. A social media age gate implemented through government ID is one kind of internet. A facial age-estimation system is another. A third-party age-assurance token is another. Device-level or app-store-level enforcement is another. Each creates different risks. Each shifts power to different institutions. Each changes the practical meaning of access. Parliament should not be asked to approve the general vibe and discover the architecture afterward.<\/p>\n

Making this stranger, Parliament already has standalone age-verification legislation before it. Bill S-209<\/a>, the Protecting Young Persons from Exposure to Pornography Act<\/em>, is explicitly aimed at restricting young persons\u2019 online access to pornographic material. If Parliament wants to debate age verification for adult content, it already has a bill through which to do that. Bill C-34 does something different. It imports age-verification logic into a much broader online safety framework covering social media, AI chatbots, platform duties, adult-content access, and a powerful new Commission. This is what happens when scope creep infects a legislative body.<\/p>\n

There is also a political cost to this kitchen-sink approach. The good parts of the bill now have to carry the bad parts. Platform accountability gets tied to age verification. Child protection gets tied to identity infrastructure. AI chatbot regulation gets tied to social media access rules. A debate that should be specific becomes everything all at once. That helps no one except the people who benefit from confusion.<\/p>\n

If the government wants to regulate harmful platform design, it should regulate harmful platform design. If it wants to create an age-verification regime for social media, it should say so clearly and defend that choice directly. If it wants to regulate AI chatbots, it should explain the scope of those rules on their own terms. If it wants to create a powerful Digital Safety Commission, it should be explicit about which decisions Parliament is making and which decisions it is handing to the regulator.<\/p>\n

The good parts make the bad worse<\/h2>\n

The frustrating thing is that parts of Bill C-34 are aimed at the right target. The government correctly identifies that online harms are not only the result of individual behaviour. They are also shaped by how services are designed and operated. Features like algorithmic recommendation systems, engagement-based feeds, autoplay, and endless scrolling can amplify harmful content and increase exposure, especially for young users.<\/p>\n

That's the correct analysis. So regulate that. Regulate recommender systems. Regulate addictive design. Regulate dark patterns. Regulate weak reporting tools. Regulate synthetic sexual abuse material. Regulate non-consensual intimate imagery. Regulate platforms that make it easy to harass people and hard to get help. Require real transparency. Require meaningful safety plans. Require platforms to assess risk, publish what they are doing, and face consequences when they fail.<\/p>\n

Bill C-34, to its credit, does some of this. It creates duties for regulated services. It requires safety-focused and age-appropriate design features. It requires blocking and flagging tools. It requires digital safety plans. It creates duties around harmful content. It has provisions aimed at content that sexually victimizes children or revictimizes survivors. It addresses intimate content communicated without consent, including deepfake sexual images. It creates chatbot-specific duties around harmful content, crisis situations, and manipulative behaviour.<\/p>\n

Good. Do more of that. Please, do more of that. That's holding platforms accountable. That's the correct lane.<\/p>\n

The problem is that the bill does not stop there. It also includes a minimum-age regime for social media accounts. Section 27 requires operators of specified regulated social media services to implement adequate age-verification or age-estimation measures designed to prevent a person under 16 from having an account or otherwise being registered with the service. That's the landmine in the bill. Not because children should be left exposed to harm. Not because platforms are fine. Not because parents should be abandoned. Not because online harms are fake.<\/p>\n

Because age verification is not just a child safety feature. It is infrastructure.<\/p>\n

You cannot verify only children<\/h2>\n

This is the logical conclusion and somehow the part that keeps getting skipped over.<\/p>\n

A platform cannot enforce a ban on under-16 users by checking only under-16 users. It doesn't know who they are. To find out who is under 16, it has to assess everyone. It has to distinguish the 15-year-old from the 16-year-old, the 16-year-old from the 18-year-old, and the adult from the teenager. That means everyone gets pulled into the age-assurance flow.<\/p>\n

The government may call this age verification. It may call it age estimation. It may call it privacy-preserving. It may call it proportionate. It may call it a safeguard. It may say only specified regulated services will be covered. It may say the Commission will decide what is adequate. It may say personal information must be destroyed after the age check is complete.<\/p>\n

But the experience from the user's perspective is simple. Before you can participate, prove you're old enough. Maybe it uses government ID. Maybe it uses a third-party token. Maybe it uses facial age estimation. Maybe it uses account history. Maybe it uses behavioural signals. Maybe it uses app-store-level controls. Maybe it uses some vendor that claims to verify age without revealing identity. Maybe the platform doesn't learn your exact age but receives a pass\/fail result.<\/p>\n

Those details matter. Some versions are worse than others. But none of them answer the burning question.<\/p>\n

Should Canadians have to pass through an age-assurance system to participate in major online public forums?<\/p>\n

Bill C-34 appears to answer: yes, if the service is specified by regulation and the Commission considers the measures adequate.<\/p>\n

\u201cAge estimation\u201d is not a magic privacy wand<\/h2>\n

The bill doesn't only talk about age verification. It also talks about \"age estimation\".<\/p>\n

This is meant to sound softer. It may not require government ID. It may not require uploading documents. It may not require the platform to know exactly who you are. It may involve estimating age from signals rather than verifying identity directly.<\/p>\n

Unfortunately, age estimation is still not harmless. If a service estimates your age from your face, that raises biometric and discrimination concerns. If it estimates your age from your behaviour, that raises surveillance concerns. If it estimates your age from account history, device signals, social graph, usage patterns, or data broker information, that raises profiling concerns. If it relies on a third-party vendor, that creates a new compliance layer between Canadians and public online participation.<\/p>\n

And if the estimate is wrong, then what? Does a 17-year-old with a young-looking face get locked out? Does a 15-year-old who looks older get waved through? Does a privacy-conscious adult who refuses to complete an age check lose access? Does a person without conventional documentation get pushed into a harder flow? Does a trans person, a racialized person, a person with a disability, or someone who simply does not fit the training data get misclassified?<\/p>\n

The bill says measures must not unreasonably or disproportionately limit users\u2019 expression. That's nice language, but it doesn't actually solve the problem. It just gives the regulator a balancing exercise after the architecture has already been accepted. Once the system is built around age checks, expression becomes something the system promises not to limit too much.<\/p>\n

The privacy safeguards don't solve the architectural problem<\/h2>\n

Bill C-34 does, to its credit, contain privacy safeguards around age verification and age estimation. The Commission must be satisfied that the measures are effective, that personal information is not collected or used except for age-verification or age-estimation purposes, that the personal information is destroyed once the verification or estimation is complete, and that it is protected until destruction.<\/p>\n

Those safeguards are better than not having safeguards. I will give them at least that much.<\/p>\n

They are, however, not enough. The problem is not only what happens to the data after it is collected. The problem is that access to public online spaces becomes conditional on submitting to the process in the first place.<\/p>\n

\u201cDo not worry, the checkpoint deletes your papers after inspecting them\u201d is not the same as \u201cthere is no checkpoint.\u201d<\/p>\n

\u201cDo not worry, the vendor only uses your face to estimate your age\u201d is not the same as \u201cyou do not need to scan your face to participate.\u201d<\/p>\n

\u201cDo not worry, the platform only receives a token\u201d is not the same as \u201cthe platform does not get to demand proof that you are allowed to be there.\u201d<\/p>\n

Privacy is more than just data retention. Privacy is also freedom from unnecessary verification. Freedom from being forced into identity-adjacent systems. Freedom from being made legible as a condition of participation. Privacy is what a system forces you to reveal, what it can infer, and what other systems can connect later.<\/a>.<\/p>\n

Bill C-34 tries to manage the consequences of age verification. It does not justify why age verification should become a condition of access to social media in the first place.<\/p>\n

Section 28: \"We'll figure it out later\"<\/h2>\n

Section 27 of the bill is the obvious problem people will focus on because it says age-verification or age-estimation measures.<\/p>\n

Section 28 may be even more important. In plain language, it says an operator of a specified regulated social media service must implement any measures provided for by regulations that prevent people under 16 from having an account or being otherwise registered with the service.<\/p>\n

Any measures.<\/p>\n

Provided for by regulations.<\/p>\n

That is where the real implementation fight is going to happen.<\/p>\n

This is another Canadian digital policy classic. Parliament is asked to approve the broad structure, while the operational details are pushed into regulations, guidelines, Commission decisions, and future processes. The scary part is not always fully visible at first reading. It arrives later as compliance guidance.<\/p>\n

In this case though, the enforcement mechanism is the policy. The law doesn't need to say \u201cupload your ID to use Instagram\u201d to create ID-for-the-internet pressure. It only needs to make platforms responsible for keeping under-16 users out while giving regulators the power to decide what counts as adequate.<\/p>\n

Platforms will do what regulated entities always do. They will minimize their regulatory risk. If the penalty for letting underage users in is severe, and the penalty for making everyone verify is mostly reputational, the incentive is obvious. Regulatory compliance teams, for completely understandable reasons, pretty much always take the path of least-resistance.<\/p>\n

The Commission is where the real architecture will be written<\/h2>\n

Amongst other things, Bill C-34 creates a powerful \"Digital Safety Commission\".<\/p>\n

Some form of expert regulator may make sense for online safety. Parliament cannot write every technical detail into a statute. Platforms change quickly. Harms evolve. Design patterns shift. Regulators can build expertise, monitor compliance, and respond to evidence in ways that Parliament often cannot. That's the charitable version of this.<\/p>\n

The less charitable version is that Bill C-34 asks Parliament to create the machine first and find out how it works later. The Commission will not just be a passive administrator. It will shape regulations, issue guidance, assess compliance, manage complaints, conduct audits, issue orders, levy penalties, and decide whether services qualify for exemptions from the minimum-age regime.<\/p>\n

In practice, that means many of the most important questions will be answered after the bill passes.Which services will be covered? What age-verification or age-estimation measures will count as adequate? What safeguards will be required for an exemption? How will the Commission treat federated services? What happens when a service uses a privacy-preserving token? What happens when a user refuses to complete an age check? What error rate is acceptable? What appeal process is required? What happens when the verification vendor is wrong?<\/p>\n

A law that says \u201cthe Commission will figure it out\u201d is still a law creating the power to figure it out. Once Parliament creates the framework, the political argument shifts. The question stops being whether Canada should build age-verification infrastructure for social media and becomes how the regulator should implement the age-verification infrastructure Parliament has already authorized.<\/p>\n

That is exactly the wrong sequence. The hardest questions should be answered before the power is created, not after.<\/p>\n

The exemption model proves the default is exclusion<\/h2>\n

Section 29 allows the Commission to exempt a regulated social media service from the minimum-age provisions if the Commission is satisfied that the service provides adequate safeguards for the protection of children. On paper, that sounds completely reasonable. Supporters will argue Section 29 shows this isn't a complete ban, that services can get an exemption, they just need to prove that they're safe enough.<\/p>\n

But the structure here matters. The default is still exclusion. That means platforms are pushed into one of two models. Either exclude under-16s through age verification or age estimation, or convince the Commission that their safeguards are good enough to be exempted.<\/p>\n

If the government believes the real problem is harmful platform design, the baseline duty should be safer design. Full stop. Not \u201cexclude young people unless you can satisfy the regulator.\u201d Not \u201cage-gate first, ask for an exemption later.\u201d<\/p>\n

The exemption model also gives the Commission enormous influence over the shape of online childhood. What counts as adequate safeguards? Who decides? Based on what evidence? How transparent will the process be? How will children\u2019s own perspectives be included? How will the Commission weigh privacy, expression, mental health, safety, autonomy, and access to community?<\/p>\n

A 15-year-old is not a toddler. A 15-year-old can work. A 15-year-old can organize. A 15-year-old can write, code, publish, volunteer, protest, explore identity, seek help, and participate in civic life. Treating every person under 16 as someone to be removed from major public online spaces is not a small design choice. It's a statement about young people's agency.<\/p>\n

This will not hit all children equally<\/h2>\n

One of the common defences of this type of legislation is that parents aren't doing enough to parent their children online. There is some truth buried in that complaint. Many parents are overwhelmed. Many do not understand the platforms their children use. Many are fighting products designed by some of the richest companies in the world to capture attention, encourage compulsion, and make opting out socially difficult. \u201cJust parent better\u201d is not a serious answer to that.<\/p>\n

But a government ban does not solve the parenting problem. It often just reproduces it. Blunt bans rarely, if ever, protect the vulnerable as cleanly as their supporters imagine. Some young people will comply. The ones most likely to comply are often the ones with stable homes, attentive parents, reliable devices, supportive schools, and relatively lower risk. They are the teenagers whose parents are already involved, whose online activity is already somewhat supervised, and whose offline life gives them other places to go.<\/p>\n

The young people in the most vulnerable positions, the ones this legislation is supposed to protect, are also the ones most likely to route around the system. A teenager in an abusive household may need online access their parents don't approve of. A queer or trans teenager in an unsafe home may need pseudonymous communities. A young person being bullied may need somewhere outside their school and family environment to talk. A teenager experiencing exploitation may need access to information, support, or people who can help. A young person with unstable housing, poor family support, or mental health struggles may not experience the internet as a frivolous distraction. They may experience it as one of the few places where they can find privacy, language, community, or escape.<\/p>\n

Those are exactly the young people who are least helped by a policy that assumes parents are available, safe, and capable of acting as the main enforcement layer. They are also exactly the young people least likely to respond to a ban by calmly logging off. They will find older accounts, shared accounts, fake birthdays, VPNs, foreign services, alternate app stores, browser versions, private servers, smaller platforms, gaming chats, encrypted groups, or whatever workaround appears five minutes after implementation. Teenagers are very good at bypassing rules written by adults who believe \u201ccreate account\u201d is a meaningful control boundary.<\/p>\n

The result is predictable. Lower-risk teenagers are more likely to be blocked from mainstream services. Higher-risk teenagers are more likely to remain online, but in less visible and less accountable spaces. If young people are pushed away from large regulated platforms with safety teams, reporting tools, transparency obligations, parental controls, and public scrutiny, where do they go? Smaller services. Foreign services. Less moderated spaces. Private communities. Encrypted groups. Platforms with no Canadian presence, no meaningful reporting tools, no compliance staff, and no easy way for regulators to intervene.<\/p>\n

A policy can succeed on paper while making harm harder to see. It can reduce the number of under-16 accounts on mainstream platforms while increasing the number of vulnerable young people using less visible workarounds. It can make adults feel that a boundary has been drawn while pushing the hardest cases into places where the boundary is least enforceable. It can make the problem quieter without making young people safer.<\/p>\n

That is the recurring failure of blunt access bans. They are easiest to enforce against the people least likely to be in danger, and easiest to evade by the people whose danger is already hardest to detect. One just needs to look at the failure of Australia's attempt to confirm this<\/a>. If the government\u2019s goal is to protect vulnerable young people, it should be very careful about policies that reward invisibility.<\/p>\n

The bill has an outdated view of social media<\/h2>\n

Bill C-34 also seems to assume that social media still means one company, one platform, one database, one login system, and one operator with practical control over the whole service. That is how Facebook works. That is how Instagram works. That is how TikTok works. That is mostly how Reddit works.<\/p>\n

It is however, not how the modern social web is evolving. Mastodon is not one service. It is thousands of independently operated servers speaking a shared protocol. Lemmy is not one service. It is a federated network of communities and instances. Bluesky is more centralized in practice today, but its underlying protocol is explicitly designed around federated components: personal data servers, relays, app views, feed generators, and labelers.<\/p>\n

Bill C-34 keeps talking about \u201cthe operator\u201d as though there is always one obvious entity with the ability to enforce the law across the service. In federated systems, that assumption falls apart entirely. Who is the operator of Mastodon? The non-profit developing the software? The administrator of mastodon.social? The person running a tiny instance for twenty friends? The Canadian instance that displays a post? The foreign instance where the post originated? The user who self-hosts? The relay? The app? The moderation service? There's no single front door, no single entity in control. That's the whole point.<\/p>\n

A centralized platform can comply with an age-verification mandate by putting a checkpoint in front of account creation. That is obviously bad for privacy, but at least the implementation model is obvious. A federated platform cannot do that without either pushing the mandate down to every participating server, breaking interoperability with servers that do not comply, or recreating centralized control layers on top of a system designed not to have them. Every option is bad.<\/p>\n

If every Mastodon or Lemmy instance has to implement age verification, the law becomes impossible for small community-run servers to comply with. If large instances block non-compliant instances, the fediverse fractures along regulatory lines. If app stores, clients, relays, or hosting providers become responsible, enforcement shifts away from the actual social interaction layer and toward infrastructure choke points. If only large services are covered, then the law creates a strange two-tier internet where centralized platforms are age-gated and federated systems sit in a legal grey zone until regulators decide what to do with them.<\/p>\n

The government says online services shape civic and cultural life. The federated social web is part of that life. It is one of the few serious attempts to build social media that is not entirely controlled by a handful of giant companies. It is exactly the kind of architecture a digital sovereignty agenda should want more of: portable identity, interoperable protocols, smaller communities, local moderation, user choice, and less dependence on monopolistic platforms.<\/p>\n

Bill C-34 seems to have no idea what to do with that, and that should worry anyone who cares about decentralization. A law that only works cleanly when applied to centralized platforms will tend to favour centralized platforms. They have compliance teams. They have lawyers. They have trust and safety departments. They have identity vendors. They have policy staff. They can absorb regulatory complexity and turn it into a moat. Small federated services simply cannot.<\/p>\n

The result is perverse. A bill supposedly aimed at making social media safer may end up entrenching the very platform model that made social media so powerful, so addictive, and so difficult to govern in the first place. At this point it's not just a privacy problem. It's a competition problem. It's an interoperability problem. It's a digital sovereignty problem. It is a sign that the government is trying to regulate the social internet as though the only possible model is the centralized corporate platform.<\/p>\n

That is probably the worst possible lesson to take from the past two decades. If Canada wants safer social media, it should not write laws that make decentralized alternatives harder to operate. It should be encouraging smaller communities, open protocols, user-controlled moderation, portability, and pluralism. Instead, Bill C-34 risks telling the independent social web: become more like the platforms, or become legally impossible.<\/p>\n

The access-control logic will spread<\/h2>\n

The problem with age gates is that they rarely remain isolated. Once a service has to know whether a user is over 16 for social media access, why stop there? If the same service hosts adult content, it may also need to know whether a user is over 18. If the service has AI chatbots, it may need age-specific safeguards there too. If future legislation adds new categories of content, new thresholds can be layered onto the same access-control architecture.<\/p>\n

That's how these systems expand. The first threshold is justified by the most sympathetic case. The second threshold is easier because the infrastructure already exists. The third threshold becomes a minor administrative detail. This isn't a slippery slope argument in the lazy sense. It's a systems argument, this is just the nature of how systems evolve. When a system exists, people find uses for it. When vendors build products, they sell them. When platforms integrate compliance flows, they reuse them. When regulators learn that access can be conditioned on age, identity, or eligibility, future policy debates start from that assumption.<\/p>\n

The real risk is not only that Bill C-34 creates an age gate for social media. It is that it normalizes age gates as a tool for governing public online life. The government will say the safeguards are narrow. Maybe they are, for now. But infrastructure has this pesky way of outliving the political assurances that created it.<\/p>\n

The VPN problem is not a footnote<\/h2>\n

Any serious under-16 social media ban immediately runs into the problem of VPNs. If a child can route traffic through another country, use foreign app stores, or access web versions of services through non-Canadian endpoints, enforcement becomes harder. That does not mean enforcement is impossible, but it does mean that the pressure quickly moves outward.<\/p>\n

First, platforms must verify age. Then, they must detect evasion. Then, app stores need to cooperate. Then, payment systems, device makers, browsers, operating systems, and network providers are asked to help. Then VPNs become suspicious because they allow users to bypass geography-based restrictions. Then privacy tools start looking like compliance problems.<\/p>\n

This is not an abstract concern. It is the same pattern we see again and again in internet regulation. The first law targets a sympathetic harm. The enforcement problem then becomes an argument for expanding the law\u2019s reach. Each additional layer is justified as necessary because the previous layer was incomplete. And because children are involved, anyone objecting can be accused of defending harm, it's why \"think of the children\" is an argument governments the world over instantly reach for.<\/p>\n

Privacy is not suspicious<\/h2>\n

The worst argument for this kind of policy is the \u201cnothing to hide\u201d argument. Maybe people who care about privacy should not be online, the argument goes. Maybe if they refuse to verify themselves, that is fine. Maybe it is even good. Maybe the people with the most to hide will leave.<\/p>\n

This is, in the nicest way possible, deranged.<\/p>\n

Privacy is not evidence of guilt. Anonymity is not inherently illegitimate. Pseudonymity is not a loophole. The ability to speak, read, explore, and participate without tying every action to a verified identity is not a concession to criminals. It is one of the conditions that makes a free and democratic society possible.<\/p>\n

People have things to hide because people have lives. They have medical questions, political beliefs, religious doubts, sexual identities, family problems, workplace complaints, private fears, unpopular opinions, and thoughts they have not finished thinking yet.<\/p>\n

The people who most need privacy are often the people most harmed when systems demand verification. Vulnerable youth. Abuse victims. Whistleblowers. Journalists. Political dissidents. Queer and trans people. People in small communities. People without stable documentation. People seeking sensitive information. People who are not doing anything wrong and still don't want to be turned into a compliance record.<\/p>\n

A democracy should not treat privacy as suspicious. A democracy cannot treat privacy as suspicious. The burden should be on the state to justify intrusion, not on the public to justify privacy.<\/p>\n

Once again, this is bad digital sovereignty<\/h2>\n

Bill C-34 also fits into a larger Canadian problem, one I've already written about at length<\/a>. Canada says it wants digital sovereignty. It says it wants trustworthy infrastructure, public accountability, resilience, and the ability to make its own choices in a world dominated by foreign technology platforms. Then it keeps proposing policies that make Canadian digital life more permissioned, more compliance-heavy, more centralized, more dependent on opaque intermediaries, and less trustworthy. This is somehow mistaking digital sovereignty for digital bureaucracy.<\/p>\n

A sovereign internet is not one where Canadians need permission slips to participate. It is not one where access to major public forums depends on verification vendors, platform compliance teams, regulator guidance, and future regulations that ordinary people will never read. It is not one where privacy tools become suspect because they complicate enforcement.<\/p>\n

Real digital sovereignty should mean Canadians have more control over the systems they depend on. More privacy. More resilience. More domestic capacity. More public trust. More open standards. More competition. More ability to leave platforms without leaving public life. Bill C-34 points in the opposite direction when it treats access as the control point. It says: we cannot make the platforms safe enough, so we will decide who is allowed through the door.<\/p>\n

The bill should be amended<\/h2>\n

The government can still fix this. It should keep the platform accountability parts. It should strengthen them. It should focus on the systems that create and amplify harm. Require meaningful risk assessments. Require public digital safety plans that are actually useful. Require accessible reporting and appeal mechanisms. Require strong action on child sexual exploitation material and non-consensual intimate imagery. Require safer defaults for minors. Require transparency around recommender systems. Require limits on addictive design. Require labels for synthetic content where appropriate. Require platforms to make blocking and reporting tools easy to find and easy to use. Require independent audits. Require evidence. Genuinely, I'd love to write a positive article for once.<\/p>\n

But remove or radically narrow the minimum-age regime. At minimum, Parliament should not pass sections 27 to 29 in their current form. If the government insists on age-related protections, they should be built around age-appropriate design, not generalized age verification. The law should prohibit mandatory government ID checks, biometric age estimation, face scanning, and third-party identity verification as conditions of ordinary social media access. It should require privacy impact assessments. It should require public technical standards before implementation. It should give the Privacy Commissioner more than consultation. It should include explicit protections for anonymous and pseudonymous participation. It should ensure that refusals to complete age checks do not automatically become grounds for exclusion from public online spaces.<\/p>\n

Most importantly, it should not outsource the real debate to future regulations. Parliament should decide whether Canada is creating age-verification infrastructure for social media. Not the Commission later. Not Cabinet later. Not compliance vendors later. Not platforms quietly implementing whatever minimizes liability.<\/p>\n

Parliament.<\/p>\n

Now.<\/p>\n

In public.<\/p>\n

The problem is the architecture<\/h2>\n

The government will say this is about safety. It is, any attempt to deny that is making the lazy version of the argument. But safety is not the only value in a democracy. Privacy matters. Expression matters. Access matters. Youth autonomy matters. Public participation matters. Technical architecture matters.<\/p>\n

If the architecture requires everyone to prove they are old enough before entering major public online spaces, then the law has changed what the internet is. It has made participation conditional. It has made access something to be granted after verification. It has made privacy something to be balanced after the checkpoint has already been built.<\/p>\n

Children deserve protection online. They deserve platforms that are not engineered to exploit them. Parents deserve better tools. Users deserve reporting systems that work. Survivors deserve fast action. The public deserves transparency. Regulators deserve real powers. Platforms deserve much less deference than they currently receive. But Canadians also deserve an internet where privacy is not suspicious, pseudonymity is not treated as a problem to be solved, decentralized communities are not regulated out of existence, and participation in public life does not require passing through an age-assurance system.<\/p>\n

Bill C-34, admittedly, gets some things right. That's probably why I'm frustrated. The government correctly identified that online services shape civic life. It correctly identified that platform design can amplify harm. It correctly identified that voluntary action has not kept pace. It correctly identified that children need protection. It correctly identified that platforms need duties.<\/p>\n

Then it reached for age verification. Once again, Ottawa found a real digital policy problem and answered it with infrastructure that should make Canadians nervous.<\/p>\n

The issue at hand is not whether children should be protected. Obviously they should. The issue is whether protecting children requires building a system where everyone may have to prove they are allowed to participate. That's not some minor implementation detail to figure out later.<\/p>\n

That is the whole fight.<\/p>\n"},{"title":"Canada Day is Coming. May God help us all.","pubDate":"Mon, 22 Jun 2026 00:00:00 +0000","author":"Ethan Plant","link":"https:\/\/ethanplant.ca\/notes\/canada-day-is-coming\/","guid":"https:\/\/ethanplant.ca\/notes\/canada-day-is-coming\/","description":"

There are certain sentences that sound harmless until you happen to live in Vancouver in June 2026. \"The World Cup is in town.\" \"Canada Day is next week\". \"There is a big event downtown.\" \"The trains may be busy.\"<\/p>\n

Each one, on its own, is manageable. Vancouver has handled big crowds before. We are a city of fireworks, concerts, cruise ships, Stanley Cup trauma, beach weather, Canucks hope, Olympic legacy, and the annual civic ritual of pretending the Canada Line was built for the number of people who actually use it.<\/p>\n

But this year feels different.<\/p>\n

This year, Canada Day is not arriving in isolation. It is arriving in the middle of the World Cup. It is arriving after Vancouver has already remembered that international football fans are loud, joyful, relentless, and apparently capable of turning a regular weeknight into a moving street festival. It is arriving in a city where people are already watching matches in pubs, gathering at fan events, packing trains, waving flags, and discovering that, yes, we do in fact have national emotions when the circumstances demand it.<\/p>\n

May God help us all.<\/p>\n

The problem is not that any one thing is too much. The problem is that everything is happening at once. Canada Day in Vancouver is already a strange beast. Downtown fills up. The waterfront becomes a human conveyor belt. Every patio is full. Every transit station develops a thousand-yard stare. Someone, somewhere, decides that the correct response to national pride is standing motionless at the top of an escalator.<\/p>\n

Now add the World Cup into the mix.<\/p>\n

Add visitors who do not know that Waterfront Station is less of a station and more of a psychological experiment. Add locals who absolutely should know better but will still attempt to \u201cjust grab the train\u201d at the worst possible moment. Add people in jerseys, people in flags, people in face paint, people trying to get to Canada Place, people trying to get to the PNE, people trying to get home, people trying to get anywhere, and one guy in a Canucks jersey who has somehow decided this is also about him.<\/p>\n

And then, because fate has a sense of humour, I did the math. This was a mistake. Because now Wednesday is looking at the city like a loaded shotgun.<\/p>\n

Canada plays Switzerland on Wednesday. If Canada wins or draws, Canada finishes top of Group B. That alone would be absurd enough, because we are not emotionally prepared to be the kind of country casually doing World Cup group-stage arithmetic with consequences.<\/p>\n

But the consequences are the important part. Top of Group B means Canada plays its Round of 32 match in Vancouver on July 2.<\/p>\n

Which means Canada Day would not simply be Canada Day.<\/p>\n

It would be Canada Day, in Vancouver, during the World Cup, immediately before Canada plays a home knockout match at BC Place.<\/p>\n

And not just any knockout match.<\/p>\n

Canada\u2019s first ever men\u2019s World Cup knockout match.<\/p>\n

On home soil.<\/p>\n

After Canada's first ever men's World Cup win. After a 6\u20130 demolition of Qatar in Vancouver that made the city sound like it had briefly remembered it was allowed to feel things.<\/p>\n

That is the part that makes this feel less like scheduling and more like prophecy. This would not merely be another match. This would be one of those weird civic moments where sports, geography, timing, national identity, and transit capacity all collide in public. A country gets its first World Cup win. The win is not a squeaker. It is not a lucky bounce. It is 6\u20130. It is domination. It happens at home. The crowd loses its mind. The city hears it from blocks away.<\/p>\n

Then, if Canada can get past Switzerland with even a draw, the reward is a knockout match back in Vancouver the day after Canada Day. This is how you accidentally create a Heritage Moment.<\/p>\n

There is going to be some poor transit planner looking at the numbers like they are reading a cursed text. There is going to be someone at TransLink staring into the middle distance. There is going to be a police officer on Granville who has accepted that the next forty-eight hours belong to a force larger than municipal authority. There is going to be a tourist asking if it is always like this, and some exhausted local saying, \u201cNo. Somehow worse.\u201d<\/p>\n

This is the thing about Vancouver: for all our reputation as no fun city, the city does occasionally remember how to lose its mind. It just needs permission. A playoff run will do it. A gold medal will do it. A perfect summer evening will do it. Apparently, so will the World Cup. And Canada Day gives everyone permission at once.<\/p>\n

That is the dangerous part. Not dangerous in the grim sense. Dangerous in the \u201cthis is going to become a story people tell later\u201d sense. Dangerous in the \u201cI tried to take the SkyTrain and became part of Canadian history\u201d sense. Dangerous in the \u201cthe city has exceeded its recommended daily intake of vibes\u201d sense.<\/p>\n

Because there is something genuinely lovely about it too. Canada Day can sometimes feel a little awkward, a little staged, a little too laminated. But World Cup energy is not laminated. It is not orderly. It is not contained by a polite programming schedule. It spills. It echoes. It turns strangers into a crowd. It makes people cheer from patios and balconies and open windows. It gives the city a pulse loud enough to hear from blocks away.<\/p>\n

That is what I noticed during Canada\u2019s match against Qatar. I didn't need to be watching to know something had happened. I could hear it. Every goal came rolling through the neighbourhood as a wave of sound. The sound of a country having a moment.<\/p>\n

As a proud Canadian, I am happy to cheer right alongside it. But I am also realistic.<\/p>\n

Canada Day is coming. The World Cup is here. Canada may be one result away from turning July 1 into the unofficial pre-party for the most important men\u2019s soccer match this country has ever played on home soil. Vancouver is about to combine national celebration, global sport, summer crowds, downtown bottlenecks, historical catharsis, and a transit network that already looks personally offended by the concept of demand.<\/p>\n

May God help us all.<\/p>\n

May God help the poor person who thinks they can casually transfer at Waterfront.<\/p>\n

May God especially help the Canada Line.<\/p>\n

She was not built for this.<\/p>\n

But she will be asked to serve.<\/p>\n

And honestly, at a certain point, there is no use resisting the pageantry of it. If Canada insists on getting its first men\u2019s World Cup win at home, threatening to win its group, and possibly playing its first ever knockout match in Vancouver the day after Canada Day, then fine. The bit has earned its trumpets.<\/p>\n

God save our King and Heaven bless.<\/p>\n

The maple leaf forever.<\/p>\n"},{"title":"Bridger Is Building an OSINT Dossier in a Cute Font","pubDate":"Wed, 10 Jun 2026 00:00:00 +0000","author":"Ethan Plant","link":"https:\/\/ethanplant.ca\/writing\/bridger\/","guid":"https:\/\/ethanplant.ca\/writing\/bridger\/","description":"

I was scrolling through Instagram, because unfortunately I am not immune to doomscrolling, when I came across a reel advertising bridger.social<\/a>. Bridger claims, in its own words, to be \"A close-friends social media built to help you actually connect.\" The antithesis of modern-day social media.<\/p>\n

That pitch, at first glance, is exactly the sort of thing that should get me very excited. A close-friends social app. No endless scroll. No influencers. No AI slop. No follower-count brain poison. No ad-choked feeds where the people you actually care about are buried under a mountain of algorithmic sludge.<\/p>\n

Just a social app, for actual friends to stay in touch. A product that says, in effect, \"you were not supposed to spend your life scrolling\". A social media platform that says, \"this belongs to you, the user\".<\/p>\n

I'm exactly the target audience for that type of claim. I care about digital sovereignty. I care about user control, exit rights, local-first software, open systems, and the difference between using software and being used by it. This whole website essentially exists because I think people should have homes on the internet that aren't just rented rooms inside other people's platforms. I am, admittedly, very easy to bait with the phrase \"user-owned\".<\/p>\n

Naturally, I had some skepticism going in. I wondered what \u201cuser-owned\u201d actually meant. I wondered whether the code would be open source. I wondered whether users would have real exit rights. I wondered about data portability, federation, self-hosting, APIs, contributor rights, governance, ads, and the business model. All of the boring questions that make the infrastructure engineer in me happy.<\/p>\n

Then, I opened the beta. And I slowly realized I was looking at the most horrifying thing I've seen on the internet in a while.<\/p>\n

My initial response to Bridger may have been a healthy dose of architectural skepticism. My second reaction was incident response. Because, as I explored the beta, the problem wasn't merely that Bridger hadn't fully explained its governance model.<\/p>\n

The problem was the product was asking users to build an extensive identity dossier. Not metaphorically. Not in some abstract \"all data collection is bad\" sense. I mean it was asking for exactly the kinds of details that privacy, security, and OSINT people spend their time warning about.<\/p>\n

The trust problem started immediately<\/h2>\n

Bridger's sign-up flow managed to be both casual and invasive in the worst possible combination. To start, I never received any kind of validation email. No confirmation link. No verification code. No proof that I controlled the email address I had entered. As far as I can tell, the beta let me proceed without completing even the most basic account-integrity step.<\/p>\n

It did, however, ask for my date of birth for \"age verification\". The box explicitly says: \"Used for age verification only. Never shown to others.\"<\/p>\n

\"Bridger<\/p>\n

There's a really strange set of priorities here. The product made no attempt to verify my email, arguably the most basic fraud prevention step, but demanded my date of birth immediately.<\/p>\n

And date of birth isn't a throwaway field. It's identity-adjacent. It's frequently used in account recovery, identity matching, eligibility checks, advertising systems, and data-broker enrichment. It can become sensitive very quickly when combined with a name, email address, friend graph, location context, profile preferences, daily posts, and social activity.<\/p>\n

It is also not, by itself, \"age verification\". A user typing a birth date does not prove their age. It proves they can type a birth date. Maybe that is acceptable for a low-risk beta. Maybe it's a placeholder while regulatory compliance is figured out. Maybe the team plans something more serious later. But then call it what it is. Do not collect date of birth under the reassuring label of \"age verification\" while leaving the rest of the trust model underdeveloped.<\/p>\n

The sign-up flow also immediately asked for my first and last name. I gave it only my first name, because what, exactly, had this product done to earn my full government name? A close-friends app may need a display name. It may need a handle. It may eventually need billing information if someone becomes a paying member. It may allow users to share their real names with people they already trust. But \u201cfirst and last name\u201d immediately at signup is a very different choice. It treats real identity as the default.<\/p>\n

I admit this is nitpicking a beta website's sign-up flow, and it's not out of the ordinary for a social media platform. But if a platform's public messaging is \"we care deeply about privacy\", I feel I reserve the right to be deeply critical.<\/p>\n

The privacy-preserving version of this flow would ask: \"What should your friends call you?\" It would separate display identity from legal identity. It would make full names optional. It would explain clearly who can see them. It would not require more trust than the product has earned.<\/p>\n

Then came the profile flow<\/h2>\n

The profile setup flow is when things went from \"concerning but it's a beta\", to horrific.<\/p>\n

Immediately I clicked on \"Setup your profile\" and I'm greeted by a 29-step workflow and a screen asking me to select my hobbies. A bit long, but no red flags so far.<\/p>\n

\"Bridger<\/p>\n

I clicked through a bit more and got asked for my birthday... again. During signup, Bridger asked for my date of birth for \u201cage verification\u201d and reassured me that it would never be shown. Then, later in the profile flow, it asks: \u201cWhen is your birthday?\u201d with month, day, and year fields, followed by visibility options: Close Friends, Wider Friend Group, and All Acquaintances.<\/p>\n

\"Bridger<\/p>\n

Maybe these are technically separate fields. Maybe the signup date of birth is intended for age gating, while the profile birthday is intended as an optional social field. That can be a legitimate distinction. But the product doesn't make that distinction, if any, clear to the user.<\/p>\n

From the user's perspective: the app says give us your birth date, we will never show it. Then later it says: when is your birthday, and who can see it? That's a really confusing privacy flow for an end user.<\/p>\n

There's also a data-minimization problem. If the purpose of collecting date of birth is age verification, the product may not need to store or expose a full date of birth as a profile attribute. It might need only an age-gate result, or an age range, or a minimum-age confirmation, depending on the legal and safety model. If the purpose is social celebration, it likely does not need the year. Age verification data should be treated as safety or compliance data. Birthday data should be treated as optional profile data. Those should not feel like the same onboarding chore wearing two different fonts.<\/p>\n

A later section in the flow made the data-use problem even clearer. It asks the user for their sun, moon, and rising signs, and then helpfully says: \"Don't know yours? Add your birthday earlier to auto-fill the sun sign.\" That means the birthday isn't just being collected as an isolated social field, it's being used to directly derive more metadata about a user.<\/p>\n

Maybe zodiac signs are silly. Maybe nobody cares. But the pattern matters. The product says one thing at signup, asks again later, then uses birthday data to auto-fill another profile field. This is exactly why purpose limitation matters. Users need to understand what data is being collected, why it is being collected, where it appears, what it derives, and how else it will be used. \"We'll never show this\" is easy to write. The hard part is ensuring the product does not later reuse the same category of data in ways that surprise users.<\/p>\n

Then, the flow kept going.<\/p>\n

It asked for nicknames.<\/p>\n

It asked for middle name.<\/p>\n

It asked where I am from.<\/p>\n

It asked what town I live in now.<\/p>\n

It asked where I went to high school.<\/p>\n

It asked where I went to college.<\/p>\n

It asked what I studied.<\/p>\n

It asked for current job title.<\/p>\n

It asked for dream job.<\/p>\n

It asked what pets I have.<\/p>\n

It asked for my pets' names.<\/p>\n

It asked who is in my family: parents, siblings, kids, anyone close.<\/p>\n

It asked where I fall in line among siblings.<\/p>\n

It asked for food allergies.<\/p>\n

It asked for dietary restrictions.<\/p>\n

It asked for ethnicity or heritage.<\/p>\n

It asked for relationship status.<\/p>\n

It asked for sexuality.<\/p>\n

It asked for pronouns.<\/p>\n

It asked for religion or beliefs.<\/p>\n

It asked for zodiac signs.<\/p>\n

It asked for important dates in my life.<\/p>\n

And near the end, it asked: \"Anything else friends should remember?\"<\/p>\n

I think I got about halfway through before muttering, \"holy shit\" under my breath.<\/p>\n

This isn't really<\/em> a quirky whimsical profile setup. This is asking users to hand over a comprehensive identity dossier in a Lisa Frank<\/a> skin.<\/p>\n

I don't say that lightly. I've followed the OSINT space for around a decade by this point. I know exactly how dangerous this data can be in the wrong hands. The problem isn't that any one of these fields is always catastrophic by itself. The problem is that the flow assembles them together into a single profile.<\/p>\n

A malicious person with access to that data would not merely know \u201cfun trivia\u201d about you. They would have the raw material for impersonation, stalking, phishing, account recovery attacks, social engineering, harassment, doxxing, discrimination, and intimate coercion.<\/p>\n

Middle names, hometowns, schools, pet names, family structure, sibling order, and important dates are classic identity-verification and account-recovery material. They are the cursed security questions of the 2000s rebuilt as a social profile wizard. We all know the ones:<\/p>\n

\u201cWhat was the name of your first pet?\u201d<\/p>\n

\u201cWhat high school did you attend?\u201d<\/p>\n

\u201cWhat city were you born in?\u201d<\/p>\n

\u201cWhat is your oldest sibling\u2019s name?\u201d<\/p>\n

The industry spent years learning that these are terrible secrets because they are often guessable, searchable, memorable, and socially exposed. The industry has spent the better part of a decade trying to teach people that these types of questions are actually terrible security practice. Bridger\u2019s beta appears to ask users to type that same information into a profile flow and then decide who can see each field. That should give anyone with even a brief understanding of cybersecurity chills.<\/p>\n

Sensitive data in a friendship costume<\/h2>\n

Then, there are the extremely sensitive categories. Ethnicity. Religion. Sexuality. Relationship status. Pronouns. Food allergies. Dietary restrictions.<\/p>\n

Some of these may be harmless for some users in some contexts. For other users, they may be sensitive, risky, or genuinely dangerous. Sexuality may not be safely public. Religion may not be safely public. Ethnicity may expose someone to harassment. Pronouns may be a political target in some environments. Dietary restrictions may reveal health, religion, disability, pregnancy, recovery, or eating-disorder context. Relationship status can expose vulnerability, queer relationships, family conflict, breakups, abuse risk, or unwanted attention.<\/p>\n

The correct design posture around data like this, especially for a platform claiming to care about privacy, is not cute curiosity. It is unrelenting restraint. Don't ask users for sensitive data without a clear purpose. Don't expose by default. Don't make users evaluate disclosure field by field while trying to complete onboarding. Don't bury visibility decisions inside a long tap-through flow.<\/p>\n

Don't treat \"skip this one\" as if it solves the consent problem.<\/p>\n

Admittedly, every field is optional. There's no hard requirement to fill in any of these. That doesn't make this okay. Optional is not the same thing as privacy-preserving. A long onboarding flow can pressure users without explicitly forcing them. It can normalize disclosure. It can make skipping feel like incompletion. It can make privacy feel like a chore. It can train users to answer first and think later.<\/p>\n

By screen 17 of 29, or 21 of 29, or 28 of 29, most people are not conducting a careful threat model. They're just trying to finish the onboarding wizard. This is privacy fatigue as interface design.<\/p>\n

\"All Acquaintances\" is not a safety model<\/h2>\n

The visibility model makes it worse. Almost every screen asks: \u201cwho can see this?\u201d with options like Close Friends, Wider Friend Group, and All Acquaintances.<\/p>\n

That may sound like user control, but it's not enough.<\/p>\n

First, \"All Acquaintances\" is not reassuring. Acquaintances are precisely the people who may be dangerous enough to know you and not close enough to trust. Coworkers, old classmates, ex-friends, friends-of-friends, mutuals, people from school, people from events, people you met twice, people who know just enough context to misuse information. That category cannot be meaningfully safe. There's a reason the data on your private Instagram and on your LinkedIn page are very different.<\/p>\n

Second, visibility controls don't answer the data-governance question. Who can see a field in the UI is only one part of privacy. The deeper questions are: is the data stored? Is it indexed? Is it searchable? Is it logged? Is it used for recommendations? Is it used for matching? Is it used for advertising? Is it available to admins? Is it available to moderators? Is it included in exports? Is it deleted when removed? Is it retained in backups? Is it protected differently if sensitive? Is it encrypted? Is it accessible if the service is breached?<\/p>\n

The UI only asks users \"who can see this?\" The real question is who can access it, infer from it, process it, retain it, correlate it, and lose it. Because, that's the catastrophic breach scenario.<\/p>\n

Imagine a breach of this dataset. Not just emails and hashed passwords, although that would be bad enough. Imagine a breach containing full names, birth dates, towns, hometowns, schools, colleges, job titles, family members, sibling order, pets, pet names, food allergies, dietary restrictions, ethnicity, religion, sexuality, relationship status, pronouns, important life dates, and open-ended notes written specifically as things friends should remember.<\/p>\n

That's a map of people\u2019s private lives. It would be useful to scammers. It would be useful to stalkers. It would be useful to abusive partners. It would be useful to harassers. It would be useful to doxxers. It would be useful to identity thieves. It would be useful to anyone trying to impersonate someone, guess account-recovery answers, craft convincing phishing messages, or apply pressure using personal facts.<\/p>\n

This is the reason why privacy people are always super annoying and paranoid-sounding. Because the fun little profile field is never just a fun little profile field once it's in a database somewhere.<\/p>\n

The free-text trap<\/h2>\n

Then there is \"Important dates in your life.\"<\/p>\n

That is a deceptively dangerous prompt. It could collect anniversaries, bereavements, sobriety dates, immigration dates, religious dates, medical dates, trauma dates, breakup dates, family events, court dates, or anything else someone considers important. The prompt is emotionally open-ended. The data could be deeply personal.<\/p>\n

And then the final open-ended field: \"Anything else friends should remember?\"<\/p>\n

I fully understand this is supposed to be Bridger's version of the \"Bio\" field on most social media platforms. An area of free text to write whatever you want on your profile. But consider the framing here, this is explicitly framed as \"stuff your friends should remember\". People will put everything in there.<\/p>\n

Allergies. Trauma. Pronunciation. Neurodivergence. Estranged family. \"Do not mention this around my parents.\" \"I am sober.\" \"I am not out at work.\" \"My dad died in March.\" \"I panic when people yell.\" \"I have a medical condition.\" \"I use a different name around family.\" \"Please do not post photos of me.\" \"I'm a minor.\"<\/p>\n

The app doesn't need to intend harm for this to become extremely sensitive extremely quickly. That's the core issue here. A privacy failure is not always a villain twirling a moustache and selling data to the highest bidder. Sometimes it is a team building a cute product that doesn't fully understand the blast radius of the fields it is asking for.<\/p>\n

The product claims to be about trust, friendship, privacy, and escaping the worst parts of social media. But the onboarding flow asks users to construct a semi-public memory palace of identity, family, location, education, work, health-adjacent information, beliefs, sexuality, relationships, pets, allergies, dietary restrictions, life dates, and anything else their friends should remember. Bridger doesn't just ask \"who are you?\" It asks \"what would someone need to know to identify, locate, infer, remember, or socially engineer you?\"<\/p>\n

\"Privacy will be the top priority\" is not an answer<\/h2>\n

Before I dived into the beta, I took some time to read the comments on the reel I saw. I wanted to get a vibe for what people were saying. Most of the comments were generic hype.<\/p>\n

One in particular however, caught my eye. Someone asked Bridger a straightforward question: \"will it be under GDPR?\" Bridger's reply was simply, \"Privacy will be the top priority!\"<\/p>\n

\"Instagram.<\/p>\n

They answered a very serious question, with a marketing slogan. The question was not \"do you care about privacy?\" The question was whether Bridger would be subject to a specific data-protection regime. That is an important legal, operational, and architectural question. It asks about scope, jurisdiction, users, processing activities, rights, lawful bases, deletion, export, retention, consent, processors, transfers, and safeguards. \"Privacy will be the top priority!\" doesn't answer any of that.<\/p>\n

On its own, this might be forgivable. It was a social-media reply. Maybe the person writing it wasn't prepared to answer a regulatory question in a comment thread. Maybe the correct internal answer is more serious than the public reply. Maybe the team simply had not yet worked through the details. No one should be expecting a beta social media platform to have a compliance lawyer on standby.<\/p>\n

But then, Bridger is asking for birth date, full name, birthday, hometown, current town, high school, college, field of study, job title, family structure, sibling order, pet names, food allergies, dietary restrictions, ethnicity or heritage, relationship status, sexuality, pronouns, religion or beliefs, important life dates, and open-ended personal notes.<\/p>\n

At that point, \"privacy will be the top priority\" stops being a harmlessly vague answer. It becomes a real problem. A product asking for identity-adjacent, health-adjacent, relationship, location, family, religion, ethnicity, sexuality, and open-ended intimate data needs a serious privacy model.<\/p>\n

Not vibes. Not reassurances. Not a marketing slogan with an exclamation mark. A model.<\/p>\n

What data is collected? Why is it collected? What's optional? What's public by default? Who can access it? Is it retained after deletion? Is it exported? Can users request full deletion? What happens if the user is a minor? What happens if the data leaks? What happens if someone enters sensitive information into the final free-text box?<\/p>\n

These are all the natural questions created by the shape of the product. This is why the GDPR reply matters. The right answer didn't have to be a legal memo. It could have been simple and honest: \"We are still assessing our obligations before launch, especially if we offer Bridger to users in Europe. We know this matters, and we will publish a proper privacy framework before collecting sensitive data.\"<\/p>\n

That would have been reassuring. Instead, the public answer amounted to: trust us, privacy matters. But the beta then asks for a long list of deeply personal information. That's playing incredibly fast and loose with privacy. And when a product is collecting this much sensitive information, fast and loose is exactly what people should be afraid of.<\/p>\n

The friend quiz makes it worse<\/h2>\n

And then, there is the \"Friend Quiz\".<\/p>\n

The Friends page features a \"Friend Quiz\" box with the text \"Add friends with profile data to unlock the quiz.\" At first glance, this seems like a fairly harmless dark pattern. Just an easy way to drive users to invite their friends to the platform.<\/p>\n

That line becomes much darker after going through the profile flow. Because what, exactly, is the quiz about? If the quiz only unlocks once you have friends that have filled in an entire intelligence briefing into their personal lives, the obvious implication is that at least some of this profile data becomes quiz material.<\/p>\n

The app asks users to provide deeply identifying and sometimes sensitive information, then appears to use \"profile data\" as the substrate for a friend quiz. It turns deeply personal knowledge into a gamified feature. It makes intimacy measurable. It makes remembering your friends into an app mechanic.<\/p>\n

Again, maybe the actual quiz is harmless. Maybe it only asks cute questions. Maybe it avoids sensitive fields. Maybe the product has guardrails that are not visible in the beta flow. It's entirely possible that the quiz explicitly excludes sensitive fields such as sexuality, religion, ethnicity, allergies, or family details.<\/p>\n

But the UI makes no attempt to communicate that. What it communicates is: add friends with profile data to unlock the quiz. After the profile flow I had just seen, that sentence doesn't read as charming. It fires like seven alarms in the threat model part of my brain.<\/p>\n

This is the danger of collecting everything \"for friendship.\" Once the data exists, the product starts finding uses for it. A birthday becomes a zodiac sign. A preference becomes a prompt. A profile field becomes quiz content. A private detail becomes an interaction surface. This is how platforms eat away at privacy, not all at once immediately. One cute feature at a time.<\/p>\n

The app says what the data is for<\/h2>\n

The somewhat hidden \"View My Data\" page makes this even more alarming.<\/p>\n

\"Bridger<\/p>\n

\"Your answers to profile questions helps us connect you to people who have similar interests. Coming soon.\"<\/p>\n

This should set off immediate alarm bells. The profile answers aren't just decorative flavour. They're not merely notes for your existing friends. The app says, quite clearly, those answers are intended to help connect users to people with similar interests.<\/p>\n

This data becomes matching logic. It becomes discovery logic. It becomes recommendation logic. Whatever word you prefer, it means the profile data is product fuel. It is, at minimum, designed to feed matching or discovery logic.<\/p>\n

The same page says hobby tags will \"let you find people who share specific interests.\" It also has a section for \"Closeness Tier Assignments,\" which appear to control whose content users can see.<\/p>\n

There's a clear product shape emerging here. Bridger asks users for structured personal information. Some of that information is identity-adjacent. Some is sensitive. Some is useful for social engineering. Some is health-adjacent. Some is relationship, family, location, school, belief, or sexuality-related. Then the product tells users that their answers will help connect them to people with similar interests.<\/p>\n

Maybe the current beta does not yet implement the full matching system. The page itself says all of this is coming soon. That doesn't make the concern weaker. It makes the roadmap visible. Bridger isn't just collecting personal data because friends might enjoy reading it. It is planning to use that data to connect, sort, and discover people.<\/p>\n

This is exactly why data minimization matters. Once the data exists, the product starts finding uses for it. It has to, the incentives are too great to avoid it. A birthday becomes a zodiac field. A profile answer becomes quiz material. A hobby becomes a discovery tag. A personal detail becomes a matching signal.<\/p>\n

And a \"close-friends app\" quietly becomes a system for structuring, searching, and acting on intimate social data.<\/p>\n

This should have been stopped<\/h2>\n

A team with a mature privacy and safety posture might look at this flow and stop it before it reached a semi-public beta. A privacy review would ask why these fields exist. A security review would ask what happens if they leak. A trust and safety review would ask how they can be abused. A data-protection review would ask whether the collection is necessary, proportionate, purpose-limited, optional in a meaningful way, default-private, and explainable. A product review would ask whether friendship actually requires any of this. A regulatory compliance review would ask what data-privacy regulations apply.<\/p>\n

Apparently, that didn't happen. Or, if it did, the flow survived anyway. This is what happens when no one with sufficient authority is saying no.<\/p>\n

No, you do not need the user's middle name.<\/p>\n

No, you do not need their pets' names.<\/p>\n

No, you do not need their sibling order.<\/p>\n

No, you do not need their high school.<\/p>\n

No, you do not need their current town public.<\/p>\n

No, you do not need their ethnicity in a friend app.<\/p>\n

No, you do not need their sexuality in onboarding.<\/p>\n

No, you do not need their religion or beliefs.<\/p>\n

No, you do not need important life dates.<\/p>\n

No, you do not need a free-text field where users can deposit trauma in a cute box.<\/p>\n

At least, you do not need any of that by default. And if you believe you do need it, the burden is on you to justify it with extraordinary clarity, restraint, and protection.<\/p>\n

Bridger does not appear to be doing that in any visible or convincing way. Instead, the beta gives users a familiar platform move: provide personal data now, sort out visibility later.<\/p>\n

The broader lesson<\/h2>\n

I don't think every cute profile question is evil. I don't think a platform to connect with friends has to be sterile. I don't think every early beta should have the complete privacy authority of a bank.<\/p>\n

But I do think a close-friends app needs to understand deeply what kind of data it is asking for. Friendship is intimate. That's the point. A product that mediates friendship is not collecting random preferences in a vacuum. It is collecting context about relationships, identity, memory, location, history, family, habits, beliefs, vulnerability, and trust.<\/p>\n

That data has a blast radius. A social app for friends should ask for less, not more. It should default to completely private, not public. It should separate display identity from legal identity. It should never ask for sensitive categories unless there is an extraordinary reason. It shouldn't make users decide visibility for dozens of fields while trying to complete onboarding. It should not collect a birth date under the promise to never share it and then ask for birthday visibility later. It should not use personal data as feature fuel without making the boundaries painfully clear.<\/p>\n

It should never<\/em> turn intimacy into a structured dataset and then call that connection.<\/p>\n

The most dangerous data is often not the data that looks dangerous. It is the cute stuff. The memorable stuff. The \"your friends already know this anyway\" stuff. The hometown, the school, the sibling order, the birthday, the important date, the dietary restriction, the relationship status, the thing friends should remember.<\/p>\n

That's precisely why people will happily volunteer it. That's precisely why it's useful. And that's precisely why a privacy-conscious product should be careful with it.<\/p>\n

Bridger says it wants to build a better social app for friends.<\/p>\n

Good. Godspeed.<\/p>\n

Just please don't ask your users to build an OSINT dossier in a cute font.<\/p>\n

Update: the beta now has a separate security-governance issue<\/h2>\n

After this piece was written, Bridger\u2019s Discord was placed in read-only mode following an announcement that there had allegedly been conversations about trying to find and exploit the beta code to make the project appear unsafe.<\/p>\n

I want to be clear about my own role here.<\/p>\n

My concerns are based on normal use of the beta, the user-facing onboarding and profile flow, and the app\u2019s own UI around profile data, quizzes, and future matching or discovery. I did not attempt to exploit the beta, bypass access controls, probe the application, interfere with the project, or make Bridger appear unsafe. I also do not support anyone doing so.<\/p>\n

If anything, this reinforces the point.<\/p>\n

A product that collects sensitive personal information has to assume adversarial conditions. It has to assume some users will behave badly, some contributors may need limits, some people will poke at systems they should not touch, and some data will attract exactly the wrong kind of attention.<\/p>\n

That is why data minimization matters.<\/p>\n

The safest sensitive data is the data you never collect.<\/p>\n"},{"title":"Immediate WWDC Thoughts","pubDate":"Mon, 08 Jun 2026 00:00:00 +0000","author":"Ethan Plant","link":"https:\/\/ethanplant.ca\/notes\/wwdc-2026\/","guid":"https:\/\/ethanplant.ca\/notes\/wwdc-2026\/","description":"

My immediate reaction to Apple WWDC is that Apple may be the only major tech company that has not fully lost its mind around AI.<\/p>\n

This is not the same as saying Apple is good, right, or pure, or immune from doing Apple nonsense. It is still Apple. It still names operating systems things like \"Golden Gate\". It still unveils a design language called \"Liquid Glass\", and then, one year later, quietly improves it by making it less annoying. It still frames ecosystem lock-in in nice corporate language like, \"making a more streamlined user experience\". But, compared to the rest of the tech industry, Apple seems almost alarmingly sane.<\/p>\n

The first sign was that WWDC went more than two minutes before mentioning AI. In 2026, that feels like an act of monastic resistance. Nearly every tech conference these days open with a CEO walking on stage, staring into the middle distance, and explaining that the company has been spiritually transformed by agents like the Second Coming has happened. Apple, by some miracle, started with operating systems.<\/p>\n

There was a line early on that I genuinely liked: \"the best operating systems aren't just built on big breakthroughs, they're built on sweating the details\". That is an absolute banger quote, mostly because it's true.<\/p>\n

The best parts of WWDC weren't the grand AI announcements. They were the boring quality of life improvements that make computers feel less stupid. Performance improvements. Better CPU scheduling on older iPhones. Faster photo availability after taking a picture. Improved search indexing. iOS 27 still supporting the now ancient iPhone 11, which is absolutely wild. Android could never. And what I found notable is this was their opening move. It wasn't a footnote after an hour of AI features no one asked for. It was immediate. \"This is how we're making our OS better\".<\/p>\n

This is the kind of thing Apple is genuinely good at when it remembers what company it is. Computers aren't just transformed by big conceptual shifts. They're improved by fixing the small frictions. The half-second delay. The missing search result. The thing that should've synced but didn't. The feature that technically exists but feels too annoying to use.<\/p>\n

I am also the kind of person who gets unreasonably happy about an improved search index, so this part of the keynote definitely worked on me.<\/p>\n

Liquid Glass is still hilarious though. Apple spent a year telling us this was the future of interface design, and now one of the big improvements is that users can nearly disable it entirely. Good. Correct. Necessary. But extremely funny. Apple's eternal curse is to decide that its taste is law, then eventually discover that people sometimes want to read the thing on their screen.<\/p>\n

This is where Apple is both better than the industry and still deeply Apple.<\/p>\n

For all its faults, Apple seems to be one of the only major technology companies that still understands that computers should belong to the people using them. Admittedly, that sounds absurd, given that Apple is also one of the most locked-down companies in consumer technology. This is the company of App Review, sealed hardware, blessed APIs, ecosystem lock-in, and design decisions handed down like papal encyclicals. Apple's version of ownership has always been conditional. You own the device, but not entirely. You can use the computer, but only along the paths Apple has decided are safe, elegant, profitable, or acceptable.<\/p>\n

And yet. Apple still seems to understand something most of the industry has forgotten. Your computer should still feel<\/em> like yours. It should be quiet. It should be coherent. It should protect you. It should not constantly beg for your attention. It should not turn every interaction into a growth funnel, ad impression, chatbot session, or a data extraction event. A computer should feel like a tool in your hand, not a terminal attached to someone else's business model<\/a>.<\/p>\n

This is Apple's great contradiction. Apple understands, on paper at least, that computers belong to their users. It just can't quite bring itself to let that mean what it obviously means. Apple's computers belong to you in the way a very nice hotel \"belongs to you\". It's private, it's beautifully maintained, someone has thought carefully about the lighting. But you can't just decide to knock down a wall.<\/p>\n

It's absolutely maddening. It is also, in the current tech landscape, almost... humane?<\/p>\n

The AI section was where this became much more obvious. The industry has spent the last few years acting like AI isn't a neat feature, or a tool, or a new interface layer, but this weird corporate religious movement<\/a>. Every product needs an agent. Every app needs a chatbot. Every company needs to say \"In today's fast evolving landscape, AI is helping us reimagine...\" until everyone in the room falls asleep.<\/p>\n

Apple seems to have looked at all of this and politely asked: what in the fuck are you people doing?<\/p>\n

That was the main feeling I had watching the keynote. Apple is not rejecting AI. It's clearly going in very hard on AI. But the framing around Apple Intelligence feels very different. It's not \"what if every product became a chatbot?\" It's \"what if the computer was better at helping you use the computer?\" That should have been the starting point for everyone.<\/p>\n

On-device speech synthesis, natural language processing, and image processing. The new Core AI<\/a> API making it easier for apps to bring in their own local models. Apple repeatedly saying \"Private Cloud Compute\" like it was legally required to mention it every five minutes. A personal device is exactly where this stuff should live. The useful version of AI isn't a slop generating machine stapled carelessly onto every text field. It's context, it's search, it's glue. It's your computer knowing enough about what you're doing to help without making you hand over your life over to some random cloud service that pinky promises it respects your privacy.<\/p>\n

The \"second brain\" people are going to be insufferable about this, but they may also be right. On-device intelligence combined with mass local indexing is essentially the Obsidian + Claude Code fantasy on steroids. Your phone knowing your photos, messages, calendar, files, screenshots, and emails well enough to help you find and act on things is genuinely useful. It's also extremely intimate, which is why the privacy architecture matters.<\/p>\n

Apple's advantage here isn't that Apple is some morally pure actor. It's that Apple's incentives are very different than most of the companies currently speedrunning AI integration. A company that makes its money selling expensive computers and phones is not the same as a company that makes money turning human behaviour into advertising profiles. That doesn't make Apple virtuous by any means, it makes Apple structurally less insane.<\/p>\n

There were still moments that made me nervous. \"Age-based protection\" is one of those phrases that immediately makes me sit up. The declared age range API feels like the kind of thing that could be fine in Apple's hands, but become deeply cursed once governments and platforms start getting ideas. The trust and safety section was, somehow, mostly fine, but I reserve the right to become unreasonably angry about it later.<\/p>\n

The expanded on-device scanning for gore and violent content also seems basically good, at least in the version Apple presented. On-client scanning is not automatically bad. In fact, some of it is exactly where safety features should happen. The problem is always scope, coercion, and whether \u201cprotect the user\u201d quietly turns into \u201cinspect the user.\u201d<\/p>\n

So, fine. For now. But privacy features are always on thin ice.<\/p>\n

Siri remains the most embarrassing part of this. The new Siri looks genuinely useful. It also would have been a banger in 2012. Apple announcing that Siri can finally understand context and do things across apps feels less like a revolutionary breakthrough than a company finally arriving at the future it promised 14 years ago.<\/p>\n

Even Apple seemed to know this was a bit awkward. There was very much a \"new and improved Siri for real this time, we swear\" energy. Like the 6th... 7th? redesign of Siri. New voice. New app. Conversation history. Cross-device awareness. Spotlight integration. On-screen context. Camera mode that's basically Google Lens. It's probably all useful, it's also embarrassing that this is all \"new\".<\/p>\n

Still, the integration looks right. Right-clicking to invoke Siri with context is exactly the kind of AI integration I want. There where I need it. Out of the way where I don't. Not screaming at me from every corner of the interface. Not turning my computer into a haunted LinkedIn bot. Just available as a tool when I need it.<\/p>\n

That's the thing Apple seems to understand better than almost anyone else right now. AI should be ambient, contextual, and mostly invisible until needed. It should make existing workflows easier. It shouldn't demand that every task become a conversation.<\/p>\n

Some of the smaller AI features are also just obviously good. Natural language shortcuts might make Shortcuts usable for normal people. Call context sounds genuinely helpful. Automatic proofreading is nice. Automatic updating of compromised passwords is extremely smart. AI photo editing is neat, even if it is also spiritually cursed. The bill splitting demo was admittedly cool.<\/p>\n

Then, there is the usual Apple weirdness.<\/p>\n

Siri AI is a stupid name. Safari still will not just give me vertical tabs. Website notifications remain funny given Apple\u2019s long war against PWAs. Apple subtly calling out Chrome was deserved and petty. Apple partnering with Gemini feels like a glitch in the timeline. Siri AI not launching in the EU or China is both predictable and very funny.<\/p>\n

And then, there was Tim Cook.<\/p>\n

I know, intellectually, that CEOs are not supposed to matter this much. Apple is a giant institution. Tim Cook is not Apple. There will be another Apple CEO someday, possibly soon. The company will continue. But still. \u201cGood morning\u201d hits differently when you know it's the last one. Cook\u2019s Apple has never had the mythic energy of Steve Jobs\u2019 Apple. It was never going to. But Cook\u2019s Apple became something else: operationally terrifying, socially cautious, sometimes boring, occasionally brave, usually tasteful, frequently controlling, and somehow still one of the only large tech companies that remembers computers are supposed to be useful.<\/p>\n

That was, overall, my main takeaway from WWDC. Apple didn't avoid AI. It didn't ignore the moment. It did not pretend this technology does not matter. It just chose to treat AI cautiously.<\/p>\n

It just treated AI like software.<\/p>\n

It treated the computer as a thing that should help the person using it.<\/p>\n

Apparently that's a radical position now.<\/p>\n"},{"title":"Your Dropdown Has Offended British Columbia","pubDate":"Wed, 03 Jun 2026 00:00:00 +0000","author":"Ethan Plant","link":"https:\/\/ethanplant.ca\/notes\/pacific-time\/","guid":"https:\/\/ethanplant.ca\/notes\/pacific-time\/","description":"

I was trying to add my website to the Internet Phone Book<\/a>, as one does, when I encountered the following option in the registration form:<\/p>\n

(UTC-08:00) Pacific Time (US and Canada)<\/p>\n

Absolutely the fuck not.<\/p>\n

I live in Vancouver. Vancouver is not on UTC-8 anymore. Vancouver is also not in Mountain Time.<\/p>\n

This leaves me in the very stupid position of having two wrong choices. I can choose the right region with the wrong offset, or the right offset with the wrong region. This is the sort of thing that happens when a timezone selector mistakes civil time for a number.<\/p>\n

Timezones are not offsets. They are legal, political, historical, and occasionally deranged regional agreements about what the clock should say. They change because governments change them. They contain exceptions. They offend software engineers because they refuse to behave like clean abstractions.<\/p>\n

This is why America\/Vancouver exists.<\/p>\n

\u201cPacific Time (US and Canada)\u201d used to be an acceptable simplification. It is not anymore. Pacific Time in the United States and Pacific Time in British Columbia have diverged. The label has become a fossil from an older timezone regime.<\/p>\n

Naturally, I will be filing an immediate bug report in defence of civil timekeeping and the dignity of Pacific Canada.<\/p>\n

The Small Web is beautiful because it is made of human beings. Unfortunately for everyone involved, some of those human beings notice timezone dropdowns.<\/p>\n"},{"title":"Canada Keeps Sabotaging Its Own Digital Sovereignty","pubDate":"Wed, 03 Jun 2026 00:00:00 +0000","author":"Ethan Plant","link":"https:\/\/ethanplant.ca\/writing\/canada-digital-sovereignty\/","guid":"https:\/\/ethanplant.ca\/writing\/canada-digital-sovereignty\/","description":"

Canada should know better.<\/p>\n

That's the part that makes the past few weeks of digital policy discourse so frustrating. This is not a country without technical memory. Canada has been home to serious telecommunications engineering, security software, cryptography, mobile infrastructure, privacy law, artificial intelligence research, and some of the best computer science institutions in the world. The knowledge is here. The people are here. The institutions are here.<\/p>\n

What's missing is the willingness to listen to them.<\/p>\n

Kitchener-Waterloo alone should make Canada impossible to dismiss as a country that doesn't understand software. The University of Waterloo is one of the strongest computer science schools on the planet. In the 2026 QS subject rankings<\/a>, the University of Waterloo placed 27th in the world for computer science (a position it shares with the University of British Columbia). Waterloo's coop program is the world's leader, with more than 8000 employers in more than 70 countries<\/a>. Waterloo doesn't just produce papers, it's producing people who go directly into the systems, platforms, infrastructure, and companies that shape the digital world.<\/p>\n

Research In Motion is personal for me in a way that is hard to separate from Kitchener-Waterloo itself. I grew up in Kitchener. I remember driving through Waterloo and being surrounded by RIM buildings. Many of my classmates in school had parents who worked there. In a very real sense, I grew up in the shadow of Canadian tech.<\/p>\n

My own father briefly worked at RIM and once met CEO Jim Balsillie. Years later, in a Globe and Mail article<\/a> about Waterloo during RIM\u2019s decline, he described the company\u2019s troubles plainly: \u201cIt\u2019s sad. They have contributed a lot to this community.\u201d<\/p>\n

That's the part that is easy to miss from outside the region. RIM was not only a phone company. It was part of the local geography. It shaped jobs, buildings, philanthropy, housing, and the ordinary civic atmosphere of Kitchener-Waterloo. BlackBerry\u2019s secure communications legacy matters technically, but RIM\u2019s presence in Waterloo also matters because it showed what Canadian digital capacity looked like when it was rooted in a place.<\/p>\n

And while Waterloo may be the top, it is far from alone. The University of Toronto, UBC, McGill, Universit\u00e9 de Montr\u00e9al, Alberta, Ottawa, Carleton, and others form a serious national base of computer science and engineering talent. Times Higher Education\u2019s 2026 Canadian computer science rankings<\/a> place Toronto 22nd globally, Waterloo 41st, Universit\u00e9 de Montr\u00e9al 52nd, UBC 57th, and McGill 74th.<\/p>\n

The same holds true geographically. Canada has a handful of places that should, in theory, make the country punch well above its weight in digital policy. Waterloo has the talent pipeline. Toronto and Montr\u00e9al have deep AI, privacy, finance, platform, and research ecosystems. Vancouver has cloud infrastructure, gaming, and cross-border west coast technical talent. Waterloo, UBC, McGill, and the University of Toronto give Canada globally recognized academic depth. This is not a country short on people who can explain how digital systems behave when the law touches them.<\/p>\n

And maybe this is just the University of Ottawa grad in me, but Ottawa is arguably one of the more interesting places on this map.<\/p>\n

It sits at the intersection of technical memory and public power. The federal government is there. Parliament is there. The regulators are there. The institutions are there. The policy schools, legal community, national-security apparatus, telecommunications history, and procurement machinery are there. And just outside Ottawa sits Kanata North, one of the clearest reminders that Canada once had an enormous telecommunications-industrial base.<\/p>\n

Canada's largest technology park didn't just appear out of nowhere. Its lineage runs through Computing Devices Canada, Bell Northern Research, Nortel, Mitel, and Corel. Even when Nortel collapsed, the expertise didn't just vanish. Many of its people remained in the area. They joined other companies, became entrepreneurs, and helped Ottawa earn the title of \"Silicon Valley North\".<\/p>\n

Ottawa is not just a national capital that happens to have some tech nearby. It is a capital beside a deep reservoir of telecommunications and infrastructure expertise. It has the people who write policy close to the people who understand networks. It has lawyers, regulators, engineers, security specialists, civil servants, researchers, and industry veterans in the same region. In theory, that should make Canada unusually capable of building world-class digital policy.<\/p>\n

The tragedy, as it unfortunately often is, is that Canada has almost all of the ingredients. It has the schools. It has the talent. It has the security history. It has the telecom memory. It has the policy institutions. It has the legal expertise. It has the companies. It has the civil society groups. It has enough people who understand exactly how these systems fail. And yet, file after file, Canada chooses to ignore them.<\/p>\n

Sovereignty is not control<\/h2>\n

The desire for digital sovereignty isn't the problem. Arguably, it makes more sense now than it did even just a few years ago.<\/p>\n

Canada's dependence on American digital infrastructure has always been politically awkward. But the recent tensions between Canada and the United States have made it harder to treat that dependence as harmless convenience. If most of Canada's cloud services, office software, social networks, search engines, mobile operating systems, app stores, advertising systems, content distribution networks, and AI infrastructure are controlled by American companies, then Canadian digital dependence is also geopolitical dependence. An article by Policy Options<\/a> put it bluntly:<\/p>\n

\n

Much of Canadian digital communications infrastructure is under the control of U.S. companies and thus potentially the U.S. government. In the Trump 2.0 era, this raises critical economic, political and national security concerns.<\/p>\n<\/blockquote>\n

So, the instinct behind a push for digital sovereignty is not wrong. It's entirely reasonable for Canada to want more domestic capacity, more control over its critical infrastructure, more resilience against foreign pressure, and less dependence on companies and legal systems outside Canadian control. A middle power living beside an increasingly aggressive superpower would be foolish not to think about this.<\/p>\n

\n

\"Middle powers must act together because if you are not at the table, you are on the menu.\"\n- Prime Minister Mark Carney, World Economic Forum Annual Meeting, Davos, January 20, 2026<\/p>\n<\/blockquote>\n

The mistake is what Ottawa seems to think sovereignty means. Canada keeps acting as if sovereignty is the ability to assert jurisdiction. If it can compel a provider, it calls that sovereignty. If it can tax a platform, mandate a contribution, order retention, block a site, regulate a service, or require an identity check, it calls that sovereignty.<\/p>\n

But control is not the same thing as sovereignty. Control is the ability to issue a demand. Sovereignty is the ability to make that demand survive contact with reality.<\/p>\n

That distinction matters because digital systems do not become trustworthy just because a law tells them to behave. Infrastructure has architecture. Cryptography has constraints. Platforms have incentives. Companies have exit options. Trade partners have retaliation tools. Users have trust thresholds. Domestic firms have limited capital. Small providers have compliance limits. Every digital policy touches a system that can respond in ways the law did not intend.<\/p>\n

The federal government already knows the right words. Canada's Digital Charter<\/a> says that Canadians must be able to trust that their personal information is protected, that their data won't be misused, and that organizations clearly communicate with users. It then states:<\/p>\n

\n

This trust is the foundation on which our digital and data-driven economy will be built.<\/p>\n<\/blockquote>\n

Ottawa wrote this sentence, and then immediately forgot it.<\/p>\n

Canada\u2019s National Cyber Security Strategy<\/a> similarly frames cybersecurity as central to Canada\u2019s digital future, saying the strategy is meant to help secure that future in partnership with provinces, territories, Indigenous communities, industry, and academia.<\/p>\n

\n

Today, it is abundantly clear that to safely advance Canada's digital and clean economy, to protect our democracy and our day-to-day livelihoods, and to ensure our future economic prosperity, cyber security must be a fundamental building block of our country's national security, economic security, and public safety.<\/p>\n<\/blockquote>\n

The government\u2019s AI strategy consultation<\/a> also identified sovereignty, sustainability, public benefit, safe AI systems, and public trust as key themes. None of these are bad aspirations. They're exactly the right aspirations for a country in Canada's position. But, if trust is the foundation, then digital sovereignty cannot be built through policies that make trust harder to maintain.<\/p>\n

A country cannot build digital sovereignty by making secure systems legally uncertain. It cannot build digital sovereignty by treating data minimization as an obstacle to law enforcement. It cannot build digital sovereignty by forcing sensitive online activity through identity-checking infrastructure. It cannot build digital sovereignty by creating trade liabilities and then backing down once another country notices. It cannot build digital sovereignty by publishing AI ambitions while leaving privacy law, procurement, compute, security, competition, and public-sector adoption in a half-built state.<\/p>\n

Real digital sovereignty requires resilient infrastructure. Not just data centres with Canadian addresses, but systems that can withstand outages, attacks, dependency shocks, supply-chain pressure, foreign legal demands, and policy instability. The Government of Canada\u2019s own public-cloud white paper<\/a> acknowledges that cloud adoption raises data sovereignty, residency, and security risks, even as federal IT policy has been shaped around a cloud-first approach.<\/p>\n

It requires trusted law. People and companies need to know that the legal environment protects secure design, privacy, due process, and basic constitutional limits. If the law is vague, secretive, or technically careless, it becomes part of the threat model.<\/p>\n

It requires technical credibility. Governments don't need to become engineering teams, but they do need to understand enough to know when a proposed legal power conflicts with how secure systems actually work. A statute can authorize a result. It cannot repeal the engineering consequences of achieving that result.<\/p>\n

It requires trade awareness. Canada is not the United States. It cannot assume that every platform, vendor, trading partner, or multinational company will simply absorb a Canadian rule because Ottawa has announced it. A middle power has to know where it has leverage and where it's creating exposure.<\/p>\n

It requires geopolitical realism. Canada has to assume that foreign governments, especially the United States, may use trade, market access, legal demands, and industrial pressure to protect their own firms and strategic interests. Digital sovereignty cannot be built on the fantasy that Canada can simply announce a policy and the most powerful country on Earth will politely absorb the consequences.<\/p>\n

It requires user trust. Digital sovereignty is meaningless if Canadians do not trust Canadian systems. A domestic platform that people believe is less private, less secure, or more exposed to state access is not sovereign in any meaningful sense. It is merely local.<\/p>\n

And it requires credible domestic capacity. Sovereignty cannot just mean forcing foreign companies to comply. It has to mean building enough Canadian capability that there are real alternatives: cloud capacity, AI compute, cybersecurity talent, public-sector technical competence, privacy-preserving infrastructure, procurement discipline, and firms that can scale without being crushed by the very compliance burdens the government creates.<\/p>\n

Bill C-22: mistaking access for capability<\/h2>\n

I've already written a fair bit about Bill C-22<\/a>, because frankly, I'm angry about it. The point here though is narrower: Bill C-22 is one example of a larger Canadian digital-policy failure. It shows Ottawa mistaking legal authority for safe technical capability.<\/p>\n

The government\u2019s stated goal is not necessarily absurd. Police and intelligence agencies do need lawful tools to investigate serious crime and threats to national security. Digital systems have changed how evidence is stored, transmitted, deleted, encrypted, and hidden. A country cannot simply pretend that the investigative environment of the 1990s still exists.<\/p>\n

The question around C-22 isn't \"should lawful access exist?\" It already does. The question is whether the state can demand access in ways that risk the security of the systems being accessed. That's where Bill C-22 becomes genuinely dangerous.<\/p>\n

A warrant can authorize access to information. It cannot make the information exist. A production order can compel disclosure of data a provider has. It cannot safely conjure data the provider deliberately does not collect. A law can say police are entitled to evidence. It cannot repeal the security consequences of forcing systems to preserve access paths.<\/p>\n

A government can authorize access, but it cannot legislate away the security consequences of building access paths. That's the line Bill C-22 keeps blurring. The bill states providers aren't required to introduce a \"systemic vulnerability\", but then in the same breath allows technical capability requirements, access-enabling equipment, metadata retention, and secret ministerial orders.<\/p>\n

That's why Apple, Meta, Google, Signal, VPN providers, privacy lawyers, and civil liberties groups are alarmed. They aren't simply asking whether lawful access should exist. They are asking what systems will have to become in order to comply.<\/p>\n

Google\u2019s brief to SECU<\/a> made the institutional problem especially clear. Existing Canadian law already allows law enforcement to seek court orders requiring reasonable assistance with warrants. Bill C-22 would move far more power into executive hands, including secret orders requiring providers to create or maintain technical capacity for access.<\/p>\n

\n