The European Commission has opened

a “call

for ev­i­dence” to help shape its European Open Digital Ecosystem Strategy. The com­mis­sion is look­ing to re­duce its de­pen­dence on soft­ware from non-EU coun­tries:

The feed­back pe­riod runs un­til mid­night (Brussels time) February 3, 2026. The com­mis­sion seeks in­put from all in­ter­ested stake­hold­ers, “in par­tic­u­lar the European open-source com­mu­nity

(including in­di­vid­ual con­trib­u­tors, open-source com­pa­nies and

foun­da­tions), pub­lic ad­min­is­tra­tions, spe­cialised busi­ness sec­tors,

the ICT in­dus­try, acad­e­mia and re­search in­sti­tu­tions”.

I dis­cov­ered a Default ArcGIS API key em­bed­ded in Flock Safety’s pub­lic-fac­ing JavaScript bun­dles. This sin­gle cre­den­tial granted ac­cess to the com­pa­ny’s ArcGIS map­ping en­vi­ron­ment, and 50 pri­vate lay­ers, the same in­fra­struc­ture that con­sol­i­dates li­cense plate de­tec­tions, pa­trol car lo­ca­tions, drone teleme­try, body cam­era lo­ca­tions, 911 call data, and sur­veil­lance cam­era lo­ca­tions from ap­prox­i­mately 12,000 law en­force­ment, com­mu­nity, and pri­vate sec­tor de­ploy­ments na­tion­wide. The key was not re­stricted by re­fer­rer, IP, or ori­gin al­low­ing it to be used by any­one, any­where. It was ex­posed pub­licly across 53 sep­a­rate Flock Safety front-end bun­dles and en­vi­ron­ments, each in­stance in­de­pen­dently grant­ing ac­cess to their ArcGIS map­ping plat­form.Across the United States, li­cense plate read­ers, drones, and au­dio sen­sors qui­etly record the move­ments of mil­lions of peo­ple every day. Flock Safety op­er­ates one of the largest and most rapidly ex­pand­ing of these net­works, with hun­dreds of thou­sands of cam­eras gen­er­at­ing over 30 bil­lion ve­hi­cle de­tec­tions each month, and an undis­closed amount of peo­ple de­tec­tions.At the cen­ter of this in­fra­struc­ture is FlockOS, which Flock mar­kets un­der the head­line “One map. Smarter Response.” According to their own doc­u­men­ta­tion, the ArcGIS-powered in­ter­face “consolidates all data streams and the lo­ca­tions of each con­nected as­set, en­abling greater sit­u­a­tional aware­ness and a com­mon op­er­at­ing pro­ce­dure.” (Source: ClearGov Resource Document)That “one map” is not a metaphor. It is the ArcGIS stack it­self and the ex­posed API key un­locked it.The ex­posed cre­den­tial was an or­ga­ni­za­tion-wide ArcGIS API key tied di­rectly to Flock Safety’s ArcGIS map­ping en­vi­ron­ment. It ap­peared in client-side JavaScript bun­dles served from de­vel­op­ment sub­do­mains that were pub­licly ac­ces­si­ble.Query­ing the ArcGIS API with this key re­turned meta­data con­firm­ing its scope and the ex­tent of Flock’s mis­con­fig­u­ra­tion:The cre­den­tial was tagged app­Ti­tle: “Default API Key”, the auto-gen­er­ated key Esri cre­ates at ac­count signup. According to Esri’s ArcGIS doc­u­men­ta­tion:“An API key is a per­ma­nent ac­cess to­ken that de­fines the scope and per­mis­sion for grant­ing your pub­lic-fac­ing ap­pli­ca­tion ac­cess to spe­cific, ready-to-use ser­vices and pri­vate con­tent… An API key is cre­ated for you when you sign up for an ArcGIS Developer ac­count.“The key’s meta­data listed 50 “portal:app:access:item: priv­i­leges each grant­ing ac­cess to a pri­vate ArcGIS item.Given Flock’s cen­tral­ized “one map” ar­chi­tec­ture where par­tic­i­pat­ing agen­cies con­tribute data to shared, Flock-owned lay­ers rather than main­tain­ing sep­a­rate in­stances each of those 50 pri­vate items likely ag­gre­gates data from hun­dreds or thou­sands of agen­cies. A sin­gle Detections layer would con­tain hotlist hits from all ~5,000 par­tic­i­pat­ing po­lice de­part­ments. A sin­gle Mobile Units layer would show pa­trol car po­si­tions across every in­te­grated agency.“For the high­est level of se­cu­rity, al­ways set the API key scopes and re­fer­rers be­fore de­ploy­ing an ap­pli­ca­tion.“Flock ap­plied no re­fer­rer re­stric­tions, no IP al­lowlist, and no scope lim­i­ta­tions. They took the de­fault key, granted it ac­cess to 50 pri­vate items, and em­bed­ded it in client-side JavaScript bun­dles across 53 pub­licly ac­ces­si­ble end­points:Each end­point in­de­pen­dently served the same un­re­stricted cre­den­tial 53 times, and any one of them could have been used to ac­cess Flock’s ArcGIS en­vi­ron­ment.ru=({

es­riMap­sApiKey: t,

base­Lay­ers: n,

dy­nam­i­cLay­ers: i,

fea­ture­Lay­ers: o,

mark­er­Lay­ers: a,

non­Clus­tered­Mark­er­Lay­ers: s,

clus­tered­Mark­er­Lay­ers: l,

heatmapLay­ers: h,

fo­cused­Mark­ers: p,

se­lect­ed­Lay­ers: g,

set­S­e­lect­ed­Lay­ers: A,

on­Base­Lay­er­Change: y,

on­Cus­tomMapLay­erS­e­lec­tion­Change: b

})A sin­gle com­po­nent con­sumes the Esri API key along­side every layer type: base maps, dy­namic over­lays, fea­ture lay­ers, clus­tered and non-clus­tered mark­ers, and heatmaps. Layer se­lec­tion state is man­aged uni­formly across all data sources.In­ter­nal per­mis­sion flags from JavaScript bun­dles con­firm FlockOS’s role as the uni­fied in­ter­face:FlockOS is the in­ter­face; ArcGIS is the sub­strate. The ex­posed API key granted ac­cess to the com­mon map­ping layer where all Flock Safety ap­pli­ca­tions con­verge: cam­era in­ven­to­ries, mo­bile units, de­tec­tion out­puts, hotlists, search geome­tries, drone teleme­try, Raven an­a­lyt­ics, of­fi­cer-ac­ces­si­ble views, and Flock911 in­ci­dents.Peo­ple searches ren­dered as tracked ob­jects on the mapSearch foot­prints—the ac­tual poly­gons and radii in­ves­ti­ga­tors draw when se­lect­ing ge­o­graphic ar­eas of in­ter­est­Counts of in­te­rior and ex­te­rior cam­eras per lo­ca­tionAu­dio and tran­script data flows through the same map con­text as cam­eras, pa­trol units, and alerts. No sep­a­rate se­cu­rity bound­ary ex­ists at the map­ping layer.Every sta­tus chip ren­dered on the pa­trol/​de­vice tray (via hQ) only rec­og­nizes the val­ues: Docked, Buffering, Recording, Inactive, Offline, Off, ON, ONLINE, ACTIVE, Charging, and Uploading. Statuses in the “online/charging/buffering” group ren­der as green; “inactive/offline/off” ren­ders gray; and “recording” ren­ders red. This con­firms the com­plete set of de­vice states ac­tively ren­dered on the shared map UI.The ex­posed Default API Key was not an iso­lated in­ci­dent.I sep­a­rately dis­closed an ad­di­tional crit­i­cal vul­ner­a­bil­ity in­volv­ing unau­then­ti­cated ArcGIS to­ken mint­ing. This vul­ner­a­bil­ity al­lows unau­then­ti­cated users to ob­tain valid ArcGIS to­kens scoped to Flock Safety’s pro­duc­tion en­vi­ron­ment from their de­vel­op­ment en­vi­ron­ment, to­kens ti­tled “Flock Safety Prod” that grant ac­cess to the ge­o­graphic map­ping of Flock’s cam­era net­work lo­ca­tions.I am with­hold­ing spe­cific tech­ni­cal de­tails to pre­vent ex­ploita­tion while the vul­ner­a­bil­ity re­mains un­patched. However, its ex­is­tence more than 55 days af­ter re­spon­si­ble dis­clo­sure with no re­me­di­a­tion, demon­strates a sys­temic pat­tern of cre­den­tial mis­man­age­ment.Both keys op­er­ated un­der the same ac­tive sub­scrip­tion with nearly one mil­lion avail­able cred­its. Critically, de­vel­op­ment en­vi­ron­ments were con­fig­ured with broader ac­cess than pro­duc­tion, and those de­vel­op­ment sites were pub­licly ac­ces­si­ble.The 50 “portal:app:access:item” priv­i­leges ref­er­ence pri­vate item IDs that can­not be in­ven­to­ried with­out ac­tively query­ing each one which I did not do. However, ArcGIS col­lab­o­ra­tion fea­tures al­low part­ner or­ga­ni­za­tions to share lay­ers into an­other or­ga­ni­za­tion’s por­tal, and ev­i­dence sug­gests this ca­pa­bil­ity was ac­tively used.An in­di­vid­ual at a sher­if­f’s of­fice with an ac­tive Flock de­ploy­ment con­firmed dur­ing the course of this re­search that their agency shares ArcGIS lay­ers di­rectly with Flock Safety’s or­ga­ni­za­tion. This cor­rob­o­rates the tech­ni­cal ar­chi­tec­ture doc­u­mented in Esri’s col­lab­o­ra­tion doc­u­men­ta­tion and aligns with the priv­i­lege struc­ture ob­served in the ex­posed cre­den­tial meta­data.What I can state with cer­tainty:Es­ri’s own doc­u­men­ta­tion con­firms that such priv­i­leges grant ac­cess to “hosted fea­ture ser­vices, web maps, web scenes, tile lay­ers” and other pri­vate por­tal con­tentA law en­force­ment source with di­rect knowl­edge of their agen­cy’s Flock in­te­gra­tion con­firmed that layer shar­ing with Flock Safety’s ArcGIS or­ga­ni­za­tion oc­curs in prac­ticeThe key ap­peared across 53 pub­licly ac­ces­si­ble end­points with no re­fer­rer re­stric­tions, IP lim­i­ta­tions, or ac­cess con­trols­Many of the pho­to’s I’ve used as ex­am­ples are from pub­licly ex­posed ArcGIS datasets owned by Police Departments, that have rel­e­vant Flock Safety data in them.Taken to­gether, these find­ings es­tab­lish that the ex­posed cre­den­tial pro­vided a vi­able tech­ni­cal path­way to ac­cess shared law en­force­ment data. The pre­cise con­tents of each pri­vate layer re­main un­ver­i­fied, yet the cir­cum­stan­tial ev­i­dence is sub­stan­tial.For­eign in­tel­li­gence ser­vices would not need ac­cess to com­mu­ni­ca­tions con­tent if they could re­li­ably ob­serve move­ment at this scale. Historical lo­ca­tion data re­veal­ing the pres­ence, rou­tines, and as­so­ci­a­tions of politi­cians, fed­eral agents, in­tel­li­gence per­son­nel, mil­i­tary lead­er­ship, or spe­cial op­er­a­tions units con­sti­tutes in­tel­li­gence in its own right.Con­sider a sce­nario: If mem­bers of SEAL Team 6 or Delta Force dis­ap­pear from road­ways for sev­eral days, that ab­sence is it­self a sig­nal. If, dur­ing the same time­frame, a pri­mary French trans­la­tor also van­ishes from rou­tine move­ment pat­terns, the sig­nal sharp­ens. A co­or­di­nated ab­sence across these roles would strongly sug­gest the ini­ti­a­tion of a spe­cial op­er­a­tions mis­sion in­ferred solely from move­ment data col­lected by a na­tion­wide li­cense plate reader net­work. A top se­cret clear­ance would­n’t be needed for top se­cret in­for­ma­tion.China has pre­vi­ously com­pro­mised ho­tel in­fra­struc­ture for years at a time, not to sur­veil or­di­nary guests, but to cap­ture rare over­laps where of­fi­cials from dif­fer­ent coun­tries stayed in the same lo­ca­tion on the same night. (Source) If ad­ver­saries are will­ing to in­fil­trate ho­tel sys­tems for frag­ments of move­ment data, the in­tel­li­gence value of a na­tion­wide, cen­tral­ized sur­veil­lance map should be self-ev­i­dent.Per­sis­tent, in­dis­crim­i­nate move­ment track­ing en­ables co­er­cion, black­mail, and in­flu­ence op­er­a­tions that do not re­quire ac­cess to com­mu­ni­ca­tions con­tent. Members of Congress, se­nior mil­i­tary lead­ers, diplo­mats, cor­po­rate ex­ec­u­tives and their spouses and chil­dren are all placed at height­ened risk. With suf­fi­cient cov­er­age and time, pat­terns of life emerge. Affairs, undis­closed meet­ings, sen­si­tive re­la­tion­ships, and rou­tine be­hav­iors be­come vis­i­ble once move­ment data is col­lected and cor­re­lated at scale.This is not a the­o­ret­i­cal con­cern. The doc­u­mented his­tory of law en­force­ment mis­use of li­cense plate reader sys­tems, in­clud­ing Flock’s own plat­forms, demon­strates that ac­cess to move­ment data is rou­tinely weaponized for per­sonal pur­poses by those en­trusted with it.Brasel­ton, Georgia (November 2025): Police Chief Michael Steffman was ar­rested and charged with stalk­ing, ha­rass­ment, and mul­ti­ple counts of mis­us­ing au­to­mated li­cense plate recog­ni­tion sys­tems af­ter a months-long Georgia Bureau of Investigation probe re­vealed he used Flock cam­eras to track and ha­rass mul­ti­ple in­di­vid­u­als. Steffman re­signed hours be­fore his ar­rest af­ter serv­ing the de­part­ment for 20 years. Subsequent pub­lic records analy­sis by the grass­roots coali­tion Get The Flock Out re­vealed that Steffman had searched Flock data from agen­cies in other states, in­clud­ing Capitola, California, demon­strat­ing the cross-ju­ris­dic­tional reach en­abled by Flock’s net­work shar­ing ca­pa­bil­i­ties. (Source)Sedgwick, Kansas (2023–2024): Police Chief Lee Nygaard used Flock Safety li­cense plate read­ers to track his ex-girl­friend’s ve­hi­cle 164 times and her new boyfriend’s ve­hi­cle 64 times over a four-month pe­riod. He logged false jus­ti­fi­ca­tions in­clud­ing “missing child,” “drug in­ves­ti­ga­tion,” and “suspicious ac­tiv­ity” to con­ceal the per­sonal na­ture of his searches. Nygaard also fol­lowed the cou­ple in his pa­trol ve­hi­cle out­side city lim­its. He re­signed dur­ing the mis­con­duct in­ves­ti­ga­tion. His po­lice cer­ti­fi­ca­tion was re­voked, though he faced no crim­i­nal charges. (Source)Orange City, Florida (2024–2025): Officer Jarmarus Brown was ar­rested and charged with stalk­ing and unau­tho­rized com­puter ac­cess af­ter us­ing Flock li­cense plate read­ers to track his ex-girl­friend’s where­abouts for ap­prox­i­mately seven months. An au­dit re­vealed he had re­peat­edly run tags for three spe­cific ve­hi­cles. A fel­low of­fi­cer had warned Brown to “stop run­ning her ve­hi­cle in that sys­tem be­cause he could get in trou­ble” a warn­ing Brown ig­nored. Brown also placed a GPS AirTag in the vic­tim’s wal­let with­out her knowl­edge. When con­fronted by in­ves­ti­ga­tors, Brown ad­mit­ted the sit­u­a­tion was “dumb as hell on my end.” He was served ter­mi­na­tion pa­per­work fol­low­ing his ar­rest. (Source)These cases share com­mon pat­terns: trusted of­fi­cials of­ten in lead­er­ship po­si­tions weaponiz­ing sur­veil­lance tools against women with no con­nec­tion to crim­i­nal in­ves­ti­ga­tions. The sys­tems pro­vided few mean­ing­ful bar­ri­ers to mis­use, and de­tec­tion typ­i­cally oc­curred only af­ter vic­tims in­de­pen­dently re­ported sus­pi­cious be­hav­ior.My re­search di­rectly sup­ports Senator Ron Wyden’s claims that “Flock can­not live up to its com­mit­ment to pro­tect the pri­vacy and se­cu­rity of Oregonians” (Letter to Flock) and his urg­ing for the “Federal Trade Commission (FTC) in­ves­ti­gate Flock Safety… and, where ap­pro­pri­ate, hold the com­pany re­spon­si­ble for its neg­li­gent cy­ber­se­cu­rity prac­tices” (Letter to FTC).After the City of Staunton can­celed its Flock Safety con­tract, CEO Garrett Langley sent an un­so­licited email to Staunton Police Department (source) stat­ing:“I’m writ­ing to you di­rectly be­cause I want there to be zero con­fu­sion about what’s hap­pen­ing. Flock has never been hacked. Ever.“That state­ment is tech­ni­cally cor­rect only in the nar­row­est sense. The ab­sence of a breach was not the re­sult of in­ter­nal se­cu­rity con­trols, au­dits, or mon­i­tor­ing but of re­spon­si­ble dis­clo­sure. I iden­ti­fied the vul­ner­a­bil­ity and re­ported it so it could be re­me­di­ated.The ab­sence of a hack does not im­ply the pres­ence of se­cu­rity. Had this cre­den­tial been found by any­one else, this may have been one of the largest data breaches and na­tional se­cu­rity in­ci­dents of this decade.In the same com­mu­ni­ca­tion, Flock as­serted:“Flock is CJIS com­pli­ant”

“Flock ad­heres to the high­est se­cu­rity stan­dards, in­clud­ing NDAA, SOC 2 (Type II), SOC 3, ISO 27001, HECVAT, FERPA, and align­ment with NIST and CAIQ.“As a cy­ber­se­cu­rity pro­fes­sional who has con­ducted dozens of com­pli­ance as­sess­ments, these state­ments are fa­mil­iar. Compliance frame­works are of­ten mis­taken for guar­an­tees of se­cu­rity, when in re­al­ity they are scoped eval­u­a­tions of spe­cific con­trols, not com­pre­hen­sive ex­am­i­na­tions of an or­ga­ni­za­tion’s risk pos­ture. The scope of what is tested is de­fined by the com­pany be­ing as­sessed, which means com­pli­ance re­flects what was re­viewed, not every­thing that ex­ists.I re­quested ac­cess to Flock’s au­dit re­ports; they were not pro­vided. What I can say is this: a de­fault, or­ga­ni­za­tion-wide API key em­bed­ded across 53 pub­licly reach­able de­vel­op­ment and pro­duc­tion-ad­ja­cent web as­sets would not sur­vive even a ba­sic re­view for ex­posed se­crets or sub­do­mains. Its per­sis­tence strongly sug­gests that this at­tack sur­face was ei­ther ex­cluded from the as­sess­ment scope or in­suf­fi­ciently tested.When a de­fault, or­ga­ni­za­tion-wide cre­den­tial per­sists across 53 pub­licly reach­able as­sets, the fail­ure is not merely pro­ce­dural, it is ar­chi­tec­tural. The ex­posed sur­face was not a pe­riph­eral fea­ture or iso­lated test en­vi­ron­ment. It was de­vel­op­ment in­fra­struc­ture con­fig­ured with priv­i­leges that would have granted ac­cess to pri­vate ArcGIS items shared within Flock Safety’s or­ga­ni­za­tion.What You Can DoIf you’re a res­i­dent: File a pub­lic records re­quest for your city’s Flock Safety con­tract and any in­ter­nal au­dit logs. Attend the next city coun­cil meet­ing where sur­veil­lance pro­cure­ment is dis­cussed. The EFF main­tains a Street-Level Surveillance re­source for track­ing these de­ploy­ments.If you’re a jour­nal­ist: The tech­ni­cal ev­i­dence pre­sented here is a start­ing point. I’m avail­able for fol­low-up. There are more threads to pull.If you’re in law en­force­ment: Ask your ven­dor hard ques­tions. Request their pen­e­tra­tion test re­sults. Demand to know where your agen­cy’s data lives and who else can ac­cess it. Your of­fi­cers’ safety de­pends on in­fra­struc­ture that ad­ver­saries can­not triv­ially com­pro­mise.If you’re a pol­i­cy­maker: Senator Wyden’s let­ters to Flock and the FTC are pub­lic record. Support an in­ves­ti­ga­tion. Mandate in­de­pen­dent se­cu­rity au­dits for any ven­dor han­dling law en­force­ment lo­ca­tion data.Al­though the API key has now been ro­tated, the les­son re­mains. If a sin­gle cy­ber­se­cu­rity re­searcher in his early twen­ties could gain di­rect tech­ni­cal ac­cess to an ex­po­sure of this mag­ni­tude, a well-re­sourced for­eign ad­ver­sary op­er­at­ing with in­tent could ob­serve far more.Flock Safety did not merely leak an API key. They ex­posed the op­er­a­tional heart­beat of the na­tion, and they did so re­peat­edly, across 53 sep­a­rate in­stances.That re­al­ity should con­cern every­one.In­for­ma­tion is lever­age and we move the ful­crum. We can help you:Shape the iden­tity you want the world to see­Leave it to us to se­cure

The world’s lead­ing All-Source Intelligence Firm for Cybersecurity and Privacy

To use the Mastodon web ap­pli­ca­tion, please en­able JavaScript. Alternatively, try one of the na­tive apps for Mastodon for your plat­form.

The al­pha stage is an early, un­sta­ble ver­sion meant pri­mar­ily for test­ing.

* Demonstrated ba­sic web­site nav­i­ga­tion func­tion­al­ity, sup­port­ing es­sen­tials like the home­page, tabs, and sim­ple searches

* Advanced tab man­age­ment is now com­plete, with the ex­cep­tion of the Tab Switcher UI, which is not sup­ported yet.

* Tabs now func­tion in­de­pen­dently and can be opened in par­al­lel

* Session per­sis­tence is im­ple­mented: pre­vi­ously opened tabs, along with their his­tory, will re­open when the ap­pli­ca­tion is launched again.

* Tabs cur­rently ap­pear in the main win­dow and are sup­ported in the left side­bar as well.

* Bookmarks sys­tem a sim­ple book­mark fea­ture is now avail­able.

* Users can save pages, or­ga­nize them into fold­ers

* Users can view them in the book­marks di­a­log, side­bar, and book­marks bar.

* Password man­age­ment frame­work es­tab­lishes the core in­fra­struc­ture needed for se­cure pass­word han­dling and fu­ture im­prove­ments in this area.

The New York Times has frame-by-frame analy­sis, from three an­gles, of the mur­der of 37-year-old Renee Good in Minneapolis yes­ter­day. She was shot to death by mask-wear­ing ICE agent Jonathan Ross, with what was ob­vi­ously no jus­ti­fi­ca­tion. The shoot­ing is, jus­ti­fi­ably, na­tional news. I’m sure you’ve read about it. But this Times analy­sis coolly and calmly shows just how out­ra­geous it was, and how pre­pos­ter­ous the claims from President Trump and Secretary of Hats Kristi Noem are os­ten­si­bly at­tempt­ing to de­fend it — both as an act of self-de­fense by the cow­ardly ICE agent and, even more ab­surdly, as an act of “domestic ter­ror­ism” by Good, who was at­tempt­ing to do noth­ing more than drive away from the scene.

George Orwell, in 1984: “The Party told you to re­ject the ev­i­dence of your eyes and ears. It was their fi­nal, most es­sen­tial com­mand.” Let’s stop pussy­foot­ing around what hap­pened here. This ICE agent mur­dered Renee Good, in broad day­light, in front of many wit­nesses and mul­ti­ple cam­eras. Trust the ev­i­dence of your eyes and ears.

But I want to add an­other note. The main footage here comes from by­stander Caitlin Callenson. Here’s her full 4m:25s footage, un­cen­sored, hosted — with credit, and I hope, per­mis­sion — on the YouTube ac­count of Minnesota Reformer. Be warned that it shows Good be­ing shot to death (albeit sans gore), and con­tains many loud pro­fan­i­ties. This is very good and clear footage. It is dif­fi­cult view­ing but you should watch it. Callenson was very close to Good’s ve­hi­cle. I’d say about 30 feet or so. You can see why she thought to start film­ing be­fore the mur­der­ous agent drew his gun and fired. The scene was al­ready chaotic. But then, af­ter the mur­der­ous agent fired three shots — just 30 or 40 feet in front of Callenson — Callenson had the courage and con­vic­tion to stay with the scene and keep film­ing. Not to run away, but in­stead to fol­low the scene. To keep film­ing. To con­tinue doc­u­ment­ing with as best clar­ity as she could, what was un­fold­ing.

I’d like to think I’d have done the same. I’m not sure at all that I would have. I def­i­nitely might have been us­ing my iPhone to shoot video of the in­ci­dent up un­til the shots were fired. But when that hap­pened, my mind would im­me­di­ately have turned to “These agents are scared and an­gry and out of con­trol, and that one just went psy­cho and fired his gun un­pro­voked. That guy is just as likely to shoot more peo­ple as he was the woman he just shot. His an­gry, scared, ob­vi­ously un­der­trained col­leagues might join in. And the most likely peo­ple they’ll shoot next are peo­ple point­ing cam­eras at them.” I do not know what I would have done in that mo­ment. I hope I never find out. But I know with cer­tainty what I would im­me­di­ately think, which is that if I choose to con­tinue shoot­ing video of the in­ci­dent, there is a very good chance one of them will shoot or bru­tal­ize me next. It would make more sense to shoot some­one film­ing the scene than it did to shoot Renee Good in the first place. Good’s killing was ut­terly sense­less. Shooting a wit­ness with a run­ning cam­era and then de­stroy­ing their phone to elim­i­nate the ev­i­dence (and a wit­ness) would make some sense. Sick sense, but sense.

But in that mo­ment of pan­de­mo­nium and ob­vi­ous dan­ger to her­self, Callenson did­n’t merely con­tinue film­ing. She did­n’t merely stand her ground. She pro­ceeded into the scene to get closer to Good’s ve­hi­cle af­ter it crashed into a parked car, Mr. Brown-style. She pointed her cam­era di­rectly at the only-par­tially-masked face of the mur­der­ous agent as he walked away from Good’s crashed ve­hi­cle, then got into an un­marked Chevy Tahoe and just fled from the scene like the ob­vi­ous cow­ard he is. I pre­sume the mur­der­ous agent will soon be iden­ti­fied, and Callenson’s clear steady-handed footage may be the rea­son why. [Update: While I was fin­ish­ing this post, the Minnesota Star Tribune iden­ti­fied and named him — Jonathan Ross — and in­deed, it was Callenson’s footage that made his iden­ti­fi­ca­tion pos­si­ble.] And, to top it off, all the while — start­ing be­fore the shoot­ing — Cal­len­son was scream­ing “Shame!” in the faces of these agents, and call­ing them out on their ab­hor­rent in­de­fen­si­ble ac­tions. To each of their di­rec­tives to her, she re­sponds, with the de­f­i­n­i­tion of right­eous anger, “You shot some­one in the fuck­ing face!” (Emily Heller, Renee Good’s neigh­bor, showed sim­i­lar courage, telling an ICE agent who re­fused to al­low a cit­i­zen physi­cian to check on Good (who laid dy­ing or dead in­side her car), as she filmed the scene, “How can I re­lax, you just killed my fuck­ing neigh­bor! You shot her in the fuck­ing face! You killed my fuck­ing neigh­bor! How do you show up to work every day?”)

Callenson’s courage in the face of ob­vi­ous dan­ger is just re­mark­able. My god. She rose to the mo­ment in a cru­cible of chaos, in­san­ity, and mur­der­ous vi­o­lence. We all need to think about what she did, to re­ally imag­ine our­selves in the same mo­ment — the dan­ger she stood up to, and the prin­ci­ples she stood up for — if we hope to do the same if a sim­i­lar mo­ment comes to us.

And, to top it off, she had the pres­ence of mind to shoot her his­toric footage in widescreen.

On every WebAssembly dis­cus­sion, there is in­evitably one com­ment (often near the top) ask­ing what hap­pened.

It seems to have been ad­ver­tised as a world-chang­ing ad­vance­ment. Was it just over­sold? Was it an­other JVM ap­plet sce­nario, doomed to fail?

I’d like to tackle this in a weirdly round­about way be­cause I think these sorts of ques­tions make a few mis­placed as­sump­tions that are crit­i­cal to clar­ify.

Of course, WebAssembly does see real-world us­age. Let’s list some ex­am­ples!

For many of these, WebAssembly is crit­i­cal to ei­ther their en­tire prod­uct or a ma­jor fea­ture.

But I think this alone is not very con­vinc­ing. We don’t yet see ma­jor web­sites en­tirely built with we­bassem­bly-based frame­works. We’re not build­ing our ap­pli­ca­tions di­rectly to WebAssembly for max­i­mum porta­bil­ity. But why not?

To an­swer this, we need a good men­tal model for what WebAssembly is. This will help us qual­ify where it is most im­pact­ful and the lim­i­ta­tions we’re up against.

This makes ques­tions like “how fast is WebAssembly” a bit hard to an­swer. You don’t ask how fast al­ge­braic no­ta­tion is—it’s not a very sen­si­ble ques­tion.

Taken in the con­text of some­thing like JavaScript, the lan­guage is only as fast as the en­gine run­ning it. JavaScript the lan­guage has no speed, but you can bench­mark JS en­gines like V8, SpiderMonkey, and JavaScriptCore. You can bench­mark the IO li­braries of JS run­times like Bun, Deno, and Node.

What peo­ple ac­tu­ally mean is “how use­ful are the con­structs of this lan­guage to ef­fi­cient map­pings of mod­ern hard­ware” and “what is the cur­rent land­scape of sys­tems tak­ing ad­van­tage of these con­structs”.

Through clever-enough en­gi­neer­ing, you can make any sys­tem suf­fi­ciently fast with some trade-offs. If com­pil­ing your code di­rectly to C does­n’t bother you, get­ting “near na­tive” speeds is pos­si­ble in both JavaScript and WebAssembly.

That’s right, you can com­pile WebAssembly! You can also choose to in­ter­pret it di­rectly—that’ll be up to your run­time, just like every other sys­tem.

So let’s ask the ac­tual ques­tion of WebAssembly: how use­ful are the con­structs of this lan­guage to ef­fi­cient map­pings of mod­ern hard­ware? Turns out, pretty use­ful!

WebAssembly is a pretty close ap­prox­i­ma­tion of an as­sem­bly lan­guage. Not too close, mind you. It’s higher level than that. But it’s close enough to cleanly com­pile to most as­sem­bly lan­guages with­out a sig­nif­i­cant speed trade-off.

And yes, you can write WebAssembly by hand! I made a rustlings-es­que course called watlings where you can hand-write WAT to solve some ba­sic ex­er­cises.

WAT is a very close ap­prox­i­ma­tion to Wasm. It is al­most 1:1 in that you can com­pile WAT to Wasm and then back to WAT with barely any loss in in­for­ma­tion (you may lose vari­able names and some meta­data). It looks like this:

Try read­ing the code. It will feel both fa­mil­iar and for­eign.

We have func­tions and S-expressions. We have im­ports and ex­ports. But we also have in­struc­tions like i32.add and im­plicit stack re­turns.

Wasm is a byte­code per­haps best com­pared to JVMIS (i.e. JVM byte­code). They have sim­i­lar goals and con­straints, but dif­fer­ent land­scapes and guar­an­tees.

Compared to JVM byte­code, Wasm has a sig­nif­i­cantly smaller API and stronger safety guar­an­tees. It has fewer opin­ions on your mem­ory man­age­ment strat­egy and more lim­i­ta­tions on what your pro­gram can do with­out per­mis­sion from its host en­vi­ron­ment.

It can crunch num­bers, but must be ex­plic­itly pro­vided its mem­ory and all im­ports. In this way, it is much dif­fer­ent from an ac­tual as­sem­bly lan­guage (or, a more widely used one).

We’ll wrap back around to this later.

You can com­pile many lan­guages to Wasm.

Notable among them are Rust, C, Zig, Go, Kotlin, Java, and C#. Commonly in­ter­preted lan­guages have even had their run­times com­piled to WebAssembly, such as Python, PHP, and Ruby. There are also many lan­guages that solely com­pile to WebAssembly, such as AssemblyScript, Grain, and MoonBit.

For many of these, it is im­por­tant not to re­quire a garbage-col­lec­tor. For oth­ers, it would be help­ful to in­clude one. Wasm al­lows for both (with the GC op­tion be­ing much more re­cent).

Your browser in­cludes a Wasm “engine”, mak­ing this dou­bly an at­trac­tive com­pi­la­tion tar­get. This means with­out much setup, your phone and lap­top can run Wasm pro­grams al­ready.

Like how JVM can have many im­ple­men­ta­tions of its run­ner, there are many im­ple­men­ta­tions that run in­de­pen­dently of your browser such as Wasmtime, WasmEdge, and Wasmer.

These lan­guages can out­put a sin­gle ar­ti­fact with­out be­ing too spe­cific to your com­put­er’s hard­ware. You only need a Wasm run­ner to ex­e­cute it (note more JVM analo­gies).

Right now, Wasm is look­ing re­ally sim­i­lar to JVM. The main dif­fer­ences seem to be around mem­ory man­age­ment strate­gies and how many plat­forms sup­port it.

The se­cu­rity story is what re­ally starts to drive in the wedge.

WebAssembly main­tains a min­i­mal at­tack sur­face by treat­ing all ex­ter­nal in­ter­ac­tions as ex­plicit, host-de­fined im­ports. We went over this ear­lier. Its “deny-by-default” ar­chi­tec­ture, small in­struc­tion set, hid­den con­trol-flow stack (i.e. no raw point­ers), and lin­ear mem­ory com­bine to cre­ate a very strong se­cu­rity story.

It is such that you can en­sure process-like iso­la­tion within a sin­gle process. Cloudflare takes ad­van­tage of this as­pect within V8 to run un­trusted code very ef­fi­ciently us­ing V8 iso­lates. This means sig­nif­i­cant ef­fi­ciency gains with­out sig­nif­i­cant se­cu­rity trade-offs.

Wasm pro­grams can start 100x faster if you can avoid spin­ning up a sep­a­rate process. Fermyon, a com­pany in the Wasm host­ing space, ad­ver­tises sub-mil­lisec­ond spinup times.

In these cases, the per­for­mance is a di­rect re­sult of what the se­cu­rity guar­an­tees en­able.

In other cases, se­cu­rity can un­lock fea­ture sup­port.

Flash is a mul­ti­me­dia plat­form that was pri­mar­ily used for an­i­ma­tions and games up un­til it was dropped from all ma­jor browsers in January of 2021 (primarily) due to se­cu­rity con­cerns. Ruffle has re­vived Flash ex­pe­ri­ences on sites like Newgrounds by act­ing as an in­ter­preter and VM for ActionScript.

Cloudflare al­lows run­ning Python code with sim­i­lar se­cu­rity guar­an­tees to its JS code by us­ing Pyodide, which is a Wasm build of CPython.

Figma runs un­trusted user plu­g­ins in your browser by run­ning them in a QuickJS en­gine that is com­piled to Wasm.

Elsewhere, the se­cu­rity al­lows for ex­treme em­bed­d­a­bil­ity.

We’ve gone over the num­ber of ways you can run Wasm pro­grams. A Wasm run­ner can be pretty light. Instead of forc­ing li­brary au­thors into a spe­cific lan­guage (usually Lua or JavaScript), sup­port­ing Wasm it­self opens the door to a much wider set of choices.

Tools like Zellij, Envoy, and Lapce sup­port Wasm for their plu­gin ecosys­tem.

In en­vi­ron­ments where a JavaScript en­gine is al­ready be­ing used, this means ac­cess to pro­grams you would not have been able to run oth­er­wise.

This in­cludes im­age pro­cess­ing, ocr, physics en­gines, ren­der­ing en­gines, me­dia toolk­its, data­bases, and parsers, among many oth­ers.

In a ma­jor­ity of these cases, the use of Wasm will be trans­par­ent to you. A li­brary you in­stalled will just be us­ing it some­where in its de­pen­dency tree.

Godot and Figma have code­bases writ­ten in C++, but are of­ten browser-ready by com­pil­ing to (or in com­bi­na­tion with) WebAssembly.

It seems the most com­mon use of Wasm is bridg­ing the lan­guage gap. Certain ecosys­tems seem to have suites of tools more com­mon to them. Squoosh would be a much more lim­ited ap­pli­ca­tion if it could only choose im­age com­pres­sion li­braries from NPM.

Browsers run WebAssembly with roughly the same pipeline that runs JavaScript. This seem­ingly puts a hard limit on the per­for­mance of Wasm ap­pli­ca­tions, but they will of­ten be more or less per­for­mant due to their ar­chi­tec­ture or do­main.

Using lan­guages with richer type sys­tems and more so­phis­ti­cated op­ti­miz­ing com­pil­ers can pro­duce more ef­fi­cient pro­grams. The JIT model of en­gines like V8 might pre­vent op­ti­miza­tions if the cost of op­ti­miz­ing ex­ceeds the gains from run­ning the op­ti­mized code. You might avoid meg­amor­phic func­tions more eas­ily by avoid­ing JavaScript.

However, there is a cost to cross­ing the host-pro­gram bound­ary, es­pe­cially if cloning mem­ory. Zaplib’s post-mortem is an in­ter­est­ing read here. Incrementally mov­ing a code­base to Wasm can in­cur sig­nif­i­cant costs in bound­ary cross­ing, elim­i­nat­ing any ben­e­fit in the short term.

A small API sur­face also means bi­nary bloat as sys­tem APIs are more of­ten re-cre­ated than im­ported. There are stan­dards like WASI which aim to help here. Still, there is no na­tive string type (yet).

Zig seems to pro­duce the small­est Wasm bi­na­ries among main­stream lan­guages.

Practical per­for­mance of Wasm in na­tive con­texts (i.e. out­side of a JS en­gine) seems to suf­fer for a va­ri­ety of rea­sons. Threading and IO of any sort in­curs some cost. Memory us­age is larger. Cold start is slower.

Still, the per­for­mance trade-offs might not be sig­nif­i­cant enough to mat­ter. For most uses, I’d wa­ger it’s “fast enough”. If you’re in a per­for­mance-sen­si­tive con­text, the ben­e­fits of Wasm are likely not as rel­e­vant.

The Wasm IO YouTube chan­nel has lots of talks worth watch­ing.

In fact, stan­dards and lan­guage de­vel­op­ment in Wasm has stirred sig­nif­i­cant con­tro­versy in­ter­nally. There is a lot of de­sire for ad­vance­ment, but stan­dard­iza­tion means de­ci­sions are hard to re­verse. For many, things are mov­ing too quickly and in the wrong di­rec­tion.

There is the “more of­fi­cial” W3C work­ing group and then the “less of­fi­cial” Bytecode Alliance which works much more quickly and is cen­tered around tool­ing and lan­guage de­vel­op­ment out­side of Wasm di­rectly (e.g. on WIT and the WebAssembly Component Model).

Wasm fea­ture pro­pos­als are be­ing quickly ad­vanced and adopted by a wide suite of tools. This is re­mark­able progress for stan­dard­iza­tion, but is also scary to watch if you fear large mis­steps.

So why do peo­ple think noth­ing has hap­pened?

I fig­ure most are un­der the im­pres­sion that the ad­vance­ment of this tech­nol­ogy would have had a more vis­i­ble im­pact on their work. That they would in­ten­tion­ally reach for and use Wasm tools.

Many seem to think there is a path to Wasm re­plac­ing JavaScript within the browser—that they might not need to in­clude a .js file at all. This is very un­likely.

However, you can use frame­works like Blazor and Leptos with­out be­ing aware or in­volved in the pro­duced JS ar­ti­facts.

Mostly, Wasm tools have been adopted and used by li­brary au­thors, not ap­pli­ca­tion de­vel­op­ers. The in­ter­nals are opaque. This is fine, prob­a­bly.

Separately, I think the com­mu­nity is not helped by the phi­los­o­phy of pur­posely ob­fus­cat­ing teach­ing ma­te­r­ial around Wasm. This is a fight I lost a few times.

For now, maybe check out watlings. I’ll ex­pand it at some point, surely.

Regular phys­i­cal ac­tiv­ity may ease symp­toms of de­pres­sion about as ef­fec­tively as psy­cho­log­i­cal ther­apy, ac­cord­ing to an up­dated Cochrane re­view. When re­searchers com­pared ex­er­cise with an­ti­de­pres­sant med­ica­tion, they found sim­i­lar ben­e­fits, al­though the cer­tainty of that ev­i­dence was lower.

Regular phys­i­cal ac­tiv­ity may ease symp­toms of de­pres­sion about as ef­fec­tively as psy­cho­log­i­cal ther­apy, ac­cord­ing to an up­dated Cochrane re­view. When re­searchers com­pared ex­er­cise with an­ti­de­pres­sant med­ica­tion, they found sim­i­lar ben­e­fits, al­though the cer­tainty of that ev­i­dence was lower.

Depression re­mains a ma­jor global health chal­lenge, af­fect­ing more than 280 mil­lion peo­ple world­wide and con­tribut­ing sig­nif­i­cantly to dis­abil­ity. Exercise stands out as a low cost and widely ac­ces­si­ble op­tion that also im­proves phys­i­cal health, mak­ing it ap­peal­ing to both pa­tients and health­care pro­fes­sion­als.

The analy­sis was led by re­searchers at the University of Lancashire and drew on data from 73 ran­dom­ized con­trolled tri­als in­volv­ing nearly 5,000 adults di­ag­nosed with de­pres­sion. These stud­ies ex­am­ined how ex­er­cise com­pared with no treat­ment or con­trol con­di­tions, as well as with psy­cho­log­i­cal ther­a­pies and an­ti­de­pres­sant drugs.

Overall, the find­ings showed that ex­er­cise led to mod­er­ate re­duc­tions in de­pres­sive symp­toms com­pared with no treat­ment. When mea­sured against psy­cho­log­i­cal ther­apy, ex­er­cise pro­duced sim­i­lar im­prove­ments, based on mod­er­ate cer­tainty ev­i­dence from ten tri­als. Comparisons with an­ti­de­pres­sant med­ica­tion also sug­gested com­pa­ra­ble ef­fects, but the sup­port­ing ev­i­dence was lim­ited and con­sid­ered low cer­tainty. Few stud­ies tracked par­tic­i­pants af­ter treat­ment ended, leav­ing the long-term im­pact un­clear.

Reported side ef­fects were un­com­mon. People in ex­er­cise pro­grams oc­ca­sion­ally ex­pe­ri­enced mus­cle or joint in­juries, while those tak­ing an­ti­de­pres­sants re­ported typ­i­cal med­ica­tion-re­lated is­sues such as fa­tigue and gas­troin­testi­nal prob­lems.

“Our find­ings sug­gest that ex­er­cise ap­pears to be a safe and ac­ces­si­ble op­tion for help­ing to man­age symp­toms of de­pres­sion,” said Professor Andrew Clegg, lead au­thor of the re­view. “This sug­gests that ex­er­cise works well for some peo­ple, but not for every­one, and find­ing ap­proaches that in­di­vid­u­als are will­ing and able to main­tain is im­por­tant.”

What Kind of Exercise Works Best

The re­view found that light to mod­er­ate in­ten­sity ac­tiv­ity may be more help­ful than vig­or­ous work­outs. Greater im­prove­ments in de­pres­sive symp­toms were linked to com­plet­ing be­tween 13 and 36 ex­er­cise ses­sions.

No sin­gle form of ex­er­cise clearly out­per­formed oth­ers. However, pro­grams that com­bined dif­fer­ent types of ac­tiv­ity and re­sis­tance train­ing ap­peared more ef­fec­tive than aer­o­bic ex­er­cise alone. Some ac­tiv­i­ties, in­clud­ing yoga, qigong and stretch­ing, were not eval­u­ated in this analy­sis and re­main ar­eas for fu­ture study. As with other find­ings, long-term ben­e­fits are still un­cer­tain due to lim­ited fol­low-up.

This up­date added 35 new tri­als to ear­lier ver­sions of the re­view pub­lished in 2008 and 2013. Even with the ex­panded ev­i­dence base, the main con­clu­sions changed lit­tle. Many of the in­cluded stud­ies were small, of­ten in­volv­ing fewer than 100 par­tic­i­pants, which makes it harder to draw firm con­clu­sions.

“Although we’ve added more tri­als in this up­date, the find­ings are sim­i­lar,” said Professor Clegg. “Exercise can help peo­ple with de­pres­sion, but if we want to find which types work best, for who and whether the ben­e­fits last over time, we still need larger, high-qual­ity stud­ies. One large, well-con­ducted trial is much bet­ter than nu­mer­ous poor qual­ity small tri­als with lim­ited num­bers of par­tic­i­pants in each.”

Please log in (or reg­is­ter) to post as a new dweet (copy-paste code some­where safe to save it mean­while).