Android has al­ways been a fairly open plat­form, es­pe­cially if you were de­lib­er­ate about get­ting it that way, but we’ve seen in re­cent months an ex­tremely rapid de­vo­lu­tion of the Android ecosys­tem:

The clos­ing of de­vel­op­ment of an in­creas­ing num­ber of com­po­nents in AOSP.

Samsung, Xiaomi and OnePlus have re­moved the op­tion of boot­loader un­lock­ing on all of their de­vices. I sus­pect Google is not far be­hind.

Google im­ple­ment­ing Play Integrity API and en­cour­ag­ing de­vel­op­ers to im­ple­ment it. Notably the EU’s own iden­tity ver­i­fi­ca­tion wal­let re­quires this, in stark con­trast to their own laws and poli­cies, de­spite the protest of hun­dreds on Github.

And fi­nally, the manda­tory im­ple­men­ta­tion of de­vel­oper ver­i­fi­ca­tion across Android sys­tems. Yes, if you’re run­ning a 3rd-party OS like GOS you won’t be di­rectly af­fected by this, but it will im­pact 99.9% of de­vices, and I fore­see many open source de­vel­op­ers just opt­ing out of de­vel­op­ing apps for Android en­tirely as a re­sult. We’ve al­ready seen SyncThing sim­ply dis­con­tinue de­vel­op­ment for this rea­son, cit­ing is­sues with Google Play Store. They’ve also re­peat­edly de­nied up­dates for NextCloud with no ex­pla­na­tion, only restor­ing it af­ter mass out­cry. And we’ve al­ready seen Google tar­get­ing any soft­ware in­tended to cir­cum­vent ads, la­bel­ing them in the sys­tem as “dangerous” and “untrusted”. This will most cer­tainly carry into their new “verification” sys­tem.

Google once com­peted with Apple for cus­tomers. But in a world where Google walks away from the biggest an­titrust trial since 1998 with yet an­other slap on the wrist, com­pe­ti­tion is dead, and Google is tak­ing notes from Apple about what they can legally get away with.

Android as we know it is dead. And/or will be dead very soon. We need an open re­place­ment.

React-by-default has hid­den costs. Here’s a case for mak­ing de­lib­er­ate choices to se­lect the right frame­work for the job.

React-by-default has hid­den costs. Here’s a case for mak­ing de­lib­er­ate choices to se­lect the right frame­work for the job.

React is no longer win­ning by tech­ni­cal merit. Today it is win­ning by de­fault. That de­fault is now slow­ing in­no­va­tion across the fron­tend ecosys­tem.

When teams need a new fron­tend, the con­ver­sa­tion rarely starts with “What are the con­straints and which tool best fits them?” It of­ten starts with “Let’s use React; every­one knows React.” That re­flex cre­ates a self-per­pet­u­at­ing cy­cle where net­work ef­fects, rather than tech­ni­cal fit, de­cide ar­chi­tec­ture.

Meanwhile, frame­works with real in­no­va­tions strug­gle for adop­tion. Svelte com­piles away frame­work over­head. Solid de­liv­ers fine-grained re­ac­tiv­ity with­out vir­tual-DOM tax. Qwik achieves in­stant startup via re­sum­a­bil­ity. These ap­proaches can out­per­form React’s model in com­mon sce­nar­ios, but they rarely get a fair eval­u­a­tion be­cause React is cho­sen by de­fault.

React is ex­cel­lent at many things. The prob­lem is­n’t React it­self, it’s the React-by-default mind­set.

React’s tech­ni­cal foun­da­tions ex­plain some of to­day’s fric­tion. The vir­tual DOM was a clever so­lu­tion for 2013’s prob­lems, but as Rich Harris out­lined in “Virtual DOM is pure over­head”, it in­tro­duces work mod­ern com­pil­ers can of­ten avoid.

Hooks ad­dressed class com­po­nent pain but in­tro­duced new kinds of com­plex­ity: de­pen­dency ar­rays, stale clo­sures, and mis­used ef­fects. Even React’s own docs em­pha­size re­straint: “You Might Not Need an Effect”. Server Components im­prove time-to-first-byte, but add ar­chi­tec­tural com­plex­ity and new fail­ure modes.

The React Compiler is a smart so­lu­tion that au­to­mates pat­terns like use­Memo/​use­Call­back. Its ex­is­tence is also a sig­nal: we’re op­ti­miz­ing around con­straints baked into the model.

Contrast this with al­ter­na­tive ap­proaches: Svelte 5’s Runes sim­plify re­ac­tiv­ity at com­pile time; Solid’s fine-grained re­ac­tiv­ity up­dates ex­actly what changed; Qwik’s re­sum­a­bil­ity elim­i­nates tra­di­tional hy­dra­tion. These aren’t in­cre­men­tal tweaks to React’s model—they’re dif­fer­ent mod­els with dif­fer­ent ceil­ings.

Innovation with­out adop­tion does­n’t change out­comes. Adoption can’t hap­pen when the choice is made by re­flex.

Defaulting to React of­ten ships a run­time and rec­on­cil­i­a­tion cost we no longer ques­tion. Even when it’s fast enough, the ceil­ing is lower than com­pile-time or fine-grained mod­els. Developer time is spent man­ag­ing re-ren­ders, ef­fect de­pen­den­cies, and hy­dra­tion bound­aries in­stead of ship­ping value. The broader les­son from per­for­mance re­search is con­sis­tent: JavaScript is ex­pen­sive on the crit­i­cal path (The Cost of JavaScript).

We’ve cen­tered men­tal mod­els around “React pat­terns” in­stead of web fun­da­men­tals, re­duc­ing porta­bil­ity of skills and mak­ing ar­chi­tec­tural in­er­tia more likely.

The loss is­n’t just per­for­mance, it’s op­por­tu­nity cost when bet­ter-fit al­ter­na­tives are never eval­u­ated. For in­stance, bench­marks like the JS Framework Benchmark show al­ter­na­tives like Solid achiev­ing up to 2-3x faster up­dates in re­ac­tiv­ity-heavy sce­nar­ios com­pared to React.

Svelte shifts work to com­pile time: no vir­tual DOM, min­i­mal run­time. Components be­come tar­geted DOM op­er­a­tions. The men­tal model aligns with web fun­da­men­tals.

But “not enough jobs” keeps Svelte adop­tion ar­ti­fi­cially low de­spite its tech­ni­cal su­pe­ri­or­ity for most use cases. Real-world ex­am­ples, like The Guardian’s adop­tion of Svelte for their fron­tend, demon­strate mea­sur­able gains in per­for­mance and de­vel­oper pro­duc­tiv­ity, with re­ported re­duc­tions in bun­dle sizes and faster load times. For in­stance, as de­tailed in Wired’s ar­ti­cle on Svelte, de­vel­oper Shawn Wang (@swyx on X/Twitter) re­duced his site’s size from 187KB in React to just 9KB in Svelte by lever­ag­ing its com­pile-time op­ti­miza­tions, which shift frame­work over­head away from run­time. This leads to faster, more ef­fi­cient apps es­pe­cially on slow con­nec­tions.

Solid de­liv­ers fine-grained re­ac­tiv­ity with JSX fa­mil­iar­ity. Updates flow through sig­nals di­rectly to af­fected DOM nodes, by­pass­ing rec­on­cil­i­a­tion bot­tle­necks. Strong per­for­mance char­ac­ter­is­tics, lim­ited mind­share. As out­lined in Solid’s com­par­i­son guide, this ap­proach en­ables more ef­fi­cient up­dates than React’s vir­tual DOM, with pre­cise re­ac­tiv­ity that min­i­mizes un­nec­es­sary work and im­proves de­vel­oper ex­pe­ri­ence through sim­pler state man­age­ment.

While promi­nent case stud­ies are scarcer than for more es­tab­lished frame­works, this is largely due to Solid’s lower adop­tion. Yet anec­do­tal re­ports from early adopters sug­gest sim­i­lar trans­for­ma­tive gains in up­date ef­fi­ciency and code sim­plic­ity, wait­ing to be scaled and shared as more teams ex­per­i­ment.

Qwik uses re­sum­a­bil­ity in­stead of hy­dra­tion, en­abling in­stant startup by load­ing only what the cur­rent in­ter­ac­tion needs. Ideal for large sites, long ses­sions, or slow net­works. According to Qwik’s Think Qwik guide, this is achieved through pro­gres­sive load­ing and se­ri­al­iz­ing both state and code. Apps can thus re­sume ex­e­cu­tion in­stantly with­out heavy client-side boot­strap­ping, re­sult­ing in su­pe­rior scal­a­bil­ity and re­duced ini­tial load times com­pared to tra­di­tional frame­works.

Success sto­ries for Qwik may be less vis­i­ble sim­ply be­cause fewer teams have bro­ken from de­faults to try it. But those who have re­port dra­matic im­prove­ments in startup times and re­source ef­fi­ciency, in­di­cat­ing a wealth of un­tapped po­ten­tial if adop­tion grows.

All three un­der-adopted not for lack of merit, but be­cause the de­fault choice blocks try­ing them out.

Furthermore, React’s API sur­face area is no­tably larger and more com­plex than its al­ter­na­tives, en­com­pass­ing con­cepts like hooks, con­text, re­duc­ers, and mem­o­iza­tion pat­terns that re­quire care­ful man­age­ment to avoid pit­falls. This ex­pan­sive API con­tributes to higher cog­ni­tive load for de­vel­op­ers, of­ten lead­ing to bugs from mis­un­der­stood de­pen­den­cies or over-en­gi­neer­ing. For ex­am­ple, in Cloudflare’s September 12, 2025 out­age, a use­Ef­fect hook with a prob­lem­atic de­pen­dency ar­ray trig­gered re­peated API calls, over­whelm­ing their Tenant Service and caus­ing wide­spread fail­ures. In con­trast, frame­works like Svelte, Solid, and Qwik fea­ture smaller, more fo­cused APIs that em­pha­size sim­plic­ity and web fun­da­men­tals, re­duc­ing the men­tal over­head and mak­ing them eas­ier to mas­ter and main­tain.

React’s dom­i­nance cre­ates self-re­in­forc­ing bar­ri­ers. Job post­ings ask for “React de­vel­op­ers” rather than “frontend en­gi­neers,” lim­it­ing skill di­ver­sity. Component li­braries and team mus­cle mem­ory cre­ate in­sti­tu­tional in­er­tia.

Risk-averse lead­ers choose the “safe” op­tion. Schools teach what jobs ask for. The cy­cle con­tin­ues in­de­pen­dent of tech­ni­cal merit.

Escaping re­quires de­lib­er­ate ac­tion at mul­ti­ple lev­els. Technical lead­ers should choose based on con­straints and mer­its, not mo­men­tum. Companies can al­lo­cate a small in­no­va­tion bud­get to try­ing al­ter­na­tives. Developers can up­skill be­yond a sin­gle men­tal model.

Educators can teach frame­work-ag­nos­tic con­cepts along­side spe­cific tools. Open source con­trib­u­tors can help al­ter­na­tive ecosys­tems ma­ture.

To make de­lib­er­ate choices, use this sim­ple check­list when start­ing a new pro­ject:

* Assess Performance Needs: Evaluate met­rics like startup time, up­date ef­fi­ciency, and bun­dle size. Prioritize frame­works with com­pile-time op­ti­miza­tions if speed is crit­i­cal.

* Team Skills and Learning Curve: Consider ex­ist­ing ex­per­tise but fac­tor in mi­gra­tion paths; many al­ter­na­tives of­fer gen­tle ramps (e.g., Solid’s JSX com­pat­i­bil­ity with React).

* Scaling and Cost of Ownership: Calculate long-term costs, in­clud­ing main­te­nance, de­pen­dency man­age­ment, and tech debt. Alternatives of­ten re­duce run­time over­head, low­er­ing host­ing costs and im­prov­ing scal­a­bil­ity.

* Ecosystem Fit: Balance ma­tu­rity with in­no­va­tion; pi­lot in non-crit­i­cal ar­eas to test mi­gra­tion fea­si­bil­ity and ROI.

“But ecosys­tem ma­tu­rity!” Maturity is valu­able, and can also en­trench in­er­tia. Age is­n’t the same as fit­ness for to­day’s con­straints.

Additionally, a ma­ture ecosys­tem of­ten means heavy re­liance on third-party pack­ages, which can in­tro­duce main­te­nance bur­dens like keep­ing de­pen­den­cies up-to-date, deal­ing with se­cu­rity vul­ner­a­bil­i­ties, and bloat­ing bun­dles with un­used code. While es­sen­tial in some cases, this flex­i­bil­ity can lead to over-de­pen­dence; cus­tom so­lu­tions tai­lored to spe­cific needs are of­ten leaner and more main­tain­able in the long run. Smaller ecosys­tems in al­ter­na­tive frame­works en­cour­age build­ing from fun­da­men­tals, fos­ter­ing deeper un­der­stand­ing and less tech­ni­cal debt. Moreover, with AI cod­ing as­sis­tants now able to gen­er­ate pre­cise, cus­tom func­tions on de­mand, the bar­rier to cre­at­ing be­spoke util­i­ties has low­ered dra­mat­i­cally. This makes it fea­si­ble to avoid generic li­braries like lo­dash or date li­braries like Moment or date-fns en­tirely in fa­vor of light­weight, app-spe­cific im­ple­men­ta­tions.

“But hir­ing!” Hiring fol­lows de­mand. You can de‑risk by pi­lot­ing al­ter­na­tives in non‑crit­i­cal paths, then hir­ing for fun­da­men­tals plus on‑the‑job train­ing.

“But sta­bil­ity!” React’s evo­lu­tion from classes to hooks to Server Components demon­strates con­stant churn, not sta­bil­ity. Alternative frame­works of­ten pro­vide more con­sis­tent APIs.

“But proven at scale!” jQuery was proven at scale too. Past suc­cess does­n’t guar­an­tee fu­ture rel­e­vance.

Monoculture slows web evo­lu­tion when one frame­work’s con­straints be­come de facto lim­its. Talent spends cy­cles solv­ing frame­work-spe­cific is­sues rather than push­ing the plat­form for­ward. Investment fol­lows in­cum­bents re­gard­less of tech­ni­cal merit.

Curricula op­ti­mize for im­me­di­ate em­ploy­a­bil­ity over fun­da­men­tals, cre­at­ing frame­work-spe­cific rather than trans­fer­able skills. Platform im­prove­ments get de­layed be­cause “React can han­dle it” be­comes a de­fault an­swer.

Healthy ecosys­tems re­quire di­ver­sity, not mono­cul­tures. Innovation emerges when dif­fer­ent ap­proaches com­pete and cross-pol­li­nate. Developers grow by learn­ing mul­ti­ple men­tal mod­els. The plat­form im­proves when sev­eral frame­works push dif­fer­ent bound­aries.

Betting every­thing on one model cre­ates a sin­gle point of fail­ure. What hap­pens if it hits hard lim­its? What op­por­tu­ni­ties are we miss­ing by not ex­plor­ing al­ter­na­tives?

It’s time to choose frame­works based on con­straints and merit rather than mo­men­tum. Your next pro­ject de­serves bet­ter than React-by-default. The ecosys­tem de­serves the in­no­va­tion only di­ver­sity can pro­vide.

Stop plant­ing the same seed by de­fault. The gar­den we could cul­ti­vate through di­verse frame­work ex­plo­ration would be more re­silient and more in­no­v­a­tive than the mono­cul­ture we’ve drifted into.

The choice is ours to make.

A new de­sign with Liquid Glass. Beautiful, de­light­ful, and in­stantly fa­mil­iar.

Now with the Phone app and Live Activities from iPhone for next‑level Con­ti­nu­ity.

Take hun­dreds of ac­tions in Spotlight with­out lift­ing your hands off the key­board.

Create more pow­er­ful short­cuts than ever with Apple Intelligence.

Reimagined with Liquid Glass, ma­cOS Tahoe is at once fresh and fa­mil­iar. Apps bring more fo­cus to your con­tent. You can per­son­al­ize your Mac like never be­fore. And every­thing just flows into place.

Liquid Glass re­fracts and re­flects con­tent in real time, bring­ing even more clar­ity to nav­i­ga­tion and con­trols — and even more vi­tal­ity to every­thing you do.

Personalize your Mac with new op­tions in­clud­ing up­dated light or dark ap­pear­ances, new color-tinted icons, or a stun­ning clear look.

Your dis­play feels even larger with the trans­par­ent menu bar. And you have more ways to cus­tomize the con­trols and lay­out in the menu bar and Control Center, even those from third par­ties.

Sidebars and tool­bars in apps re­flect the depth of your work­space and of­fer a sub­tle hint of the con­tent within reach as you scroll.

Get more done, from even more places.

Now in­te­grated into even more apps and ex­pe­ri­ences, Apple Intelligence helps you get things done ef­fort­lessly and com­mu­ni­cate across lan­guages.

Automatically trans­late texts in Messages, dis­play live trans­lated cap­tions in FaceTime, and get spo­ken trans­la­tions for calls in the Phone app.

Intelligent ac­tions in Shortcuts can sum­ma­rize text, cre­ate im­ages, or tap di­rectly into Apple Intelligence mod­els to pro­vide re­sponses that feed into your short­cut.

More ways to ex­press your­self with im­ages.

Mix emoji and de­scrip­tions to make some­thing brand-new. In Image Playground, dis­cover ad­di­tional ChatGPT styles. And have even more con­trol when mak­ing im­ages in­spired by fam­ily and friends us­ing Genmoji and Image Playground.

Continuity helps you work seam­lessly across Apple de­vices. And with the Phone app and Live Activities com­ing to Mac, it’s even eas­ier to stay on top of things hap­pen­ing in real time.

The menu bar now fea­tures the Live Activities from your iPhone. And when you click one, the app opens in iPhone Mir­ror­ing so you can take ac­tion.

Make and take calls with a click. Conveniently ac­cess your synced con­tent like Recents, Contacts, and Voicemail — and en­joy the fa­mil­iar fea­tures from iPhone.

For un­known num­bers, Call Screening finds out who’s call­ing and why. Once the caller shares their name and the rea­son for their call, your phone rings and you can de­cide if you want to pick up.

Hold Assist keeps your spot in line while you wait for a live agent and no­ti­fies you when they’re ready.

Make quick work of every­day tasks, jump into your fa­vorite ac­tiv­i­ties, and tur­bocharge pro work­flows — all with a whole lot less ef­fort.

Spotlight lets you take hun­dreds of ac­tions with­out lift­ing your hands off the key­board. And new quick keys help you per­form ac­tions even faster.

You can now keep all your apps and most ac­cessed files within easy reach, in­clud­ing in­tel­li­gent sug­ges­tions based on your rou­tines.

Now you can run short­cuts au­to­mat­i­cally — at a spe­cific time of day or when you take spe­cific ac­tions, like sav­ing a file to a par­tic­u­lar folder or con­nect­ing to a dis­play.

And so much more.

Magnifier lets you zoom in on your sur­round­ings us­ing a con­nected cam­era. Accessibility Reader pro­vides a sys­temwide, cus­tomized read­ing and lis­ten­ing ex­pe­ri­ence. Braille Access cre­ates an all-new in­ter­face for braille dis­plays. And Vehicle Motion Cues help re­duce mo­tion sick­ness in mov­ing ve­hi­cles.

Parents can take ad­van­tage of a wide set of parental con­trols de­signed to keep chil­dren safe. These in­clude new en­hance­ments across Communication Limits, Communication Safety, and the App Store.

Now on Mac for the most com­fort­able writ­ing ex­pe­ri­ence, Journal makes it easy to cap­ture and write about every­day mo­ments and spe­cial events us­ing pho­tos, videos, au­dio record­ings, places, and more.

An up­dated de­sign lets you quickly ac­cess fil­ter­ing and sort­ing op­tions and cus­tomize the size of Collections tiles so you can view your li­brary just how you like. And with Pinned Collections, you can keep your most-vis­ited ones right at your fin­ger­tips.

Celebrate the peo­ple who mat­ter most with a new tiled de­sign that fea­tures beau­ti­ful and per­son­al­ized Contact Posters.

With Apple Intelligence, Reminders can sug­gest tasks, gro­cery items, and fol­low-ups based on emails or other text on your de­vice. It can also au­to­mat­i­cally cat­e­go­rize re­lated re­minders into sec­tions within a list.

The new Games app brings to­gether all the games you have on your Mac. In the Game Overlay, you can ad­just sys­tem set­tings, chat with friends, or in­vite them to play — all with­out leav­ing the game. And for de­vel­op­ers, Metal 4 brings even more ad­vanced graph­ics and ren­der­ing tech­nolo­gies, like MetalFX Frame Interpolation and De­nois­ing.

Create polls and per­son­al­ize con­ver­sa­tions with back­grounds. Redesigned con­ver­sa­tion de­tails fea­ture des­ig­nated sec­tions for con­tact info, pho­tos, links, lo­ca­tion, and more. Typing in­di­ca­tors in groups let you know ex­actly who is about to chime in. Screening tools de­tect spam and give you con­trol. And the Add Contact but­ton now ap­pears next to an un­known num­ber in a group.

Easily re­fer to changes you’ve made to your ac­counts. Find pre­vi­ous ver­sions of pass­words, along with when they were changed.

Capture con­ver­sa­tions in the Phone app as au­dio record­ings with tran­scrip­tions. You can also ex­port a note into a Markdown file.

I re­cently bought a cheap Tapo in­door cam­era to see what my dog gets up to when I am out of the house.

What ac­tu­ally fol­lowed? I ended up re­verse-en­gi­neer­ing on­board­ing flows, de­com­pil­ing an APK, MITMing TLS ses­sions, and writ­ing cryp­to­graphic scripts.

My main mo­ti­va­tion for this pro­ject re­ally stemmed from the fact that the cam­era an­noyed me from day one. Setting the cam­era up in frigate was quite painful, no one re­ally seemed to know how these cam­eras worked on­line.

SIDENOTE: If you want 2 way au­dio to work in frigate you must use the tapo:// go2rtc con­fig­u­ra­tion for your main stream in­stead of the usual rtsp://. TP-Link are lazy and only im­ple­ment 2 way au­dio on their own pro­pri­etary API.

One un­doc­u­mented be­hav­ior that tripped me up was that the de­vice’s API is sup­posed to ac­cept cre­den­tials ad­min: af­ter on­board­ing. However af­ter bang­ing my head against a wall for a few hours I later dis­cov­ered that if you change your cloud pass­word af­ter on­board­ing, paired de­vices don’t get the memo 🙂.

This im­plied a few things to me that started the cogs turn­ing:

* There must be a call made dur­ing on-board­ing that syncs the de­vice pass­word with the cloud pass­word

* The de­vice must ei­ther al­low unau­then­ti­cated calls be­fore this step or have some sort of de­fault pass­word.

So con­sid­er­ing my on­board­ing woes and the fact that I was start­ing to re­coil every time the tapo app tried to jam a “Tapo Care” sub­scrip­tion down my throat, a cloud­less on­board­ing so­lu­tion for the de­vice was be­gin­ning to look more and more de­sir­able.

The first step to crack­ing this egg was to be be able to snoop on what the app and the cam­era are say­ing to each other dur­ing on­board­ing. E.g, es­tab­lish a man in the mid­dle.

To man in the mid­dle a phone app, you must be able to route all http(s) traf­fic via a proxy server you con­trol. Historically this has been quite sim­ple to achieve, sim­ply spin up a proxy on a com­puter, add the prox­y’s self-signed cer­tifi­cate to the phone’s trust­store, and con­fig­ure the phone to point at the proxy.

However, mod­ern phone apps can use a few nasty tricks to ren­der this ap­proach in­ef­fec­tive. Namely they will bla­tantly ig­nore prox­ies, throw the sys­tem trust­store to the wind and make lib­eral use of cer­tifi­cate pin­ning.

The most full-proof tech­nique for gener­i­cally MITMing an app has there­fore be­come dy­namic in­stru­men­ta­tion via tools like frida. What this al­lows us to do is force an app to use the prox­ies and cer­tifi­cates that we tell it to whilst bat­ting aside it’s at­tempts to do things like cer­tifi­cate pin­ning.

So the setup ended up look­ing like this (full setup guide here

con­fig:

theme: ‘base’

the­meVari­ables:

pri­ma­ry­Color: ‘#00000000’

pri­ma­ry­Text­Color: ‘#fff’

pri­ma­ry­Bor­der­Color: ‘#ffffff8e’

line­Color: ‘#fff’

sec­ondary­Color: ‘#fff’

ter­tiary­Color: ‘#fff’

se­quence­Di­a­gram

par­tic­i­pant A as Tapo App (with frida hooks)

par­tic­i­pant L as Laptop (mitmproxy)

par­tic­i­pant C as Tapo Camera

A->>L: Request

L->>L: Record re­quest

L->>C: Forward re­quest

C–>>L: Response

L->>L: Record re­sponse

L–>>A: Forward re­sponse

After spin­ning up mitm­proxy, in­ject­ing the frida scripts

, and on­board­ing the cam­era, we fi­nally see an ini­tial lo­gin flow — be­fore the ad­min pass­word ever gets changed:

However, sub­se­quent re­quests look like this:

And re­sponses look like this:

So from this ini­tial dive we have learned that:

* Tapo 100% has a de­fault pass­word due to the fact that it per­forms a full lo­gin be­fore it knows any­thing about the cloud pass­word.

* Tapo has an en­crypted se­curePassthrough chan­nel for its API calls to pre­vent peep­ing toms such as my­self from spilling the beans.

The next log­i­cal step is to de­com­pile the apk in JADX and start rum­mag­ing around for a de­fault pass­word.

The ini­tial lo­gin call that we cap­tured ref­er­ences an ad­min user­name:

Searching for “admin” in JADX gives us many hits but there are a few con­cen­trated in a CameraOnboardingViewModel class that look in­ter­est­ing:

The func­tion m98131y2 ap­pears to be re­turn­ing a pass­word that is then passed to the new Account() call. Following this func­tion up the chain, we hit gold:

We al­ready know

that the de­vice is us­ing en­cryp­t_­type: 3, so that means our de­fault pass­word is:

With the de­fault pass­word now re­vealed, we have the cards in our hand to de­rive ses­sion keys and de­code the se­curePassthrough mes­sages.

The only thing that would help us fur­ther is if we had a ref­er­ence im­ple­men­ta­tion for the au­then­ti­ca­tion flow. This is where PyTapo

re­ally came in handy.

Using PyTapo as a ref­er­ence, we could dump the ses­sion state and en­crypted mes­sages from mitm­proxy and write a script to do some sta­tic analy­sis on the de­crypted re­quests and re­sponses, but a re­ally cool fea­ture of mitm­proxy is that it sup­ports script­ing it­self.

What this means is that we can pass a python script to mitm­proxy, and have it di­rectly de­crypt re­quest and re­sponse pay­loads in­line whilst run­ning a cap­ture.

* Pretty-prints them in­line in mitm­prox­y’s UI in re­quest_de­crypted and re­sponse_de­crypted fields

* Dumps them to JSON files for later analy­sis

The com­plete list of calls made by the Tapo app dur­ing on­board­ing were:

This boiled down to just four im­por­tant calls:

changeAd­min­Pass­word — change from de­fault pass­word to the cloud pass­word

Everything else was fluff: time­zones, record plans, bind­ing to cloud.

In the end, the prize for all this non­sense was a scrappy lit­tle Bash script, tapo_on­board.sh

, which:

* Logs in with the de­fault ad­min pass­word,

* Switches off the ob­nox­ious OSD logo on the cam­era feed,

Peeling this onion left me with a few ob­ser­va­tions on Tapo’s firmware.

* Some end­points use SHA-256 for hash­ing, while oth­ers cling to MD5 like it’s 2003.

* There are two pub­lic keys used to send pass­words to the de­vice — one that is shared with the client and an­other su­per se­cret one that’s hard­coded in the app. The eas­i­est way to fig­ure out which one to use is to flip a coin.

* Password sync­ing be­tween the app and its man­aged de­vices is strictly vibe-based.

The whole thing feels like it was cob­bled to­gether by a con­sor­tium of couch-cryp­tog­ra­phers. But then again, it was the cheap­est in­door cam­era on ama­zon, so what did I ex­pect?

And with all this said I did fi­nally man­age to fig­ure out what the dog does when I am away.

She sleeps. On the sofa. Sometimes even in her bed.

, /PRNewswire/ – On the heels of the PayPal World an­nounce­ment, a global plat­form con­nect­ing the world’s largest dig­i­tal pay­ment sys­tems and wal­lets, PayPal to­day in­tro­duced PayPal links, a new way to send and re­ceive money through a per­son­al­ized, one-time link that can be shared in any con­ver­sa­tion.

PayPal users in the U. S. can be­gin cre­at­ing per­son­al­ized pay­ment links to­day, with in­ter­na­tional ex­pan­sion to the UK, Italy, and other mar­kets start­ing later this month. By mak­ing pay­ments this sim­ple and uni­ver­sal, PayPal links helps drive new cus­tomer ac­qui­si­tion and brings more users into the PayPal ecosys­tem.

The peer-to-peer (P2P) ex­pe­ri­ence is about to go even fur­ther. Crypto will soon be di­rectly in­te­grated into PayPal’s new P2P pay­ment flow in the app. This will make it more con­ve­nient for PayPal users in the U. S. to send Bitcoin, Ethereum, PYUSD, and more, to PayPal, Venmo, as well a rapidly grow­ing num­ber of dig­i­tal wal­lets across the world that sup­port crypto and sta­ble­coins.

Expanding what peo­ple can do with PayPal also comes with re­as­sur­ance around how per­sonal pay­ments are han­dled. As al­ways, friends-and-fam­ily trans­fers through Venmo and PayPal are ex­empt from 1099-K re­port­ing. Users won’t re­ceive tax forms for gifts, re­im­burse­ments, or split­ting ex­penses, help­ing en­sure that per­sonal pay­ments stay per­sonal.

“For 25 years, PayPal has rev­o­lu­tion­ized how money moves be­tween peo­ple. Now, we’re tak­ing the next ma­jor step,” said Diego Scotti, General Manager, Consumer Group at PayPal. “Whether you’re tex­ting, mes­sag­ing, or email­ing, now your money fol­lows your con­ver­sa­tions. Combined with PayPal World, it’s an un­beat­able value propo­si­tion, show­ing up where peo­ple con­nect, mak­ing it ef­fort­less to pay your friends and fam­ily, no mat­ter where they are or what app they’re us­ing.”

P2P is a cor­ner­stone of PayPal’s con­sumer ex­pe­ri­ence, dri­ving en­gage­ment and bring­ing more users into the ecosys­tem. P2P and other con­sumer to­tal pay­ment vol­ume saw solid growth in the sec­ond quar­ter, in­creas­ing 10% year-over-year as the com­pany fo­cused on im­prov­ing the ex­pe­ri­ence and in­creas­ing user dis­cov­er­abil­ity to make it eas­ier than ever to move money glob­ally. Plus, Venmo saw its high­est TPV growth in three years. With PayPal World un­lock­ing seam­less in­ter­op­er­abil­ity, P2P is poised for even greater mo­men­tum in the fu­ture as PayPal and Venmo con­nect to bil­lions of wal­lets world­wide.

* Create a per­son­al­ized link — Open the PayPal app, en­ter the de­tails of your pay­ment or re­quest, and gen­er­ate a unique, one-time link to share.

* Always the right per­son — Each link is pri­vate, one-time use, and cre­ated for a spe­cific trans­ac­tion.

* Drop it any­where — Send your link in a text, DM, email, or chat. Add a note, emoji, or pay­ment note.

* Manage pay­ment ac­tiv­ity: Unclaimed links ex­pire af­ter 10 days. Users can send a re­minder or even can­cel the pay­ment or re­quest be­fore the link is claimed with the PayPal app.

* Tap and done — The re­cip­i­ent taps the link and ei­ther com­pletes or ac­cepts the pay­ment within the PayPal App with their PayPal ac­count.

* Funds are in­stant — the re­cip­i­ent will get im­me­di­ate ac­cess to their funds with a PayPal Balance ac­count once ac­cepted.

About PayPal

PayPal has been rev­o­lu­tion­iz­ing com­merce glob­ally for more than 25 years. Creating in­no­v­a­tive ex­pe­ri­ences that make mov­ing money, sell­ing, and shop­ping sim­ple, per­son­al­ized, and se­cure, PayPal em­pow­ers con­sumers and busi­nesses in ap­prox­i­mately 200 mar­kets to join and thrive in the global econ­omy. For more in­for­ma­tion, visit https://​www.pay­pal.com, https://​about.pypl.com/ and https://​in­vestor.pypl.com/.

About PayPal USD (PYUSD)

PayPal USD is is­sued by Paxos Trust Company, LLC, a fully char­tered lim­ited pur­pose trust com­pany. Paxos is li­censed to en­gage in Virtual Currency Business Activity by the New York State Department of Financial Services. Reserves for PayPal USD are fully backed by U. S. dol­lar de­posits, U.S. Treasuries and sim­i­lar cash equiv­a­lents, and PayPal USD can be bought or sold through PayPal and Venmo at a rate of $1.00 per PayPal USD.

PayPal, Inc. (NMLS ID #: 910457) is li­censed to en­gage in Virtual Currency Business Activity by the New York State Department of Financial Services.

A first ver­sion of this piece was al­most ready to be pub­lished two days ago, but af­ter writ­ing more than 2,000 words, I grew in­creas­ingly an­gry and ex­as­per­ated, and that made the ar­ti­cle be­come too me­an­der­ing and rant-like, so I deleted every­thing, and started afresh sev­eral hours later.

This, of course, is about Awe-dropping, Apple’s September 9 event, where they pre­sented the new iPhone lineup, the new AirPods Pro, and the new Apple Watches. And the hon­est truth here is that I’m be­com­ing less and less in­clined to talk about Apple, be­cause it’s a com­pany that I feel has lost its align­ment with me and other long-time Apple users and cus­tomers.

The more Apple talks and moves like other big tech com­pa­nies, the less spe­cial it gets; the less spe­cial and dis­tinc­tive it gets, the less I’m in­ter­ested in find­ing ways to talk about it. Yes, I have ad­mit­ted that Apple makes me mad lately, so they still elicit a re­sponse that is­n’t ut­ter in­dif­fer­ence on my part. And yes, you could ar­gue that if Apple makes me mad, it means that in the end I still care.

But things aren’t this clear-cut. I cur­rently don’t re­ally care about Apple — I care that their bad soft­ware de­sign de­ci­sions and their con­stant user-in­ter­face dumb­ing down may be­come trends and get picked up by other tech com­pa­nies. So, what I still care about that’s re­lated to Apple is es­sen­tially the con­se­quences of their ac­tions.

The event kicked off with the fa­mous Steve Jobs quote,

Design is not just what it looks like and feels like. Design is how it works.

Why that quote? Why now, af­ter months of crit­i­cism to­wards the new de­sign æs­thetic of Liquid Glass? I gave this choice three pos­si­ble in­ter­pre­ta­tions — I still may be miss­ing some­thing here; I’m sure my read­ers will let me know.

It’s Apple’s way of trolling the crit­ics, who have re­peat­edly re­sorted to Steve Jobs’s words to crit­i­cise the sev­eral mis­guided UI choices in Liquid Glass. It’s the same kind of re­sponse as Phil Schiller fa­mously blurt­ing, Can’t in­no­vate any­more, my ass! in 2013 dur­ing the pre­sen­ta­tion of the then-re­designed Mac Pro. But it feels like a less gen­uine, more pas­sive-ag­gres­sive re­sponse (if this is the way we’re sup­posed to read their use of that quote).

Apple used the quote in earnest. As in, they re­ally be­lieve that what they’re do­ing is in line with Jobs’s words. If that’s the case, this is ut­ter self-de­cep­tion. The quote does­n’t re­flect at all what Apple is do­ing in the UI and soft­ware de­part­ment — the Liquid Glass de­sign is more ‘look feel’ than ‘work’. And the very in­tro­duc­tion of the iPhone Air proves that Jobs’s words are falling on deaf ears on the hard­ware front as well.

Apple used the quote ‘for ef­fect’. As if Meta started a keynote by say­ing, Our mis­sion is to con­nect peo­ple, no more no less. You know, some­thing that makes you sound great and no­ble, but not nec­es­sar­ily some­thing you truly be­lieve (or some­thing that is ac­tu­ally true, for that mat­ter).

I can’t know for sure which of these might be the cor­rect in­ter­pre­ta­tion. I think it heav­ily de­pends on whose Apple ex­ec­u­tive came up with the idea. Whatever the case may be, the ef­fect was the same — it felt re­ally jar­ring and tone-deaf.

If you’re not new here, you’ll know that these are the Apple prod­ucts I care the least, to­gether with HomePods and Apple TV. I al­ways tune out when Apple pre­sents these, so browse Apple’s web­site or go read the tech­ni­cal break­down else­where. Personally, I’m too into tra­di­tional horol­ogy and there­fore the de­sign of the Apple Watch has al­ways felt unimag­i­na­tive at best, and plain ugly at worst.

From a UI stand­point, the Apple Watch con­tin­ues to feel too com­pli­cated to use, and too over­bur­dened with fea­tures. I would­n’t say it’s de­sign by com­mit­tee, but more like de­signed to ap­peal to a whole com­mit­tee. Apple wants the watch to ap­peal to a wide range of cus­tomers, there­fore this lit­tle de­vice comes stuffed with all kinds of bells and whis­tles. As I said more than once, the real fea­ture I would love to see im­ple­mented is the abil­ity to just turn off en­tire fea­ture sets, so that if you only want to use it as a step counter and heart rate mon­i­tor, you can tell the watch to be just that; this would be more than just hav­ing a watch­face that shows you time, steps, heart rate — it would be like hav­ing a watch that does only that. With all the fea­tures you deem un­nec­es­sary ef­fec­tively dis­abled, imag­ine how sim­pler in­ter­act­ing with it would be, and imag­ine how longer its bat­tery life would be.

What re­ally got on my nerves dur­ing the Apple Watch seg­ment of the event, though, is this: Apple al­ways, al­ways in­serts a mon­tage of sob sto­ries about how the Apple Watch has saved lives, and what an in­dis­pens­able life-sav­ing de­vice it is. Don’t get me wrong, I’m glad those lives were saved. But this kind of ‘showcase’ every year is made in such poor taste. It’s clear to me that it’s all mar­ket­ing above every­thing else, that they just want to sell the prod­uct, and these peo­ple’s sto­ries end up be­ing used as a mar­ket­ing tac­tic. It’s de­press­ing.

As for the AirPods, and true wire­less ear­buds in gen­eral, I find this prod­uct cat­e­gory to be the most waste­ful. Unless some­one comes up with a type of ear­buds that have eas­ily re­place­able bat­ter­ies, I’m not in­ter­ested in buy­ing some­thing that’s bound to be­come e‑waste in a rel­a­tively short pe­riod of time.

Don’t buy them. Don’t waste your money, un­less you have money to waste and don’t care about a com­pany with this kind of lead­er­ship. Read How Tim Cook sold out Steve Jobs by Anil Dash to un­der­stand how I feel. I could­n’t have said it bet­ter my­self.

I’d wrap up my ar­ti­cle here, but then I’d re­ceive a lot of emails ask­ing me why I did­n’t talk about the iPhones, so here are a few stray ob­ser­va­tions:

One, maybe in­vol­un­tary, user-friendly move Apple did with this new iPhone lineup is that now we have three very dis­tinct iPhone mod­els, whose na­ture and price should re­ally help peo­ple de­cide which to pur­chase.

The reg­u­lar iPhone 17 is the safe, it­er­a­tive so­lu­tion. It looks like an iPhone 16, it works like an iPhone 16 that has now bet­ter fea­tures. It’s the ideal phone for the av­er­age user (tech-savvy or not). It’s the safe choice and the best value iPhone over­all.

The iPhone 17 Pro is pos­si­bly the most Pro iPhone to date. During its pre­sen­ta­tion, I felt like Apple wants you to con­sider this more like a pro cam­era for video­g­ra­phers and film­mak­ers rather than just a smart­phone with a good cam­era ar­ray. People who have no use for all these pro video record­ing fea­tures should­n’t waste their money on it. Unless they want a big chunky iPhone with the best cam­era ar­ray and/​or have money to burn. In my coun­try (Spain), the 6.3‑inch iPhone 17 Pro starts at €1,319 with 256GB of stor­age, and goes up to €1,819 with 1TB of stor­age. For the big­ger iPhone 17 Pro, those prices be­come €1,469 and €1,969 re­spec­tively, and if you want the iPhone 17 Pro Max with 2TB of stor­age, it’ll cost you €2,469. You do you, but I think these are in­sane prices for phones (and SSDs).

The iPhone Air is just… odd. I was cu­ri­ous to know about other techies’ re­ac­tions, and of all the ma­jor tech YouTubers, I think the one I’m agree­ing the most on their first im­pres­sions of the iPhone Air is Marques Brownlee. At this point in his video, he says:

I re­ally think this phone is gonna be a hard sell, be­cause if you sub­tract emo­tions from it, it’s just… the worst one. This is gonna jump in the lineup at $999 — it re­places es­sen­tially the Plus phones in the lineup — and it is sur­rounded by other iPhones that are bet­ter than it in ba­si­cally every way, other than be­ing su­per thin and light. So it’s a fas­ci­nat­ing gam­ble.

This phone has the same A19 Pro chip in it as the Pro phones, mi­nus one GPU core. Interesting choice: ap­par­ently it’s a bit more ef­fi­cient than the base A19, so that’s good for bat­tery life. But we also just heard a whole long list of choices Apple made with the Pro phones to make them more ther­mally ef­fi­cient to not over­heat — switch­ing from ti­ta­nium to alu­minium, and adding a vapour cham­ber to the back. But this phone is still ti­ta­nium, and ab­solutely does not have room for an ad­vanced ther­mal so­lu­tion or any sort of vapour cham­ber, so it sounds like this phone could get much hot­ter and throt­tle per­for­mance much quicker. It’s a red flag.

Now we also know that ul­tra-thin phones have a ten­dency to be a lit­tle bit less durable. They’ve bent over the years. And I’m not gonna be the first one to point this out. […] And Apple of course has thought about this. They’ve for sure tested this, and they’re telling us it’s the most durable iPhone ever. But, I mean, I’m look­ing at the phone and I think it qual­i­fies also as a red flag. And then we al­ready know there is just no way bat­tery life can be good on this phone, right? There’s just no way. I’ve been re­view­ing phones for more than a decade, and all signs point to it be­ing trash.

There was a slide in the keynote to­day about how they were still proud to achieve ‘all-day bat­tery life’. But, like, come on. Really? I mean they still do the thing where they re­arranged the com­po­nents up into the lit­tle plateau at the top to make room for more bat­tery at the bot­tom. But there’s just ab­solutely not enough room in this phone for a large bat­tery. And it does­n’t ap­pear to be sil­i­con-car­bon, or any sort of a spe­cial ul­tra-high den­sity bat­tery.

And Apple also an­nounced it along­side a spe­cial ded­i­cated MagSafe bat­tery ac­ces­sory, just for this phone, that adds 3,149 mAh, and just barely, com­bined, will match the 17 Pro in terms of quoted video play­back. So if that does­n’t scream red flag, I don’t know what to tell you.

It is also e‑SIM-only, glob­ally, ’cause there’s no room in any ver­sion of this phone for a plas­tic SIM card. There’s also no mil­lime­ter-wave 5G. And like I said, it’s com­ing in at $1,000, which is more ex­pen­sive than the base iPhone, which will have a bet­ter cam­era sys­tem, and bet­ter bat­tery life, and may over­heat less.

So look, I think there’s two ways to look at this phone. This is ei­ther Apple just throw­ing some­thing new at the wall and see­ing if it sticks. […] Or you can see this as a vi­sion­ary, long-time-in-the-mak­ing pre­view at the fu­ture of all phones. Like, maybe some­day in the fu­ture every phone will be this thin. And Apple is just now, to­day, get­ting the tech to­gether with the bat­tery and dis­play and mo­dem and Apple Silicon to make this phone pos­si­ble. Maybe kind of like how the first MacBook Air sucked, and was un­der­pow­ered, but then even­tu­ally all lap­tops be­came that thin. Maybe that’s also what’s gonna hap­pen to smart­phones. And maybe the same way Samsung made the ul­tra-thin S25 Edge, and then a few months later they came out with their su­per-thin fold­able, the Z Fold7, and I felt like the Edge phone was one half of that fold­able. Maybe that’s also what Apple’s do­ing. Maybe we’re gonna see an ul­tra-thin fold­able iPhone next year. Maybe.

Yeah, I’m firmly in the “Apple throw­ing some­thing new at the wall and see­ing if it sticks” camp. Because what’s that in­no­v­a­tive in hav­ing thin smart­phones? What’s the use­ful­ness when the other two di­men­sions keep in­creas­ing? Making a thin and light and rel­a­tively com­pact MacBook and call­ing it ‘Air’ made sense back when vir­tu­ally no other lap­top was that thin and light. It was, and is, a great so­lu­tion for when you’re out and about or trav­el­ling, and space is at a pre­mium; and you also don’t want a bulky com­puter to lug around.

Then Apple ap­plied the ‘Air’ moniker to the iPad, and that started to make less sense. It’s not that a reg­u­lar or Pro iPad were and are that cum­ber­some to be­gin with. And then Apple felt the need to have MacBook Airs that are 13- and 15-inch in size, in­stead of 11- and 13-inch. A 15-inch MacBook Air makes lit­tle sense, too, as an ‘Air’ lap­top. It may be some­what thin, some­what light, but it’s not ex­actly com­pact.

And now we have the iPhone Air — which is just thin for thin­ness’ sake. It’s still a big 6.5‑inch phone that’s hardly pock­etable. I still hap­pen to han­dle and use a few older iPhones in the house­hold, and the di­men­sions of the iPhone 5/5S/SE make this iPhone more ‘Air’ than the iPhone Air. If you want a slightly more re­cent ex­am­ple, the iPhone 12 mini and 13 mini have the real light­ness that could make sense in a phone. Perhaps you’ll once again re­mind me that the iPhone 12 mini and 13 mini weren’t a suc­cess, but I keep find­ing peo­ple telling me they would favour a more com­pact phone than a big-but-thin phone. I’ll be truly sur­prised if the iPhone Air turns out to be a big­ger suc­cess than the ‘mini’ iPhones. It is a strik­ing de­vice in per­son, no doubt, but once this first im­pact is gone and you start think­ing it over and mak­ing your de­ci­sion, what Marques Brownlee said above is kind of hard to deny.

I find par­tic­u­larly hi­lar­i­ous the whole MagSafe bat­tery ac­ces­sory af­fair. Apple cre­ates a su­per-thin, su­per-light phone, proudly show­cases its strik­ing de­sign, and im­me­di­ately neu­tralises this bold move and thin de­sign by of­fer­ing an ac­ces­sory 1) that you’ll clearly need if you want to have a de­cently-last­ing bat­tery (thus ad­mit­ting that that thin­ness cer­tainly came with an im­por­tant com­pro­mise); and 2) that in­stantly de­feats the pur­pose of a thin de­sign by re­turn­ing the bulk that was shaved away in mak­ing the phone.

What should I be in awe of?

I found a lot of re­ac­tions to these prod­ucts to be weirdly op­ti­mistic. Either I’m be­com­ing more cyn­i­cal with age and gen­eral tech fa­tigue, or cer­tain peo­ple are eas­ily im­pressed. What usu­ally im­presses me is some tech­no­log­i­cal break­through I did­n’t see com­ing, or a clever new de­vice, or some clever sys­tem soft­ware fea­tures and ap­pli­ca­tions that give new pur­poses to a de­vice I’ve known well for a while. This event, and what was pre­sented, did­n’t show any of this.

Didn’t you ex­pect Apple to be able to pro­duce yet an­other it­er­a­tion of Apple Watches and AirPods that were bet­ter than the pre­vi­ous one? Didn’t you ex­pect Apple to be able to make a uni­body iPhone af­ter years of mak­ing uni­body com­put­ers? Didn’t you ex­pect Apple to be able to have iPhones with bet­ter cam­eras and record­ing ca­pa­bil­i­ties than last year’s iPhones? Didn’t you ex­pect Apple to be able to make a thin­ner iPhone? To come up with bet­ter chips? Or a vapour cham­ber to pre­vent over­heat­ing? Or a ‘centre stage’ fea­ture for the selfie cam­era? Are these things I should be in awe of?

I will prob­a­bly be gen­uinely amazed when Apple is fi­nally able to come up with a so­lu­tion that en­tirely re­moves the dy­namic is­land from the front of the iPhone while still hav­ing a front-fac­ing cam­era up there.

I’ll be sim­i­larly amazed when Apple fi­nally gets rid of peo­ple who have shown to know very lit­tle about soft­ware de­sign and user in­ter­faces, and comes up with op­er­at­ing sys­tems that are, once again, in­tu­itive, dis­cov­er­able, easy to use, and that both look and work well. Because the iOS, iPa­dOS, and Mac OS 26 re­leases are not it — and these new iPhones might be awe-in­spir­ing all you want, but you’ll still have to deal with iOS 26 on them. These new iPhones may have a fan­tas­tic hard­ware and all, but what makes any hard­ware tick is the soft­ware. You’ve prob­a­bly heard that fa­mous quote by Alan Kay, People who are re­ally se­ri­ous about soft­ware should make their own hard­ware. Steve Jobs him­self quoted it, adding that “this is how we feel about it” at his Apple. Today’s Apple needs to hear a re­vised ver­sion of that quote, some­thing like, People who are this se­ri­ous about their hard­ware should make bet­ter soft­ware for it.

The level of good-enough-ism Apple has reached to­day in soft­ware is down­right baf­fling. This widen­ing gap be­tween their hard­ware and soft­ware com­pe­tence is go­ing to be re­ally dam­ag­ing if the course is­n’t cor­rected. The tight in­te­gra­tion be­tween hard­ware and soft­ware has al­ways been what made Apple plat­forms stand out. This in­te­gra­tion is go­ing to get lost if Apple keeps hav­ing wiz­ards for hard­ware en­gi­neers on one side, and soft­ware and UI peo­ple pro­duc­ing am­a­teur­ish re­sults on the other side. Relying on legacy and un­ques­tion­ing fan­peo­ple, for whom every­thing Apple does is good and awe­some and there’s noth­ing wrong with it, can only go so far. Steve Jobs al­ways knew that soft­ware is com­par­a­tively more im­por­tant than the hard­ware. In a 1994 in­ter­view with Jeff Goodell, pub­lished by Rolling Stone in 2010 (archived link), Jobs said:

The prob­lem is, in hard­ware you can’t build a com­puter that’s twice as good as any­one else’s any­more. Too many peo­ple know how to do it. You’re lucky if you can do one that’s one and a third times bet­ter or one and a half times bet­ter. And then it’s only six months be­fore every­body else catches up. But you can do it in soft­ware.

But not if you keep crip­pling it be­cause you want to bring all your ma­jor plat­forms to the low­est com­mon de­nom­i­na­tor.

Writer. Translator. Mac con­sul­tant. Enthusiast pho­tog­ra­pher. • If you like what I write, please con­sider sup­port­ing my writ­ing by pur­chas­ing my short sto­ries, Minigrooves or by mak­ing a do­na­tion. Thank you!

I have an in­cred­i­bly bor­ing sum­mer hobby: look­ing at the changelog for the WebKit Github repo. Why? Because I spend a chunk of my pro­fes­sional life work­ing with we­b­views in­side mo­bile apps and I like to get an early peek into what’s com­ing in the next ver­sion of iOS. Since Tim Cook has yet to stand up at WWDC and an­nounce “one more thing… Service Worker sup­port in WKWebView, pro­vided you add the cor­rect en­try to the WKAppBoundDomains ar­ray in your Info.plist” (and you know what, he should) man­ual re­search is the or­der of the day.

So I was re­ally in­ter­ested to see, the day af­ter WWDC fin­ished, a pull re­quest named:

Liquid Glass was one of the big take­aways from 2025′s WWDC. Probably the biggest change in iOS UI since iOS 7 ditched the skeuo­mor­phic look of the past. But that’s all na­tive UI, what does any of that have to do with we­b­views?

A poke around the con­text of the PR re­vealed some­thing re­ally in­ter­est­ing: Apple has a cus­tom CSS prop­erty named -apple-visual-effect . Not only does it al­low the use of Liquid Glass in iOS 26 (via val­ues like -apple-system-glass-material) but all ver­sions sup­port us­ing stan­dard ma­te­ri­als with val­ues like -apple-system-blur-material-thin.

Before you, like me, fire up Safari and start edit­ing some CSS, I have bad news: no, it does­n’t work on the web. As well it should­n’t. But it also does­n’t work by de­fault in an app us­ing WKWebView, you have to tog­gle a set­ting in WKPreferences called us­eSys­temAp­pear­ance… and it’s pri­vate. So if you use it, say good­bye to App Store ap­proval.

I wanted to try it out all the same so I hacked around to set us­eSys­temAp­pear­ance to true, set my CSS to:

.toolbar {

bor­der-ra­dius: 50%;

-apple-visual-effect: -apple-system-glass-material;

height: 75px;

width: 450px;

Whoever it was at Apple that de­cided to make this a CSS prop­erty is a ge­nius be­cause it makes it in­cred­i­bly easy to pro­vide dif­fer­ent rules based on Liquid Glass sup­port:

.toolbar {

bor­der-ra­dius: 50%;

height: 75px;

width: 450px;

back­ground: rgba(204, 204, 204, 0.7);

@supports (-apple-visual-effect: -apple-system-glass-material) {

back­ground: trans­par­ent;

-apple-visual-effect: -apple-system-glass-material

It’s an in­ter­est­ing piece of trivia but no-one out­side of Apple can use it. So what does it mat­ter? It does­n’t. Except for the im­pli­ca­tion for what I’ll call The Toupée Theory of In-App Webviews (thanks to graypegg on Hacker News for the re­name). Industry wide they don’t have a great rep­u­ta­tion. But my sug­ges­tion is this: the main rea­son we­b­views in apps have such a bad rep­u­ta­tion is be­cause you don’t no­tice the we­b­views that are in­te­grated seam­lessly.

It stands to rea­son that Apple would­n’t have de­vel­oped this fea­ture if they weren’t us­ing it. Where? We have no idea. But they must be us­ing it some­where. The fact that none of us have no­ticed ex­actly where sug­gests that we’re in­ter­act­ing with we­b­views in our daily use of iOS with­out ever even re­al­is­ing it.

I’m happy to an­nounce the re­lease of asci­inema CLI 3.0!

This is a com­plete rewrite of asci­inema in Rust, up­grad­ing the record­ing file for­mat, in­tro­duc­ing ter­mi­nal live stream­ing, and bring­ing nu­mer­ous im­prove­ments across the board.

In this post, I’ll go over the high­lights of the re­lease. For a deeper overview of new fea­tures and im­prove­ments, see the re­lease

notes and the de­tailed

changelog.

First, let’s get the Rust rewrite topic out of the way. I did it be­cause I felt like it. But se­ri­ously, I felt like it be­cause I pre­fer work­ing with Rust 100x more than with Python these days. And this type of code, with syscalls and con­cur­rency, is way eas­ier to deal with in Rust than in Python. That’s my ex­pe­ri­ence, YMMV. Anyway, in ad­di­tion to mak­ing me en­joy work­ing with this com­po­nent of asci­inema again, the rewrite re­sulted in faster startup, eas­ier in­stal­la­tion (a sta­tic bi­nary), and made many new fea­tures pos­si­ble by in­te­grat­ing asci­inema vir­tual ter­mi­nal

(also Rust) into the CLI.

Let’s look at what’s cool and new now.

The new asci­icast v3 file for­mat is an evo­lu­tion of the good old asci­icast v2. It ad­dresses sev­eral short­com­ings of the pre­vi­ous for­mat that were dis­cov­ered over the years.

The ma­jor change in the new for­mat is the use of in­ter­vals (deltas) for tim­ing ses­sion events. v2 used ab­solute time­stamps (measured since ses­sion start), which had its own pros and cons. One of­ten-brought-up is­sue was the dif­fi­culty of edit­ing the record­ings - time­stamps of all fol­low­ing events had to be ad­justed when adding/​re­mov­ing/​up­dat­ing events.

Other than tim­ing, the header has been re­struc­tured, group­ing re­lated things to­gether, e.g. all ter­mi­nal-re­lated meta­data is now un­der term. There’s also sup­port for the new “x” (exit) event type, for stor­ing the ses­sion exit sta­tus. Finally, line com­ments are al­lowed by us­ing the # char­ac­ter as the first char­ac­ter on a line.

Here’s an ex­am­ple of a short record­ing in asci­icast v3 for­mat:

The new for­mat is al­ready sup­ported by asci­inema

server and asci­inema

player.

The new CLI al­lows for live stream­ing of ter­mi­nal ses­sions, and pro­vides two modes for do­ing so.

Local mode uses built-in HTTP server, al­low­ing peo­ple to view the stream on trusted net­works (e.g. a LAN). In this mode no data is sent any­where, ex­cept to the view­ers’ browsers, which may re­quire open­ing a fire­wall port. The CLI bun­dles the lat­est ver­sion of asci­inema player, and uses it to con­nect to the stream from the page served by the built-in server.

$ asci­inema stream –local

::: asci­inema ses­sion started

::: Live stream­ing at http://​127.0.0.1:37881

::: Press

Remote mode pub­lishes the stream through an asci­inema server (either asci­inema.org or a self-hosted one), which acts as a re­lay, de­liv­er­ing the stream to the view­ers at a share­able URL.

$ asci­inema stream –remote

::: asci­inema ses­sion started

::: Live stream­ing at https://​asci­inema.org/​s/​TQGS82D­wiB­S1bYAY

::: Press

The two modes can be used to­gether as well.

Here’s a live stream of btop run­ning on one of the asci­inema.org servers:

You can also watch it di­rectly on asci­inema.org at

asci­inema.org/​s/​olesiD03B­IFH6Yz1.

Read more about the stream­ing ar­chi­tec­ture and sup­ported pro­to­cols

here.

asci­inema player (seen above) sup­ports all the de­scribed pro­to­cols. To make the view­ing ex­pe­ri­ence smooth and glitch-free, it im­ple­ments an adap­tive buffer­ing mech­a­nism. It mea­sures net­work la­tency in real-time and ad­justs the buffer size con­stantly, aim­ing for a good bal­ance be­tween low la­tency and buffer-un­der­run pro­tec­tion.

asci­inema server can now record every live stream and turn it into a reg­u­lar record­ing. At the mo­ment, asci­inema server run­ning at asci­inema.org has stream record­ing dis­abled and a con­cur­rent live stream limit of 1, but you can self-host the server where record­ing is en­abled and there’s no con­cur­rent stream limit by de­fault. The lim­its on asci­inema.org may change. I’d like to first see how the stream­ing fea­ture af­fects re­source us­age (btw, shout-out to

Brightbox, which pro­vides cloud ser­vices for asci­inema.org).

In the early ver­sions of asci­inema, asci­inema rec did­n’t sup­port sav­ing to a file - the record­ing was saved to a tmp file, up­loaded to asci­inema.org, and the tmp file was re­moved. Later on, the CLI got the abil­ity to spec­ify a file­name, which al­lowed you to save the re­sult of a record­ing ses­sion to a file in asci­icast v1 for­mat and de­cide whether you want to keep it lo­cal only or pub­lish.

Although op­tional, the file­name ar­gu­ment had long been avail­able. However, many, many tu­to­ri­als on the in­ter­net (probably in­clud­ing asci­ine­ma’s own docs) showed ex­am­ples of record­ing and pub­lish­ing in one go with asci­inema rec. That was fine - many peo­ple loved this short path from record­ing to shar­ing.

Over the years, I started see­ing two prob­lems with this. The first one is that lots of peo­ple still think you must up­load to asci­inema.org, which is not true. You can save lo­cally and noth­ing leaves your ma­chine. The sec­ond one is that the op­tion­al­ity of the file­name made it pos­si­ble to un­in­ten­tion­ally pub­lish a record­ing, and po­ten­tially leak sen­si­tive data. And it’s a com­pletely valid con­cern!

Because of that, on sev­eral oc­ca­sions I’ve seen neg­a­tive com­ments say­ing “asciinema is shady” /m\. It was never shady. It’s just a his­tor­i­cal thing. I just kept the orig­i­nal be­hav­ior for back­ward com­pat­i­bil­ity. asci­inema.org is not a com­mer­cial prod­uct - it’s an in­stance of asci­inema server, which is meant to give users an easy way to share, and to give a taste of what you get when you self-host the server. In fact, I en­cour­age every­one to self-host it, as the record­ings up­loaded to asci­inema.org are a li­a­bil­ity for me (while be­ing a good pro­mo­tion of the pro­ject :)).

I hope this clears up any con­fu­sion and sus­pi­cion.

Anyway, many things have changed since the orig­i­nal be­hav­ior of asci­inema rec was im­ple­mented, in­clud­ing my ap­proach to shar­ing my data with cloud ser­vices. These days I self-host lots of ser­vices on a server at home, and I try to avoid cloud ser­vices if I can (I’m prag­matic about it though).

The stream­ing fea­ture was built from the ground up to sup­port the lo­cal mode, which came first, and the re­mote mode fol­lowed.

In asci­inema CLI 2.4, re­leased 2 years ago, I made the up­load com­mand show a prompt where you have to ex­plic­itly make a de­ci­sion on what to do with the record­ing. It looked like this:

$ asci­inema rec

asci­inema: record­ing asci­icast to /tmp/tmpo8_612f8-ascii.cast

asci­inema: press

It was a stop­gap and a way to pre­pare users for fur­ther changes that are com­ing now.

In 3.0, the file­name is al­ways re­quired, and the rec com­mand no longer has up­load ca­pa­bil­ity. To pub­lish a record­ing to asci­inema.org or a self-hosted asci­inema server, use the ex­plicit asci­inema up­load .

A re­lated im­prove­ment in­tro­duced in this re­lease is the new server URL prompt.

When us­ing a com­mand that in­te­grates with asci­inema server (upload, stream,

auth) for the first time, a prompt is shown, pre-filled with

https://​asci­inema.org (for con­ve­nience). This lets you choose an asci­inema server in­stance ex­plic­itly and in­ten­tion­ally. The choice is saved for fu­ture in­vo­ca­tions.

It was al­ways pos­si­ble to point the CLI to an­other asci­inema

server with a con­fig file or en­vi­ron­ment vari­able, but this new prompt should come in handy es­pe­cially when run­ning the CLI in a non-work­sta­tion/​non-lap­top yet in­ter­ac­tive en­vi­ron­ment, such as a fresh VM or a dev con­tainer.

This change should make it eas­ier to use the CLI with your own asci­inema server, and at the same time it dou­bles as an ad­di­tional guard pre­vent­ing un­in­tended data leaks (to asci­inema.org).

I’m re­ally ex­cited about this re­lease. It’s been in the mak­ing for a while, but it’s out now, and I’m look­ing for­ward to see­ing what new use-cases and work­flows peo­ple will dis­cover with it.

It’s go­ing to take a mo­ment un­til 3.0 shows up in pack­age repos­i­to­ries for all sup­ported plat­forms/​dis­tros. Meanwhile, you can down­load pre­built bi­na­ries for GNU/Linux and ma­cOS from the GitHub

re­lease, or build

it from source.

Thanks for read­ing to this point!

Did you like it? Feel free to send me an email with your feed­back to

. You can also reach me on Mastodon at @ku1ik@hachy­derm.io.

Thanks!

When re­fer­ring to the user’s stuff, which is bet­ter out of these:

It’s a trick ques­tion be­cause of­ten you don’t need any pre­fix and can just use:

Amazon is a good ex­am­ple of this in ac­tion be­cause it’s ob­vi­ous that it’s your ac­count and your or­ders:

But what if your prod­uct con­tains things that be­long to you and to oth­ers — for ex­am­ple, a case work­ing sys­tem that con­tains your cases and every­one else‘s?

You could use “My cases” in a nav­i­ga­tion menu like this:

This seems fine on the face of it.

But screens are not only ac­cessed or re­ferred to through a menu.

For ex­am­ple, you might need to sign post users to their cases in an on­board­ing flow, email no­ti­fi­ca­tion or help ar­ti­cle.

Saying some­thing like “Go to my cases” is awk­ward and un­nat­ural — if I told you to go to my cases, you’d think I was telling you to go to my cases, not yours.

Similarly, a sup­port agent might tell you to “Go to your cases” over we­bchat or a phone call. This is con­fus­ing if the UI says “My cases”.

These is­sues just don’t come up when you use “your” — I’ve used this ap­proach in mul­ti­ple prod­ucts over the years, and seen ex­actly zero is­sues in user re­search.

This is easy if we look at an ex­am­ple:

This does­n’t make sense be­cause it sounds like you’re in­struct­ing the com­puter to share their pro­file, not yours.

But it’s clear if you use “my”:

* Use “your” when com­mu­ni­cat­ing to the user

* Use “my” when the user is com­mu­ni­cat­ing to us

If you’d like to de­sign forms that nail ba­sic de­tails like this, as well as com­plex prob­lems found in en­ter­prise sys­tems, you might like my course, Form Design Mastery:

Our ed­i­to­r­ial process is built on hu­man ex­per­tise, en­sur­ing that every ar­ti­cle is re­li­able and trust­wor­thy. AI helps us shape our con­tent to be as ac­cu­rate and en­gag­ing as pos­si­ble. Learn more about our com­mit­ment to in­tegrity in our Code of Ethics.

Our ed­i­to­r­ial process is built on hu­man ex­per­tise, en­sur­ing that every ar­ti­cle is re­li­able and trust­wor­thy. AI helps us shape our con­tent to be as ac­cu­rate and en­gag­ing as pos­si­ble. Learn more about our com­mit­ment to in­tegrity in our Code of Ethics.

Imagine you’re vib­ing to “Teardrop” when sud­denly your face ap­pears on the mas­sive LED screen be­hind the band. Not as a fun crowd shot—as processed data in Massive Attack’s real-time fa­cial recog­ni­tion sys­tem. Welcome to the most un­com­fort­able con­cert ex­pe­ri­ence of 2025.

The band de­ployed live fa­cial recog­ni­tion tech­nol­ogy that cap­tured and an­a­lyzed at­ten­dees dur­ing their re­cent per­for­mance.

During their lat­est tour stop, Massive Attack shocked fans by in­te­grat­ing fa­cial recog­ni­tion into the show it­self. Live video feeds cap­tured au­di­ence faces, pro­cess­ing them through recog­ni­tion soft­ware and pro­ject­ing the re­sults as part of the vi­sual ex­pe­ri­ence. This was­n’t sub­tle venue se­cu­rity—your bio­met­ric data be­came part of the artis­tic state­ment, whether you con­sented or not.

Social me­dia erupted with be­wil­dered re­ac­tions from at­ten­dees. Some praised the band for forc­ing a con­ver­sa­tion about sur­veil­lance that most peo­ple avoid, while oth­ers ex­pressed dis­com­fort with the un­ex­pected data cap­ture. The split re­ac­tions con­firmed the band’s provoca­tive in­tent had landed ex­actly as de­signed.

This stunt aligns with the band’s decades-long cri­tique of sur­veil­lance cul­ture and dig­i­tal con­trol sys­tems.

This provo­ca­tion fits Massive Attack’s DNA per­fectly. The Bristol col­lec­tive has spent years weav­ing po­lit­i­cal com­men­tary into their per­for­mances, par­tic­u­larly around themes of sur­veil­lance and con­trol. Their col­lab­o­ra­tion with film­maker Adam Curtis and con­sis­tent en­gage­ment with pri­vacy is­sues po­si­tioned them as nat­ural provo­ca­teurs for this mo­ment.

Unlike typ­i­cal con­cert tech­nol­ogy that en­hances your ex­pe­ri­ence, this fa­cial recog­ni­tion sys­tem ex­plic­itly con­fronted at­ten­dees with the re­al­ity of data cap­ture. The band made vis­i­ble what usu­ally hap­pens in­vis­i­bly—your face be­ing recorded, an­a­lyzed, and po­ten­tially stored by sys­tems you never ex­plic­itly agreed to in­ter­act with.

Details about data stor­age and par­tic­i­pant con­sent re­main un­clear, adding to both artis­tic am­bi­gu­ity and eth­i­cal con­cerns.

Here’s where things get murky. Massive Attack has­n’t re­leased of­fi­cial de­tails about what hap­pened to the cap­tured bio­met­ric data or whether per­ma­nent records were kept. This opac­ity in­ten­si­fies the artis­tic state­ment while rais­ing le­git­i­mate pri­vacy ques­tions about con­duct­ing sur­veil­lance to cri­tique sur­veil­lance.

The au­di­ence split pre­dictably along ide­o­log­i­cal lines. Privacy ad­vo­cates called it a bound­ary vi­o­la­tion dis­guised as art. Others viewed it as nec­es­sary shock ther­apy for our sleep­walk­ing ac­cep­tance of fa­cial recog­ni­tion in every­day spaces. Both re­ac­tions prove the in­ter­ven­tion achieved its dis­rup­tive goal.

Your re­la­tion­ship with fa­cial recog­ni­tion tech­nol­ogy just got more com­pli­cated. Every venue, every event, every pub­lic space po­ten­tially cap­tures your like­ness. Massive Attack sim­ply made the in­vis­i­ble vis­i­ble—and deeply un­com­fort­able. The ques­tion now is­n’t whether this was art or pri­vacy vi­o­la­tion, but whether you’re ready to con­front how nor­mal­ized sur­veil­lance has be­come in your daily life.