Loupe is an iOS and iPa­dOS app that gives you a hands-on tour of the de­vice fin­ger­print­ing sur­face. It reads real val­ues from pub­lic iOS APIs, the same ones any third-party app can call, and shows them to you raw. The point is sim­ple: see what your iPhone qui­etly ex­poses, and why each read­ing helps an app rec­og­nize you again.

Trackers don’t need your name, email, or lo­ca­tion to rec­og­nize you on­line. Each read­ing is­n’t nec­es­sar­ily unique on its own, but to­gether they form a fin­ger­print that fol­lows you across apps and web­sites.

How sig­nals are or­ga­nized

Loupe groups every read­ing into three tiers, re­flect­ing the cost of ac­cess:

Passive — vis­i­ble to any app with no prompt at all (locale, time zone, screen, bat­tery, and more).

Needs Permission — read­ings that trig­ger an iOS prompt (contacts, pho­tos, lo­ca­tion, cal­en­dars).

Advanced — clever side-chan­nel uses of pub­lic APIs, such as URL-scheme prob­ing via canOpenURL and Keychain per­sis­tence across re­in­stalls.

Privacy

Nothing Loupe reads leaves your de­vice un­less you ex­plic­itly ex­port it. Values are shown raw, with­out ag­gre­ga­tion or hash­ing. Nothing is up­loaded, synced, or shared.

A note on how this was built

Loupe was writ­ten al­most en­tirely by AI cod­ing tools.

Building

You’ll need Xcode 26 or newer.

Open code/​Loupe.xcode­proj.

Copy code/​Con­fig/​Sign­ing.lo­cal.xc­config.ex­am­ple to code/​Con­fig/​Sign­ing.lo­cal.xc­config and fill in your own DEVELOPMENT_TEAM and bun­dle iden­ti­fiers. This file is git­ig­nored and never pub­lished.

Build and run on a de­vice or sim­u­la­tor.

The pro­ject uses Xcode’s build­able fold­ers (folder ref­er­ences), so new Swift files are picked up au­to­mat­i­cally with no need to edit the pro­ject file.

ma­cOS

Loupe also builds for ma­cOS. The Mac ver­sion is mostly com­plete, but a few things still need work be­fore it’s pol­ished.

Support the pro­ject

Loupe is free and open source. If it helped you see what apps can qui­etly learn about your de­vice, the best way to sup­port more work like this is to try Psylo, our pri­vacy-first browser for iPhone and iPad. Psylo gives you proxy-backed brows­ing, iso­lated tabs, and anti-fin­ger­print­ing pro­tec­tions.

You can also read why we built Psylo.

License

The source code is re­leased un­der the MIT License.

The Loupe name and logo, the app icon, all other im­ages and icons, and the de­sign source files are © Mysk, all rights re­served, and are not cov­ered by the MIT li­cense.

About

Loupe is made by Mysk.

Website

Blog

X

Mastodon

Last week, a MetaFilter mem­ber posted a link to what ap­peared to be a new web­site for The Dictionary of Obscure Sorrows, John Koenig’s decade-long pro­ject to make a “dictionary of made-up words for emo­tions that we all feel but don’t have the words to ex­press.”

The pol­ished site in­cludes every­thing you’d ex­pect from a pub­lish­er’s pro­mo­tional book site: an au­thor bi­og­ra­phy, press men­tions, and links to buy the book on Amazon.

Strangely, it also in­cludes the en­tire text of the book, from its open­ing 800-word fore­word to a com­plete archive of all 311 ne­ol­o­gisms, with their ac­com­pa­ny­ing de­f­i­n­i­tions, et­y­mol­ogy, and short es­says, all penned by Koenig.

The book’s orig­i­nal photo-col­lage il­lus­tra­tions made by Koenig and sev­eral other artists are con­spic­u­ously miss­ing. Instead, each word has an AI-generated im­age made with DALL-E 2, rid­dled with the er­rors and ar­ti­facts typ­i­cal of that model.

A ban­ner at the top of the home­page en­cour­ages vis­i­tors to “Generate your own words us­ing AI — give your sor­rows a voice!” The Submit A Sorrow fea­ture lets you de­scribe a feel­ing, and then uses OpenAI’s GPT-4 to gen­er­ate the new word, et­y­mol­ogy, and de­f­i­n­i­tion, which go into a gallery of “User-Generated Sorrows” with AI gen­er­ated art.

MetaFilter mem­bers were im­me­di­ately sus­pi­cious, and so was I. My wife Ami and I made a card game in 2022, Lost for Words, partly in­spired by Koenig’s pro­ject. We own a copy of the book, and I’d fol­lowed it on­line for years. The em­brace of AI seemed out of char­ac­ter.

Then I no­ticed the new site was a dif­fer­ent do­main than the orig­i­nal Tumblr home­page en­tirely:

The orig­i­nal: dic­tio­nary­ofob­scure­sor­rows.comThe re­boot: the­dic­tionary­ofob­scure­sor­rows.com

What’s go­ing on here?

A Little History

John Koenig launched The Dictionary of Obscure Sorrows on Tumblr in 2009, ex­pand­ing it to a se­ries of pop­u­lar video es­says in 2013.

If you know any word from the pro­ject, it’s prob­a­bly “sonder,” which spread far be­yond its ori­gin, mak­ing its way into com­mon par­lance and even­tu­ally to Dictionary.com and Merriam-Webster.

son­der n. the re­al­iza­tion that each ran­dom passerby is liv­ing a life as vivid and com­plex as your own—pop­u­lated with their own am­bi­tions, friends, rou­tines, wor­ries and in­her­ited crazi­ness—an epic story that con­tin­ues in­vis­i­bly around you like an anthill sprawl­ing deep un­der­ground, with elab­o­rate pas­sage­ways to thou­sands of other lives that you’ll never know ex­isted, in which you might ap­pear only once, as an ex­tra sip­ping cof­fee in the back­ground, as a blur of traf­fic pass­ing on the high­way, as a lighted win­dow at dusk.

son­der n. the re­al­iza­tion that each ran­dom passerby is liv­ing a life as vivid and com­plex as your own—pop­u­lated with their own am­bi­tions, friends, rou­tines, wor­ries and in­her­ited crazi­ness—an epic story that con­tin­ues in­vis­i­bly around you like an anthill sprawl­ing deep un­der­ground, with elab­o­rate pas­sage­ways to thou­sands of other lives that you’ll never know ex­isted, in which you might ap­pear only once, as an ex­tra sip­ping cof­fee in the back­ground, as a blur of traf­fic pass­ing on the high­way, as a lighted win­dow at dusk.

Other words coined by Koenig have found a life out­side his pro­ject. You may have en­coun­tered “anemoia” (a feel­ing of nos­tal­gia for a time or place you’ve never known), “vellichor” (the strange wist­ful­ness of used book­stores), or maybe “monachopsis” (the sub­tle but per­sis­tent feel­ing of be­ing out of place).

But “sonder” is the break­away suc­cess. I’d wa­ger most peo­ple who have heard the word have no idea it was coined by a guy on Tumblr in 2012.

There’s an R&B band named Sonder, a failed Airbnb ri­val, and count­less busi­nesses rang­ing from con­sul­tan­cies and VC firms to cof­fee­houses and dis­pen­saries. There’s a bar named Sonder two miles from me right now.

That suc­cess landed Koenig a book deal with Simon & Schuster, and the book be­came a New York Times best­seller on its re­lease in November 2021.

Two years later, around August 2023, the new Dictionary of Obscure Sorrows web­site launched, but cu­ri­ously, with no ref­er­ence to it from the of­fi­cial Tumblr page or so­cial me­dia.

A Slick Impostor

The mis­sion of Koenig’s pro­ject, in his own words, is to “shine a light on the fun­da­men­tal strange­ness of be­ing a hu­man be­ing.”

So it felt strange that he would now be en­cour­ag­ing peo­ple to gen­er­ate new words and de­f­i­n­i­tions with LLMs, a con­tentious tech­nol­ogy that has been trained on so much hu­man writ­ing, but can’t know what it’s like to be hu­man.

I reached out to John Koenig di­rectly to ask if he was in­volved with the web­site. He emailed back an hour later:

Yeah man, I had noth­ing to do with it. Don’t know what to think or do about that, as the site is pretty slick. Nicer than my own, re­ally.

Yeah man, I had noth­ing to do with it. Don’t know what to think or do about that, as the site is pretty slick. Nicer than my own, re­ally.

It was­n’t hard to find who was re­spon­si­ble since they list them­selves in the “Site Credits” in the footer of every page: Qontour (formerly Prompt Digital), a web de­sign and mar­ket­ing agency based in San Francisco.

The only hint that the site is­n’t au­tho­rized is this page in their port­fo­lio, where they talk about how “Qontour built the in­ter­ac­tive dig­i­tal plat­form — de­sign­ing the site in Webflow, gen­er­at­ing an AI-powered im­age li­brary, and launch­ing a fea­ture that lets vis­i­tors sub­mit their own sor­rows and add new de­f­i­n­i­tions to the dic­tio­nary.”

On that page, they re­fer to them­selves as “fans” of the book: “The site gives fans (like us) one place to find every­thing — videos, re­views, in­ter­views, and pur­chase links — in­stead of search­ing across a dozen plat­forms.‍”

The prob­lem, of course, is that be­ing a fan does­n’t give them the right to re­pur­pose any of the ma­te­r­ial for their site.

Copyright and Confusion

In the footer of Qontour’s unau­tho­rized site, they added a copy­right no­tice ac­knowl­edg­ing that they don’t own any of the rights to the ma­te­r­ial on the site, while also li­cens­ing all the user-sub­mit­ted words into the pub­lic do­main with a CC Zero li­cense.

Dictionary Content © John Koenig — All rights re­served. User-Generated Content open li­censed — CC Zero.

Dictionary Content © John Koenig — All rights re­served. User-Generated Content open li­censed — CC Zero.

This be­trays a fun­da­men­tal mis­un­der­stand­ing of how copy­right works. Qontour did not have the right to pub­lish the en­tirety of Koenig’s book to show­case their web de­sign skills.

They also sub­mit­ted their site to Webflow’s di­rec­tory to ad­ver­tise their de­sign busi­ness. “This en­deavor show­cased our ex­per­tise in web­site de­sign, AI-generated con­tent, and ex­ten­sive con­tent in­te­gra­tion.”

Below the but­ton to “Hire Qontour,” a small link to “Copyright Info” mis­rep­re­sents their work:

The Dictionary of Obscure Sorrows by Qontour is li­censed un­der a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. All Rights Reserved. In other words, it’s some­one else’s work so you can’t copy it or edit it for any rea­son, but you can share it with oth­ers.

The Dictionary of Obscure Sorrows by Qontour is li­censed un­der a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. All Rights Reserved. In other words, it’s some­one else’s work so you can’t copy it or edit it for any rea­son, but you can share it with oth­ers.

Needless to say, you can’t re­li­cense con­tent you don’t own.

Complicating their claims of it be­ing a fan trib­ute, Qontour also used their own Amazon af­fil­i­ate code through­out the site, cre­ated un­der their pre­vi­ous name Prompt Digital, giv­ing them a cut of all book sales.

Those com­mis­sions may have been mean­ing­ful over the last few years, since the un­of­fi­cial site is now the top search re­sult for vir­tu­ally every query re­lated to the book, in­clud­ing the book’s ti­tle, the words coined in the book, and even John Koenig’s name. In every Google search I’ve tried, the un­of­fi­cial site ranks higher than the of­fi­cial site, the pub­lish­er’s site, or Wikipedia.

This is made worse by the rapid shift from tra­di­tional web search to con­ver­sa­tional AI search, which is easy to ma­nip­u­late, hides sources, and col­lapses con­text into sim­ple an­swers.

ChatGPT and Gemini both link to the boot­leg as the of­fi­cial web­site, and both claim that John Koenig is the one that cre­ated it.

This cre­ates le­git­i­mate con­fu­sion over its au­thor­ship, and ar­guably, dam­ages the rep­u­ta­tion of the pro­ject and book with its en­thu­si­as­tic em­brace of AI. The per­son who orig­i­nally posted the site to MetaFilter thought it was the of­fi­cial site, and the com­menters in the thread then, rea­son­ably, ques­tioned whether the book it­self was writ­ten by AI.

I asked Koenig if his pub­lisher was plan­ning to is­sue a cease-and-de­sist take­down to the site, but did­n’t re­ceive a re­sponse.

After email­ing him, I re­al­ized that Simon & Schuster did make moves last year to limit its reach. They filed two DMCA take­downs (1, 2) with Google last July, ask­ing them to re­move two pages from the boot­leg site from their re­sults. It had no ef­fect.

AI and Consent

It’s one thing for a fan to share or remix copy­righted ma­te­r­ial out of love for the source ma­te­r­ial, with no com­mer­cial mo­tive. (“No copy­right in­tended!”) It’s an­other for a mar­ket­ing agency to take an en­tire liv­ing au­thor’s book, re­place its art with AI slop, add an AI word gen­er­a­tor, mon­e­tize the traf­fic, pro­mote it in their port­fo­lio, and then out­rank the of­fi­cial site every­where.

This is a more fla­grant form of pla­gia­rism than you typ­i­cally see these days, where hu­man-au­thored works are laun­dered with an AI model into some­thing that’s dif­fer­ent enough from its sources to avoid le­gal is­sues.

But it’s not sur­pris­ing to see it com­ing from an agency that has leaned into gen­er­a­tive AI so heav­ily. As they proudly ex­plain, “Every page on this site was writ­ten in Claude” us­ing an “author per­sona” that they call “Q.”

What’s miss­ing here is con­sent, which feels like the orig­i­nal sin of AI. As I’ve writ­ten about many times be­fore, gen­er­a­tive AI mod­els are all trained on a mas­sive cor­pus of hu­man-au­thored works with­out at­tri­bu­tion, con­sent, or com­pen­sa­tion, ex­tract­ing value from cre­ators while cen­tral­iz­ing power among a tiny hand­ful of mas­sive tech com­pa­nies.

On a much smaller scale, Qontour could have reached out to John Koenig for per­mis­sion to re­pub­lish his work, col­lab­o­rat­ing with him on a new, im­proved web­site for the book. He might have asked them to limit it to just the words pub­lished on his Tumblr, asked for them not to build AI fea­tures, or maybe just said no to the whole thing, which would be his right.

The Last Word

What hap­pened to The Dictionary of Obscure Sorrows may have been more brazen, but it is­n’t an iso­lated case.

It’s part of a broad trend hap­pen­ing across the web, where peo­ple are us­ing AI to repack­age, op­ti­mize, and re­place the au­thor­i­ta­tive sources it was trained on for profit.

Nearly every day, I get emailed a newly-launched, ob­vi­ously-vibecoded web­site filled with AI-generated con­tent that was de­signed to siphon at­ten­tion away from hu­man cre­ators: blog­gers, au­thors, jour­nal­ists, artists, mu­si­cians, and any­one else who slowly, painstak­ingly makes things for a liv­ing. I’m not even sure any­more that the emails I’m re­ceiv­ing are sent by a hu­man.

The feel­ing of see­ing some­thing you love in­gested and re­pur­posed by a ma­chine de­signed to re­place the per­son who made it seems like a uniquely mod­ern sor­row.

Maybe there should be a word for it.

You can pur­chase John Koenig’s The Dictionary of Obscure Sorrows at Powell’s Books, di­rectly from his pub­lisher, or your lo­cal in­die book­store. If you have to use Amazon, you can buy it us­ing the au­thor’s own af­fil­i­ate code so he gets the largest cut of the sale.

You may have seen head­lines not­ing that Google’s mea­sure­ments have shown IPv6 reach­ing 50% for the first time. These mea­sure­ments are based on Google’s con­tin­u­ous mon­i­tor­ing of the avail­abil­ity of IPv6 con­nec­tiv­ity among its users, and re­flect the pro­por­tion of users who ac­cess Google ser­vices over IPv6. Reaching the 50% mark is a sig­nif­i­cant mile­stone, demon­strat­ing that IPv6 is a ma­ture, fully ca­pa­ble pro­to­col that is be­ing de­ployed at a global scale and used ef­fec­tively in real-world net­works.

The shape of IPv6 adop­tion is­n’t evenly dis­trib­uted

The global up­take of IPv6 fol­lows a com­plex and var­ied path that is­n’t ap­par­ent in a sin­gle, ag­gre­gated trend line. Google does not pub­lish per‑re­gion IPv6 sta­tis­tics, and its per‑econ­omy data is lim­ited to over­all to­tals, so these nu­ances are hard to see in Google’s fig­ures alone. To un­der­stand how adop­tion re­ally un­folds, it’s more in­struc­tive to look at the APNIC Labs data. Individual economies such as India, Viet Nam, and Saudi Arabia ex­hibit adop­tion curves that dif­fer markedly from the global av­er­age. As the APNIC Labs data shows, this global trend does not nec­es­sar­ily re­flect the ex­pe­ri­ence of in­di­vid­ual economies.

APNIC’s own mea­sure­ment records a 42% world­wide IPv6 ca­pa­bil­ity (Figure 2). That’s a sub­stan­tial dif­fer­ence, which also needs clar­i­fy­ing.

Measurement dif­fer­ences

APNIC’s mea­sure­ment pro­gram is run by APNIC Labs and uses on­line ad­ver­tis­ing dis­trib­uted through Google Ads, which ap­pear in end users’ web browsers, games, and apps wher­ever Google ad­ver­tise­ments are placed. APNIC does not se­lect spe­cific users and seeks the broad­est pos­si­ble ex­po­sure in every econ­omy, 24/7. Normal ad­ver­tis­ing track­ing sys­tems are used with APNIC Labs logic, which en­sures a unique set of tests are run, mea­sur­ing IP, BGP rout­ing and DNS, amongst other tech­nol­ogy choices. No end-user Personally Identifiable Information (PII) data is held, and raw mea­sure­ments are never shared, only col­la­tions at the ISP, econ­omy and re­gion level.

This work is car­ried out with the as­sis­tance of Google Research, ICANN, and oth­ers who help fund and sup­port the ac­tiv­ity. Given this close in­volve­ment, it’s nat­ural to ask why APNIC’s mea­sure­ment re­sults don’t al­ways align with Google’s own pub­lished sta­tis­tics. If Google is used to con­duct the re­search, how can the re­sults dif­fer?

APNIC’s mea­sure­ment ap­proach ap­plies sta­tis­ti­cal weight­ing to the col­lected data and uses ex­ter­nal sources, such as World Bank sta­tis­tics, to model Internet us­age by econ­omy. This is nec­es­sary be­cause the num­ber of mea­sure­ment sam­ples APNIC Labs re­ceives each day is not uni­form. Advertising place­ments are op­ti­mized by Google to max­i­mize de­liv­ery and rev­enue, which means that, on any given day, more ad­ver­tise­ments, and there­fore more mea­sure­ment sam­ples, may be shown in cer­tain economies than oth­ers. For ex­am­ple, if ad­ver­tis­ing de­mand is higher in North African economies such as Egypt or Tunisia on a par­tic­u­lar day, more mea­sure­ments will be col­lected there, while fewer may be gath­ered from South America or Asia.

As a re­sult, the raw sam­ple counts can­not sim­ply be ag­gre­gated to cal­cu­late global IPv6 ca­pa­bil­ity. Instead, APNIC Labs ag­gre­gates the mea­sured IPv6 ca­pa­bil­ity for each econ­omy and then weights it ac­cord­ing to that econ­o­my’s es­ti­mated Internet user pop­u­la­tion.

In prac­tice, this means that large Internet pop­u­la­tions, such as those in India, China, Indonesia, and other ma­jor economies, con­tribute pro­por­tion­ally more to the global re­sult than smaller economies, even if the raw sam­ple vol­umes on a given day might sug­gest oth­er­wise. This weight­ing en­sures that the fi­nal mea­sure­ments re­flect global Internet us­age more ac­cu­rately, rather than daily ad­ver­tis­ing dis­tri­b­u­tion pat­terns.

At the level of in­di­vid­ual economies, APNIC Labs’ mea­sure­ments gen­er­ally align with the to­tals pub­lished by Google and with data from Cloudflare, Akamai, Cisco, and oth­ers. This sug­gests that the un­der­ly­ing mea­sure­ments are com­pa­ra­ble and that the larger dif­fer­ences ob­served at the global level are likely due to dif­fer­ences be­tween APNIC’s weight­ing model. This may be why we see the large vari­ances be­tween the two mea­sure­ments.

In prac­tice, APNIC’s mea­sure­ments tend to be lower than Google’s. As a re­sult, it’s use­ful to view the two data sets to­gether, as they ef­fec­tively bracket the likely range of ac­tual IPv6 ca­pa­bil­ity at any given point in time.

Is IPv6 adop­tion pro­gress­ing as ex­pected?

Some point to the long path to­ward a 50% adop­tion mile­stone as ev­i­dence of a sys­temic fail­ure in IPv6. Nothing could be fur­ther from the truth. Deploying IPv6 has re­quired sub­stan­tial tech­ni­cal ef­fort and sig­nif­i­cant cap­i­tal in­vest­ment. It’s there­fore en­tirely ex­pected that progress has var­ied across re­gions and economies, as in­di­vid­ual ISPs and economies make their own de­ci­sions about how best to bal­ance net­work growth, user ex­pec­ta­tions, and the prac­ti­cal re­al­i­ties of op­er­at­ing Internet in­fra­struc­ture.

The global Internet is not a ‘command econ­omy‘, it evolves through col­lab­o­ra­tion and co­op­er­a­tion within mar­ket-dri­ven con­di­tions. Many providers made sub­stan­tial cap­i­tal in­vest­ments in IPv4 in ear­lier pe­ri­ods and have nat­u­rally sought to max­i­mize the re­turn on those in­vest­ments. In do­ing so, they built sus­tain­able and com­mer­cially vi­able IPv4-based net­works within their ex­ist­ing foot­prints.

By con­trast, for newer mar­ket en­trants, it has of­ten been more ra­tio­nal to adopt IPv6 as the pri­mary pro­to­col, as it can demon­stra­bly re­duce the to­tal cost of own­er­ship. This pat­tern is par­tic­u­larly ev­i­dent in the mo­bile sec­tor, most no­tably in large-scale IPv6 de­ploy­ments such as Reliance Jio’s net­work in India.

Is the global Internet func­tion­ing in a ‘two‑protocol world’?

Yes, but it could be sim­pler.

Certainly, it would be eas­ier lo­gis­ti­cally to run a global in­ter­net un­der a sin­gle pro­to­col. However, that is not the en­vi­ron­ment we have ended up with. Instead, the Internet to­day op­er­ates across a mix of di­rect IPv4 con­nec­tiv­ity, IPv4 me­di­ated through Network Address Translation (NAT), ei­ther in home net­works or at the car­rier level via Carrier‑Grade NAT (CGNAT), and IPv6.

Managing ad­dress trans­la­tion through NAT is not ma­te­ri­ally less com­plex than al­ter­na­tives such as pro­to­col trans­la­tion, IPv4 en­cap­su­la­tion over IPv6, or other tran­si­tion and proxy mech­a­nisms. As a re­sult, claims that ‘IPv4 is work­ing fine’ of­ten over­look the un­der­ly­ing re­al­ity: Modern IPv4 net­works al­ready rely on lay­ers of op­er­a­tional com­plex­ity, and there is no in­her­ently lower‑cost or sim­pler ap­proach avail­able within IPv4 alone.

From the out­set, it was un­der­stood that the lack of di­rect in­ter­op­er­abil­ity be­tween IPv4 and IPv6 would be a chal­lenge that needed to be ad­dressed. Early ef­forts ex­plored the idea of pro­to­cols that could sub­sume IPv4 un­changed and en­able di­rect con­nec­tiv­ity across both worlds, but these ap­proaches did not prove vi­able.

Instead, in­ter­op­er­abil­ity has emerged at higher lay­ers, with trans­port pro­to­cols such as TCP, UDP, and QUIC op­er­at­ing in­de­pen­dently of the un­der­ly­ing IP ver­sion. This model nec­es­sar­ily re­lies on some form of in­ter­me­di­ary. This is vis­i­ble in the way large con­tent and caching providers, such as Cloudflare, are able to of­fer dual‑stack ser­vices re­gard­less of whether the back­end sys­tems them­selves sup­port both pro­to­cols.

The ab­sence of na­tive dual‑stack ca­pa­bil­ity at some ser­vices, for ex­am­ple, cer­tain Git plat­forms or na­tional tele­vi­sion broad­cast­ers, is of­ten per­ceived as a ma­jor bar­rier to IPv6 progress. However, this may re­flect prag­matic con­straints, such as op­er­a­tional com­plex­ity, or, in the case of na­tional broad­cast­ers, le­gal and reg­u­la­tory re­quire­ments around data ac­cess and ge­olo­ca­tion, rather than re­sis­tance.

Let’s rec­og­nize the 50% mile­stone, even as the jour­ney con­tin­ues

Whatever one’s view on the de­ci­sion to in­tro­duce a sec­ond ad­dress­ing and pro­to­col model be­neath to­day’s Internet ser­vices, the re­al­ity is clear: IPv6 is now de­ployed on a global scale. Around half of the Internet users vis­i­ble to Google al­ready reach its ser­vices over IPv6. IPv6 is used every day, every hour, across de­vel­oped and de­vel­op­ing economies alike, on fixed and mo­bile net­works, on small per­sonal de­vices, and within vast data‑cen­tre‑backed ser­vices. It is no longer ex­per­i­men­tal or mar­ginal; it is part of the Internet’s day‑to‑day op­er­a­tion.

That achieve­ment re­flects the col­lec­tive ef­fort of those work­ing to build, op­er­ate, and grow the Internet world­wide, and it is some­thing worth rec­og­niz­ing and tak­ing pride in.

The views ex­pressed by the au­thors of this blog are their own and do not nec­es­sar­ily re­flect the views of APNIC. Please note a Code of Conduct ap­plies to this blog.

1 day ago

Erika Benke

Oodi Library, Helsinki

Finland’s li­braries are in­creas­ingly be­ing val­ued not by how many books they lend, but how they help so­ci­eties func­tion.

On a freez­ing January morn­ing in Helsinki, around 20 peo­ple gather out­side Oodi, the city’s cen­tral li­brary, wait­ing for the doors to open.

“I have tears in my eyes when I see peo­ple al­most run into the build­ing at 08:00, head­ing straight to their favourite spots,” says Katri Vänttinen, di­rec­tor of li­brary ser­vices for the whole of the Finnish cap­i­tal. “It shows that the li­brary re­ally be­longs to the pub­lic.”

By lunchtime, the build­ing is so full that vis­i­tors wan­der be­tween floors look­ing for an empty seat. Students work on lap­tops be­side huge win­dows over­look­ing Finland’s par­lia­ment and par­ents read with ba­bies and tod­dlers in brightly coloured play ar­eas.

A small group sits in a cir­cle: they’re knit­ting woollen socks, those with more ex­pe­ri­ence help­ing new­com­ers with tech­niques and pat­terns. In a li­brary mu­sic pod, a mid­dle-aged man records his first sax­o­phone track. In the li­brary café, an el­derly woman holds a Finnish con­ver­sa­tion class for two for­eign girls. By the en­trance, a teenage boy picks up a bas­ket­ball he’s bor­rowed and joins his friends on the li­brary court just out­side.

Research emerg­ing from these ini­tia­tives — not just in Finland, but also in Norway, Sweden, Denmark and Canada — al­ready sug­gests that li­braries play a sig­nif­i­cant role in pro­mot­ing so­cial in­clu­sion, mak­ing a poignant ar­gu­ment: what if the value of li­braries is not in how many books they lend, but more in how they help so­ci­eties func­tion? And what can the world learn from this Finnish model?

Not just books

Finland has more than 700 li­braries for a pop­u­la­tion of 5.6 mil­lion, of­fer­ing every­thing from pod­cast stu­dios and 3D print­ing to ten­nis rack­ets and swim­ming pool passes.

According to Vänttinen, the most bor­rowed items af­ter books in Helsinki li­braries are spaces: rooms that can be pre-booked, free of charge, to meet, study, hold po­lit­i­cal dis­cus­sions or make mu­sic. Among portable items, board games and con­sole games top the list.

Oodi Library, Helsinki

This cul­ture of bor­row­ing, Vänttinen ex­plains, is rooted in deep-seated prag­ma­tism that stretches back to Finland’s rural past, when peo­ple rou­tinely shared farm­ing ma­chin­ery. “Today, many peo­ple in cities live in small homes, and they might need a sewing ma­chine only once a year,” says Vänttinen. “So why buy one? People pre­fer not to spend their own money when they can ac­cess a sewing ma­chine for free, funded through their taxes.”

Six hun­dred kilo­me­tres north of Helsinki, the city of Oulu’s newly re­fur­bished cen­tral li­brary Saari re­flects the same think­ing, says li­brary clerk Chris Stephenson while load­ing a mi­cro­film reader for a vis­i­tor to browse an old news­pa­per.

Around him, read­ers fill long ta­bles be­neath soft lamps. A newly re­tired teacher is print­ing sheet mu­sic for the choir he sings in and the band where he plays the gui­tar. One floor up, a young man ar­rives to shorten his jeans af­ter book­ing a slot for a sewing ma­chine. In the same room, a 3D printer hums be­hind a school­girl us­ing a heat press to make a T-shirt she’s de­signed for a friend’s birth­day. A laser cut­ter sits idly by.

We reach prac­ti­cally every­one, re­gard­less of so­ci­etal or cul­tural sta­tus. This is true every­day democ­racy — Katri Vänttinen

Before mov­ing to Finland, Stephenson worked in li­braries in the UK for 20 years. “I saw many li­braries closed down, and com­mu­ni­ties los­ing some­thing im­por­tant,” he says.

According to Noora Hirvonen, pro­fes­sor of in­for­ma­tion stud­ies at the University of Oulu, cut­ting un­der­used ser­vices to save money can be­come a self-ful­fill­ing prophecy. “We first cut li­brary open­ing hours and, as a re­sult, li­brary vis­its drop,” says Hirvonen. “This is then used as a rea­son for ad­di­tional cuts or even clos­ing the li­brary.”

Instead, Hirvonen ar­gues, in­sti­tu­tions should ask why the ser­vice is not used. Is it be­cause peo­ple do not find it valu­able, they do not have ac­cess to it, or they do not know about it?

“Usage is not only re­flec­tive of the value of the ser­vice: it’s shaped by things like vis­i­bil­ity and avail­abil­ity,” says Hirvonen.

Pillars of democ­racy

But the sig­nif­i­cance of Finnish li­braries ex­tends far be­yond tools and meet­ing rooms.

Professors, un­em­ployed and home­less peo­ple all use the same li­brary spaces, mak­ing li­braries a key part of Finland’s de­mo­c­ra­tic in­fra­struc­ture, says Hirvonen. “They’re places where any­one can ac­cess knowl­edge, meet oth­ers and take part in pub­lic de­bate, re­gard­less of in­come or back­ground,” Hirvonen says.

While these are core val­ues of li­brar­i­an­ship every­where in the world, says Hirvonen, in the Nordic coun­tries, they are em­bed­ded in law. Under the Finnish Library Act, pub­lic li­braries must pro­mote democ­racy, free­dom of ex­pres­sion and ac­tive cit­i­zen­ship. (Some other Nordic coun­tries have sim­i­lar poli­cies too.)

More like this:

Finland’s in­vest­ment re­flects this com­mit­ment: in 2025, the coun­try spent nearly €371m ($430m/£321m) on its pub­lic li­braries — that’s €65.78 ($76/£57) per per­son, com­pared to the av­er­age £10 ($13.5) per per­son spent in the UK, and a to­tal pub­lic li­brary ex­pen­di­ture of $15.2bn (£11.4bn ), or $45 (£34) per per­son in the US.

“Libraries can di­rectly sup­port democ­racy — this is one thing the world can learn from Finland,” says li­brary scholar R David Lankes from the University of Texas, who be­lieves li­braries thrive when com­mu­ni­ties ac­tively use them to learn, de­bate and cre­ate knowl­edge to­gether.

Erika Benke

Librarians help cus­tomers nav­i­gate on­line bu­reau­cracy, from tax ser­vices and bank ac­counts to pen­sion por­tals and dig­i­tal health records, and they rou­tinely pro­vide as­sis­tance with writ­ing CVs and job ap­pli­ca­tions. As a re­sult, a re­cent study of Finnish li­braries con­cluded that li­braries func­tion as crit­i­cal in­clu­sion in­fra­struc­ture.

“This pro­motes in­clu­sion,” says Mervi Vaara, a man­ager for re­gional li­brary ser­vices in Oulu. “The li­brary is like a shared liv­ing room for every­one.”

The whole Finnish wel­fare sys­tem in one build­ing — Nasima Razmyar

As a re­sult, an analy­sis of 38 stud­ies from around the world found that pub­lic li­braries con­sis­tently re­turn more value than they cost, giv­ing back from three to five dol­lars for every dol­lar in­vested. The study em­pha­sises that li­braries cre­ate both di­rect ben­e­fits — such as sav­ings from bor­row­ing rather than buy­ing, and sup­port for job­seek­ers — and in­di­rect ben­e­fits, in­clud­ing im­proved lit­er­acy, dig­i­tal com­pe­tence, em­ploy­a­bil­ity and com­mu­nity well­be­ing.

In an­nual eval­u­a­tions car­ried out by Finland’s re­gional au­thor­i­ties, li­braries con­sis­tently top the list of most val­ued pub­lic ser­vices. “We reach prac­ti­cally every­one, re­gard­less of so­ci­etal or cul­tural sta­tus,” says Vänttinen. “This is true every­day democ­racy.”

In the 2023 re­port, Finns de­scribed li­braries as trusted sources of in­for­ma­tion and dig­i­tal con­tent. “Trust in gov­ern­ment in­sti­tu­tions has been de­clin­ing for decades,” says Lankes, nod­ding to global sur­veys like the Edelman Trust Barometer, which shows a steady long-term drop in trust in pub­lic in­sti­tu­tions in many coun­tries. “But trust in li­braries and li­brar­i­ans re­mains ex­tremely high.”

Libraries, Lankes ar­gues, are among the few pub­lic spaces where peo­ple can sim­ply ex­ist with­out be­ing ex­pected to con­sume. “You can’t go to town hall and just hang out. You can’t go to the po­lice sta­tion and just hang out,” Lankes says. “But you can come to the li­brary and just be.”

Sanna Krook

And while Finns ac­tu­ally also still en­joy high lev­els of trust in pub­lic in­sti­tu­tions, ac­cord­ing to sur­veys, they face what re­searchers call a “participation para­dox”: de­spite trust­ing in­sti­tu­tions, many cit­i­zens still feel they have lit­tle real in­flu­ence over po­lit­i­cal de­ci­sions. Ultimately, li­braries can bridge that gap too, says Elina Eerola of the Finnish in­no­va­tion fund Sitra, who worked on a re­port on how li­braries can pro­mote democ­racy.

Eerola says li­braries can cre­ate ac­ces­si­ble spaces where cit­i­zens can meet de­ci­sion-mak­ers and take part in de­bates. Sitra’s pi­lot pro­jects have used li­braries to host com­mu­nity dis­cus­sions and events to con­nect cit­i­zens di­rectly with politi­cians and pub­lic in­sti­tu­tions.

A per­sonal im­pact

For some Finns, the im­pact of li­braries is not mea­sured in sta­tis­tics. Nasima Razmyar, now a mem­ber of the Finnish par­lia­ment, ar­rived from Afghanistan as a refugee at the age of eight. She still re­mem­bers the mo­ment she re­ceived her first li­brary card: the first phys­i­cal ob­ject she owned in Finland. “When I signed my name and re­ceived it, I sud­denly felt this place be­longed to me,” says Razmyar.

Growing up in the Helsinki neigh­bour­hood of Käpylä, she spent af­ter­noons study­ing in the lo­cal li­brary af­ter school. “My par­ents did­n’t speak Finnish, so the li­brary work­ers some­times helped me with my home­work,” she says. “That lo­cal li­brary was equal­ity,” she says. “The whole Finnish wel­fare sys­tem in one build­ing.”

As the af­ter­noon light fades out­side a Helsinki li­brary win­dow, Razmyar now watches her young chil­dren choose their books. “I think it gives chil­dren the feel­ing that they be­long here, and this is for them, which is re­ally im­por­tant,” she says.

–

For more sci­ence, tech­nol­ogy, en­vi­ron­ment and health sto­ries from the BBC, fol­low us on Facebook and Instagram.

Developers don’t un­der­stand CORS

July 10, 2019 — Chris Foster

One of the best things about work­ing in full stack con­sult­ing is that I get to work with a great num­ber of de­vel­op­ers with dif­fer­ent skill lev­els in com­pa­nies from var­i­ous sizes and in­dus­tries. This pro­vides an op­por­tu­nity to see what uni­ver­sal strug­gles come up. One that seems com­mon and rel­e­vant re­cently is this: Too many web de­vel­op­ers do not un­der­stand how CORS works.

This seems par­tic­u­larly timely to point out be­cause of the re­cent Zoom vul­ner­a­bil­ity. Security re­searcher Jonathan Leitschuh found Zoom has a web server lis­ten­ing on the ma­chine at http://​lo­cal­host:19421. When you load a Zoom link, Zoom’s web­site sends a re­quest to the lo­cal­host web­server and tells it to open up the na­tive Zoom app. The whole ar­ti­cle is worth a read, but these parts stuck out to me:

I also found that, in­stead of mak­ing a reg­u­lar AJAX re­quest, this page in­stead loads an im­age from the Zoom web server that is lo­cally run­ning. The dif­fer­ent di­men­sions of the im­age dic­tate the er­ror/​sta­tus code of the server. You can see that case-switch logic here. One ques­tion I asked is, why is this web server re­turn­ing this data en­coded in the di­men­sions of an im­age file? The rea­son is, it’s done to by­pass Cross-Origin Resource Sharing (CORS). For very in­ten­tional rea­sons, the browser ex­plic­itly ig­nores any CORS pol­icy for servers run­ning on lo­cal­host.

I also found that, in­stead of mak­ing a reg­u­lar AJAX re­quest, this page in­stead loads an im­age from the Zoom web server that is lo­cally run­ning. The dif­fer­ent di­men­sions of the im­age dic­tate the er­ror/​sta­tus code of the server. You can see that case-switch logic here.

One ques­tion I asked is, why is this web server re­turn­ing this data en­coded in the di­men­sions of an im­age file? The rea­son is, it’s done to by­pass Cross-Origin Resource Sharing (CORS). For very in­ten­tional rea­sons, the browser ex­plic­itly ig­nores any CORS pol­icy for servers run­ning on lo­cal­host.

That last sen­tence is in­cor­rect — Chrome does re­spect CORS head­ers for lo­cal­host web­servers. If you’re a web de­vel­oper you’ve prob­a­bly done this when you have Create React App with your fron­tend app on one port and your back­end API on an­other port. Your app is mak­ing cross ori­gin re­quests against lo­cal­host, and this is sup­ported in all browsers.

What this says to me is that Zoom may have needed to get this fea­ture out and did not un­der­stand CORS. They could­n’t make the AJAX re­quests with­out the browser dis­al­low­ing the at­tempt. Instead, they built this im­age hack to work around CORS. By do­ing this, they opened Zoom up to a big vul­ner­a­bil­ity be­cause not only can the Zoom web­site trig­ger op­er­a­tions in the na­tive client and ac­cess the re­sponse, but every other web­site on the in­ter­net can too.

So what would a se­cure im­ple­men­ta­tion of this fea­ture look like? The web­server lis­ten­ing in on lo­cal­host:19421 should im­ple­ment a REST API and set a Access-Control-Allow-Origin header with the value https://​zoom.us. This will en­sure that only Javascript run­ning on the zoom.us do­main can talk to the lo­cal­host web­server. Further, to stop pages be­ing able to open Zoom meet­ings au­to­mat­i­cally in the back­ground zoom.us should have a Content Security Policy header that blocks ren­der­ing within an iframe.

This still leaves the vul­ner­a­bil­ity that any page can redi­rect your browser to a zoom.us link for a meet­ing that you did­n’t ex­pect, but this is a user ex­pe­ri­ence de­ci­sion that Zoom has made rather than a soft­ware vul­ner­a­bil­ity. Personally, I think the ap­proach is wrong here too. They men­tion they de­sired a bet­ter user ex­pe­ri­ence by open­ing the ap­pli­ca­tion di­rectly, but one of the rules of good user ex­pe­ri­ence de­sign is that your soft­ware must be pre­dictable.

If I am click­ing a link, I ex­pect that it will not sud­denly make my cam­era and mi­cro­phone avail­able to peo­ple I do not know. Zoom is break­ing this ex­pec­ta­tion. Even if they don’t want the built-in browser popup for UX rea­sons, put this popup in-app! Google Meet does this well:

I don’t want to take away from the CORS fo­cus of this post. Regardless of the user ex­pe­ri­ence side of the ar­gu­ment, run­ning a web­server on lo­cal­host is a risky en­deav­our to be­gin with. It should ab­solutely not be pro­vid­ing priv­i­leged ac­cess to func­tions, such as in­stalling soft­ware, to every web­site on the in­ter­net. CORS en­ables you to se­curely do this — don’t hack around it!

I can’t know for sure if fail­ure to un­der­stand CORS is why Zoom im­ple­mented the fea­ture this way. However, I’ve talked to a few peo­ple and none of us can col­lec­tively find any le­git­i­mate rea­son to im­ple­ment their ex­ist­ing ap­proach. On red­dit, leruni­corn did find and sug­gest that Firefox may block XHRs from se­cure to non-se­cure ori­gins which could ex­plain the mo­ti­va­tion be­hind this ap­proach. However, Firefox sup­ports this when the ori­gin is lo­cal­host. Further, na­tive apps can gen­er­ate a unique self-signed cer­tifi­cate. Alternatively, they could have used a browser ex­ten­sion. In any pos­si­ble case, this is not a valid rea­son to for­get to fil­ter ori­gins.

It’s not just Zoom. Anecdotally, lots of de­vel­op­ers I’ve talked with don’t un­der­stand well how CORS works. There’s also very a gen­er­ous quan­tity of ex­am­ples from ques­tions on Stack Overflow. Unfortunately, these are of­ten paired with pages that rec­om­mend very in­se­cure de­faults like this one in ex­press which would make your ap­pli­ca­tion vul­ner­a­ble if copied ver­ba­tim. Other ven­dors have been caught with the ex­act same vul­ner­a­bil­ity found in Zoom.

Developers just want to get their code to work, and by­pass­ing the same-ori­gin pol­icy en­tirely might get it to work, but when some­one finds out what you’ve done you’ll get prob­lems like Zoom has now.

I’ve seen CORS con­fu­sion from both ex­pe­ri­enced and new de­vel­op­ers. Is the CORS API too com­plex and con­fus­ing, or do we only need bet­ter de­vel­oper ed­u­ca­tion around is­sues like CORS and CSP? I’m not sure, but the cur­rent ap­proach def­i­nitely does­n’t seem like it’s work­ing.

During sev­eral re­cent con­ver­sa­tions, peo­ple have told me that they’ve stopped check­ing their phones in the morn­ing. Not be­cause noth­ing was hap­pen­ing, but be­cause every­thing was. They de­scribed the feel­ing as stand­ing un­der a wa­ter­fall of per­pet­ual bad news.

This ex­pe­ri­ence is far from an iso­lated one. According to Reuters Institute’s 2025 Digital News Report, 69 per­cent of Canadians at least oc­ca­sion­ally avoid the news now.

Globally, 40 per­cent re­port they at least some­times or of­ten do the same, the high­est fig­ure ever recorded. People shared con­sis­tent rea­sons for this: the news put them in a bad mood, they felt over­whelmed and pow­er­less to act.

As a re­searcher in de­vel­op­men­tal psy­chol­ogy, fo­cus­ing on so­cial de­vel­op­ment and psy­cho­log­i­cal well-be­ing, I ar­gue that news fa­tigue is not lazi­ness, weak­ness or a gen­er­a­tional de­cline in civic in­ter­est. It’s the pre­dictable re­sponse of a hu­man brain meet­ing an en­vi­ron­ment it was never de­signed to nav­i­gate.

Wired for bad news

Long be­fore smart­phones or even the print­ing press, our cog­ni­tive ar­chi­tec­ture was shaped by a sin­gle prob­lem: stay alive long enough to re­pro­duce. Our an­ces­tors whose at­ten­tion drifted past the rus­tle in the grass left fewer de­scen­dants than those who froze, looked and lis­tened.

The brain that paid at­ten­tion to threats was the brain that sur­vived.

This is the foun­da­tion of what psy­chol­o­gists call the neg­a­tiv­ity bias, one of the most repli­cated find­ings in cog­ni­tive sci­ence. Across decades of re­search, the hu­man mind has been shown to weigh neg­a­tive in­for­ma­tion more heav­ily than pos­i­tive, at­tend to it faster and re­mem­ber it longer.

A preda­tor nearby mat­tered more than a beau­ti­ful sun­set. The cost of miss­ing a real threat was death, while the cost of over­re­act­ing was a few min­utes of wasted vig­i­lance. The asym­me­try made this bias adap­tive.

Here is the prob­lem: the hu­man brain has not changed since then. We are the same species as we were thou­sands of years ago. What’s changed is the size of the world it’s asked to scan for threats.

Scanning the whole world

For most of hu­man his­tory, the threats our ner­vous sys­tem processed were lo­cal. A neigh­bour­ing tribe. A drought. The ill­ness of a child we per­son­ally knew. Information about dis­tant places would barely ar­rive, and if it did, it was mainly ir­rel­e­vant.

In 2026, the same neu­ro­log­i­cal sys­tem is be­ing asked to ab­sorb a war in one re­gion, a fi­nan­cial shock in an­other, a cli­mate dis­as­ter in a third and a vi­o­lent crime in a fourth, all be­fore lunchtime.

A study pub­lished in the sci­en­tific jour­nal Nature Human Behaviour ex­am­ined more than 105,000 real news head­lines viewed nearly six mil­lion times. Each ad­di­tional neg­a­tive word in­creased click-through rates, while pos­i­tive words had the op­po­site ef­fect.

Recent stud­ies sug­gest peo­ple around the world demon­strate mea­sur­ably stronger phys­i­o­log­i­cal re­sponses to neg­a­tive news than to pos­i­tive news. The body is re­act­ing be­fore the mind has de­cided whether the threat is rel­e­vant.

Some re­searchers have in­tro­duced a clin­i­cal frame­work for what hap­pens in this in­stance called Problematic News Consumption (PNC) — a pat­tern of news en­gage­ment that re­sults in pre­oc­cu­pa­tion, dys­reg­u­la­tion and dis­rup­tion to daily func­tion­ing. In their 2022 study, the re­searchers found that 17 per­cent of American adults qual­i­fied as hav­ing se­vere lev­els of PNC. Among that group, 61 per­cent re­ported feel­ing un­well quite a bit or very much, com­pared with six per­cent of those who did­n’t.

For mi­nor­ity pop­u­la­tions, news fa­tigue may be even more con­se­quen­tial.

Repeatedly wit­ness­ing harm di­rected at our own groups, even when we’re not the im­me­di­ate tar­get, can have a sig­nif­i­cant psy­cho­log­i­cal im­pact on peo­ple from the same group af­fil­i­a­tion. For racial­ized com­mu­ni­ties, such as im­mi­grants, the cog­ni­tive load could be even heav­ier, and the op­tion to sim­ply stop watch­ing is much harder to ex­er­cise when the news is about their coun­try of ori­gin.

Looking away is not the fix

What’s the so­lu­tion to news fa­tigue? Well, it’s not avoid­ance. A democ­racy de­pends on in­formed cit­i­zens.

Many adults al­ready cite the spread of mis­lead­ing in­for­ma­tion as a ma­jor source of stress. Withdrawing from ac­cu­rate, trust­wor­thy in­for­ma­tion only deep­ens the prob­lem. We’re wired to pay more at­ten­tion to bad news, and that kind of con­tent will find its way to us one way or an­other.

The fix is to man­age the con­sump­tion and the sources.

Several ap­proaches can help man­age news fa­tigue and pro­tect men­tal health. Containing news con­sump­tion to de­fined win­dows of time re­duces the sense of be­ing over­whelmed. Choosing depth over vol­ume also mat­ters: one care­fully re­ported long-form ar­ti­cle will in­form you bet­ter than bursts of ran­dom, un­re­li­able and emo­tion­ally loaded posts on Instagram.

There is also value in dis­tin­guish­ing be­tween in­for­ma­tion and ac­tion — re­search on per­ceived con­trol and stress con­sis­tently shows that the gap be­tween aware­ness and agency is one of the strongest pre­dic­tors of psy­cho­log­i­cal dis­tress. Identifying what you can ac­tu­ally do about what you read in the news, how­ever small, reg­u­lates that re­sponse.

Finally, be wary of “rage bait” — in­ten­tion­ally provoca­tive mes­sages or con­tent de­signed to boost en­gage­ment on so­cial me­dia plat­forms by elic­it­ing neg­a­tive re­ac­tions. Recognizing that cer­tain con­tent cre­ators want to pro­voke rather than re­flect re­al­ity cre­ates use­ful cog­ni­tive dis­tance.

The news will not be­come less “heavy.” But our re­la­tion­ship with it can be­come more de­lib­er­ate. Our brains were not built for this scale of in­put. They were, how­ever, built to learn to adapt.

Real-Time Strategy

Redefined

Every unit, pro­jec­tile and ex­plo­sion sim­u­lated in real-time

Unmatched

Scale & re­al­ism

All units and pro­jec­tiles are sim­u­lated in real-time. The game of­fers fully sim­u­lated pro­jec­tile bal­lis­tics, ex­plo­sion physics and ter­rain de­for­ma­tion.

Enjoy an im­mer­sive RTS ex­pe­ri­ence, whether you are com­mand­ing in­di­vid­ual units, or armies of thou­sands. Take con­trol as you en­gage in an epic strug­gle for dom­i­na­tion!

ScreenshotsGameplay

Strategic

Importance of ter­rain

The shape of every bat­tle­field in-game im­poses which strate­gies work and which units are ef­fec­tive. No two maps will play the same. Radar can­not pen­e­trate moun­tains and nu­clear war­fare will phys­i­cally al­ter the ter­rain.

Utilize over 10 dif­fer­ent unit classes, in­clud­ing all-ter­rain Experimental units, to work your way to vic­tory.

Learn how to Play

Countless

World-class con­trols

Your power lies in the care­ful bal­ance of ex­po­nen­tially grow­ing your re­source in­come and the pro­duc­tion of dev­as­tat­ing war ma­chines.

You de­cide if you want to dis­arm your en­e­mies with a few pre­cise early strikes or to build a thou­sand bombers and oblit­er­ate them.

Immerse your­self in a vi­o­lent world where tac­ti­cal and strate­gi­cal su­premacy are needed in your fight to­wards vic­tory.

Commands Overview

Relentless game de­sign

Unique and with a pur­pose

Each and every unit in the game has a role to fill. Mix-and-match units to cre­ate in­fi­nite pos­si­ble tac­tics. Experiment with your own com­bi­na­tions and show off the new strate­gies you de­velop in bat­tle.

‍

Compare Units

Linux 7.2 has fi­nally elim­i­nated the strncpy API from the Linux ker­nel. The strncpy() func­tion for copy­ing up to a spec­i­fied num­ber of bytes has long been dep­re­cated and af­ter six years of work and hun­dreds of patches, no more users of the strncpy in­ter­face within the Linux ker­nel re­mained that it has now been elim­i­nated.

The strncpy func­tion within the Linux ker­nel has been a “persistent source of bugs” for years due to counter-in­tu­itive se­man­tics and be­hav­ior around NUL ter­mi­na­tion along with per­for­mance is­sues due to re­dun­dant zero-fill­ing of the des­ti­na­tion. It took work over the last six years with around 362 com­mits to elim­i­nate users of strncpy code within the ker­nel, but they are over the fin­ish line for Linux 7.2.

This merge on Friday elim­i­nated the strncpy API and the last per CPU ar­chi­tec­ture strncpy im­ple­men­ta­tions.

In place of strncpy, Linux ker­nel code should use strscpy() for NUL ter­mi­nated des­ti­na­tions, strscpy_­pad() for NUl-terminated des­ti­na­tions with zero-padding, str­tomem_­pad() for non-NUL-ter­mi­nated fixed-width fields, mem­cpy_and_­pad() for bounded copies with ex­plicit padding, or mem­cpy() for known-length mem­ory copies.

First, I want to tell you how ex­actly I got to this point and why I started re­search­ing dif­fer­ent op­tions for han­dling asyn­chro­nous I/O on Linux… Last year, my stu­dents and I built a re­verse proxy server called TinyGate. It was su­per sim­ple, worker-based, and it ba­si­cally worked well. Of course, I did­n’t ex­pect it to be very fast, but it was an ed­u­ca­tional pro­ject, and since we’d made a real, kind of pro­duc­tion-ready tool, I was re­ally proud of it. But my stu­dents weren’t as happy as I was - they wanted to build some­thing gen­uinely use­ful, and they were re­ally dis­ap­pointed that our “product” had strong ar­chi­tec­tural lim­its and could­n’t out­per­form ti­tans like ng­inx and haproxy. So they lit­er­ally forced me to re­search to­gether how those tools work un­der the hood and how to han­dle asyn­chro­nous I/O to cut down on the heavy over­head… Long story short, we made a sec­ond ver­sion of TinyGate, based on epoll. It still lost to ng­inx/​haproxy in bench­marks, but it had a dra­matic per­for­mance boost com­pared to the first ver­sion. But epoll is­n’t per­fect ei­ther (as I’ll ex­plain be­low), and we even­tu­ally switched to io_ur­ing, which led to a full rewrite of our pro­ject from scratch, again… So it’s a re­ally in­ter­est­ing topic, and to­day I’ll share an overview of the two queue­ing sys­tems Linux gives you for asyn­chro­nous I/O.

epoll her­itage

When I just started de­vel­op­ing for Linux, epoll was a new fea­ture, and ba­si­cally it had no al­ter­na­tives. Everyone used it to man­age asyn­chro­nous ex­e­cu­tion - there was no other choice. The prob­lem is, epoll re­lies heav­ily on syscalls: it tells you when I/O is pos­si­ble, but you still have to call read()/​write() your­self af­ter­ward - that’s two syscalls per I/O event, on top of the one-time epol­l_ctl reg­is­tra­tion. Each of these syscalls causes a con­text switch be­tween user and ker­nel mode, which cre­ates HUGE over­head once you’re han­dling a lot of con­nec­tions. But we have a so­lu­tion! About 17 years af­ter epoll landed in the Linux ker­nel (2002), io_ur­ing ap­peared (2019)! Instead of telling you when I/O is pos­si­ble, it tells you when I/O is done - no polling loop, and far less as­so­ci­ated syscalls.

The ker­nel con­sumes sub­mis­sions from mem­ory shared be­tween your app and the ker­nel, and posts com­ple­tions back into that same shared mem­ory - both live in ring buffers, hence the name. The catch: by de­fault you still have to call io_ur­ing_en­ter() to tell the ker­nel “go check the sub­mis­sion queue” - but one call can sub­mit a whole batch of op­er­a­tions and reap a whole batch of com­ple­tions, in­stead of one syscall pair per op­er­a­tion like with epoll + read. If you want close to zero syscalls dur­ing steady state, there’s IORING_SETUP_SQPOLL, which spins up a ded­i­cated ker­nel thread that polls the sub­mis­sion queue for you - at the cost of that thread burn­ing CPU (more on this be­low).

A lit­tle com­par­i­son

Basic ar­chi­tec­ture: as I said be­fore, epoll no­ti­fies you when I/O is pos­si­ble, io_ur­ing no­ti­fies you when I/O is done. Where epoll makes every I/O op­er­a­tion cross the ker­nel bound­ary, io_ur­ing lets you pay a small “setup fee” once (creating the ring) plus a per-batch fee (the io_ur­ing_en­ter() call) in­stead of a fee per op­er­a­tion. So in­stead of a syscall pair per I/O, you get a syscall per batch of I/Os - or, with SQPOLL, close to none at all. As you can see, with a ton of I/O hap­pen­ing, this saves a lot of syscalls.

On rel­a­tively new sys­tems where io_ur­ing is sup­ported (kernel v5.1+, re­leased in 2019), there’s of­ten not much rea­son to reach for epoll. The shift from a readi­ness model to a com­ple­tion model is a huge ar­chi­tec­tural change - it moves a big part of the work out of your ap­pli­ca­tion and into the ker­nel.

Let’s code!

Of course, I won’t leave you with­out some code show­ing how both sys­tems work. We’ll use C. (The io_ur­ing ex­am­ple uses libur­ing, the user­space helper li­brary - in­stall it via libur­ing-dev/​libur­ing-de­vel, or drop down to the raw io_ur­ing_setup/​io_ur­ing_en­ter syscalls if you want zero de­pen­den­cies.)

epoll

Let’s make a sim­ple ex­am­ple of how epoll works. We’ll cre­ate the in­stance, reg­is­ter a file de­scrip­tor (stdin, in our case), and process the in­com­ing event.

As you can see, this ex­am­ple uses three syscalls in to­tal: epol­l_ctl (a one-time reg­is­tra­tion), then epol­l_wait and read for the event - so two syscalls per ac­tual I/O event, like I men­tioned above. The code it­self is pretty easy to fol­low.

io_ur­ing

Now let’s do the same thing with io_ur­ing in­stead of epoll.

What can we see here?

Similar in­stance cre­ation step.

No epol­l_ctl reg­is­tra­tion step needed.

No readi­ness check needed be­fore sub­mis­sion.

No sep­a­rate read() call at com­ple­tion.

Yeah, io_ur­ing takes way fewer re­sources for this - though, as noted above, there’s still one io_ur­ing_en­ter() call hid­ing in­side io_ur­ing_­sub­mit() and io_ur­ing_wait­_cqe() un­less you’re run­ning with SQPOLL.

When you test these ex­am­ples, keep in mind that for the sake of sim­plic­ity, some im­por­tant parts are miss­ing. For ex­am­ple, it will block for­ever if stdin never pro­duces any data, and the io_ur­ing ex­am­ple skips check­ing for a NULL sqe (which io_ur­ing_get_sqe() can re­turn if the sub­mis­sion queue is full).

Something ad­di­tional about io_ur­ing

Zero-copy. For real zero-copy I/O, reg­is­ter your buffers ahead of time with io_ur­ing_reg­is­ter_buffers() - this avoids the ker­nel re-map­ping mem­ory on every sin­gle op­er­a­tion. For net­work sends specif­i­cally, look at IORING_OP_SEND_ZC (kernel 6.0+ needed), which skips copy­ing the buffer into the ker­nel en­tirely.

SQPOLL uses CPU. Even when your queue is empty, IORING_SETUP_SQPOLL keeps a ker­nel thread spin­ning and polling, which burns CPU. There’s an idle time­out (sq_thread_idle) af­ter which it backs off to sleep­ing, but it’s not free.

Asynchronous er­ror han­dling. Errors come back (and must be han­dled) asyn­chro­nously, as part of the cqe’s res field - not as a di­rect re­turn value like a nor­mal syn­chro­nous syscall.

Summary

io_ur­ing is the new stan­dard for async I/O in the mod­ern Linux world, and hon­estly, I don’t see much rea­son to still reach for epoll on a sys­tem that has it. For a from-scratch pro­ject on a mod­ern Linux server, like our TinyGate rewrite, io_ur­ing is ab­solutely the way to go. I’m a die-hard sup­porter of drop­ping sup­port for old sys­tems as soon as it’s rea­son­able - if you’re still run­ning a ker­nel re­leased more than 7 years ago, in my opin­ion, that’s not a great idea…