While Adobe’s an­nual MAX con­fer­ence gives the com­pany a chance to un­veil its lat­est fea­tures, it also lets the brand demon­strate some of its more weird and won­der­ful ideas. ‘Sneaks’ sees Adobe en­gi­neers take to the stage to share ideas that may or may not see the light of day, such as 2024′s Project Turntable. Creative Bloq en­joyed an ex­clu­sive pre­view of the con­cept in ahead of its un­veil­ing at MAX, and it’s one of the most im­pres­sive Sneaks we’ve seen.

Project Turntable lets users eas­ily ro­tate 2D vec­tor art in 3D, whilst en­sur­ing it still look like 2D art from any new an­gle. And even af­ter the ro­ta­tion, the vec­tor graph­ics stay true to the orig­i­nal shape, main­tain­ing the de­sign’s orig­i­nal essence.

In the ex­am­ple above, a 2D vec­tor of an il­lus­trated war­rior is ro­tated to face a dragon. While spin­ning, the vec­tor im­age ap­pears to be a 3D ob­ject, but the sta­tic im­age the user set­tles on will be com­pletely flat. Truly im­pres­sive is how the tool uses AI to fill in the ‘gaps’ in the im­age — in an­other ex­am­ple, a 2D horse with only two vis­i­bly legs is ro­tated to re­veal four.

The tool was cre­ated by Adobe re­search sci­en­tist Zhiqin Chen. Adobe’s Brian Domingo told Creative Bloq that like other Adobe Innovation pro­ject, there’s still no guar­an­tee that this fea­ture will be re­leased com­mer­cially — but the team ex­pects it to gen­er­ate a ton of in­ter­est at Adobe Max.

From Automatic Image Distraction Removal, and a new Generative Workspace, Adobe has al­ready an­nounced over 100 new cre­ator-first fea­tures this week. And with huge an­nounce­ments from other brands in­clud­ing Tesla and Meta, this has ar­guably been one of the biggest weeks for AI we’ve seen so far.

Many users pre­fer to use an RSS feed reader to stay up to date with the con­tent on the web­sites they visit. But if you’ve en­abled Cloudflare on your web­site, you’re likely block­ing these RSS users from ac­cess­ing your web­site con­tent with­out re­al­iz­ing it.

In Cloudflare’s dash­board, you’ll find tools de­signed to block bot traf­fic to your web­site. Particularly, the Bot Fight Mode and block all “AI scrap­ers and crawlers” op­tions be­low. When en­abled, these fea­tures end up block­ing users who ac­cess your web­site through RSS read­ers, even though RSS read­ers are le­git­i­mate and aren’t ma­li­cious bots.

How Cloudflare blocks RSS read­ers from your web­site

When en­abling the tools, Cloudflare will eval­u­ate each visit to your web­site and de­ter­mine whether the visit is from an AI scraper or “bot” based on a score , which iron­i­cally Cloudflare uses AI to gen­er­ate.

Then, when a user’s RSS reader at­tempts to read your web­site, Cloudflare pre­sents it with a num­ber of chal­lenges that the reader would never be able to ful­fill.

Here’s an ex­am­ple of the Human Verification chal­lenge that an RSS reader would be shown when it tries to visit your web­site. The chal­lenge re­quires a hu­man to solve and, be­cause an RSS reader is not a hu­man, it can never com­plete them.

In other cases, Cloudflare will sim­ply block the RSS reader from ac­cess­ing your web­site with­out a rea­son.

The only way to re­solve when Cloudflare blocks an RSS reader from ac­cess­ing your web­site is by con­tact­ing you di­rectly and ask­ing you to make a cus­tom rule to un­block it. But Cloudflare should­n’t ex­pect peo­ple to con­tact every owner of every Cloudflare web­site that blocks their RSS reader. And you should­n’t have to waste time log­ging into Cloudflare to add an ex­cep­tion every time they block an RSS reader, ei­ther.

Unblock RSS read­ers while still us­ing Cloudflare

Even though Cloudflare blocks RSS read­ers from your web­site, you can whitelist RSS read­ers as a workaround. This would at least un­block RSS read­ers with­out hav­ing to turn off any se­cu­rity fea­tures that you may have al­ready been en­abled un­til Cloudflare bet­ter ad­dresses the is­sue.

First, find the user agent of any blocked RSS reader in Cloudflare’s an­a­lyt­ics dash­board. The User-Agent of most good RSS read­ers usu­ally in­clude the name of the reader, it’s URL, or a word like “RSS” or “feed” that makes it ob­vi­ous that it’s an RSS reader.

Once you’ve iden­ti­fied an RSS read­er’s user agent, you can cre­ate a cus­tom rule that ex­plic­itly whitelists and al­lows all traf­fic by the read­er’s IP ad­dress or by it’s user agent string. Note that user agents can be dis­guised, so it’s of­ten bet­ter to whitelist the read­er’s IP ad­dress in­stead of the user agent. If you’d like to whitelist Open RSS, please con­tact us for the re­quired in­for­ma­tion.

Cloudflare needs a bet­ter way to al­low RSS read­ers

Cloudflare of­fers a bot ver­i­fi­ca­tion pro­gram to which RSS read­ers own­ers can man­u­ally ap­ply to avoid be­ing blocked by web­sites, but this pro­gram is­n’t guar­an­teed to work and it suf­fers from quite a few prob­lems.

* The ver­i­fi­ca­tion process is flimsy — They’re us­ing a Google form for ap­pli­ca­tions to the pro­gram. Then af­ter ap­ply­ing, no no­ti­fi­ca­tion is sent that they’re work­ing on it or even re­ceived the ap­pli­ca­tion suc­cess­fully (we’ve tried ap­ply­ing twice), with no progress up­dates or ex­pected time­frame for com­ple­tion.

* Verified RSS read­ers are still be­ing blocked — There are re­ports that RSS read­ers Cloudflare has ver­i­fied as “good bots” are still be­ing blocked from web­sites. If Cloudflare has suc­cess­fully ap­proved an RSS reader as a “good bot”, it should­n’t be blocked or still re­quire web­site own­ers to add any cus­tom ex­cep­tion rules.

* Unblocking RSS read­ers across mul­ti­ple web­sites is cum­ber­some — Cloudflare’s only res­o­lu­tion to un­block­ing RSS read­ers is for the own­ers of the read­ers to con­tact each web­site owner di­rectly and ask for an ex­cep­tion to be made. While that may work for one-off cases, this is un­rea­son­able for RSS read­ers that have to ac­cess thou­sands of dif­fer­ent Cloudflare-enabled web­sites each day. It’s also over­whelm­ing for web­site own­ers to con­fig­ure ex­cep­tions for each and every RSS reader.

To be clear, there’s noth­ing wrong with us­ing Cloudflare’s se­cu­rity tools on your web­site to help deal with ma­li­cious AI bots, scrap­ers, and po­ten­tial at­tacks. But Cloudflare needs to en­sure that peo­ple who use RSS tools aren’t blocked from ac­cess­ing your web­site con­tent, and make it eas­ier to re­solve when they are.

Skip to main con­tent

What you’re see­ing be­low is two of Crokinole’s greats si­mul­ta­ne­ously se­cur­ing per­fect rounds. Technically speak­ing, they each flicked a 3.2cm disc 30cm across a board into a 3.5cm hole (just 9% wider than the disc it­self) eight times in a row. In game terms, they made eight open 20s each. But it’s just flick­ing a lit­tle disc across a small board. How hard can it be, re­ally? The mes­mer­iz­ing 56 sec­onds above were cap­tured at the semi­fi­nals of the 2024 World Crokinole Championship, where Connor Reinman de­feated Jason Slater. A matchup not un­like Magic vs. Bird, or Swift vs. Eilish. How rare was this feat of per­fec­tion? Was this one of those ob­scure new Olympic events? You may even be won­der­ing, wtf is Crokinole? We’ll get to all these ques­tions. But first, you must un­der­stand Crokinole. The game’s ori­gin: the south­ern re­gion of Ontario. If you are from the south­ern re­gion of the Canadian province of Ontario, you may al­ready be well-versed in Crokinole due to its Canadian ori­gin. For the unini­ti­ated, Crokinole is like a mashup of shuf­fle­board and curl­ing, played on a table­top board. It’s been around since the 19th cen­tury but has seen a steady rise in global pop­u­lar­ity in re­cent years. To know the game, one must play the game.

Let your train­ing be­gin. The main ob­jec­tive is to flick your discs into higher-scor­ing re­gions. The cen­ter hole is worth 20 points. Be care­ful, though—eight pegs sur­round the fif­teen-point re­gion. Here, your op­po­nent shoots on an empty board. To be a valid shot (and stay on the board) the disc must land within the 15-point re­gion. If any op­po­nent discs are on the board, your disc must hit one to be valid and stay on the board. Give it a try: Hit your op­po­nen­t’s disc. Use the slider and but­ton be­low the board to po­si­tion your disc. Then aim, hold the shoot but­ton to find the per­fect power, and re­lease. If you shoot and it is an in­valid shot, your disc is re­moved from the board and is not scored. It’s your turn, and there are no op­po­nent discs. You just need to land in the fif­teen-point re­gion, but scor­ing a 20 is ideal. A made 20 is set aside and counted. Give it a try: Shoot your disc into the cen­ter hole to se­cure the 20 points. After all six­teen discs are played, points are tal­lied based on the re­gions and any 20s. The round win­ner is the player with the most points, and a game con­sists of mul­ti­ple rounds. Easy Keanu, that was just the ba­sics. We did­n’t even get to the one-cheek rule (yes, that cheek). For more de­tails you can watch this video or read the rules. Oh, and feel free to go play—we made a sim­u­la­tor for you to hone your skills against a bot. You are ready for the next part of the jour­ney. What does the data tell us about Connor Reinman and Jason Slater? Reinman, the back-to-back world cham­pion, and Slater, the peren­nial pow­er­house, are ar­guably the great­est play­ers right now on the world stage. Player rank­ings ac­cord­ing to Crokinole Reference. No matches from 2021-2022. But how good are they? Let’s start by look­ing at their abil­ity to make open 20s, an in­dis­pens­able skill for suc­cess. Here’s how com­pet­i­tive play­ers com­pare in open 20 suc­cess rates. Reinman and Slater are top com­peti­tors in open 20s, with suc­cess rates of 66% and 75%, com­pared to the av­er­age com­pet­i­tive play­er’s 55%. For bas­ket­ball fans: a Crokinole player mak­ing eight con­sec­u­tive 20s in live play is like an NBA player sink­ing 20 straight free throws dur­ing a game—not im­pos­si­ble, but far from com­mon. How do they com­pare to ca­sual play­ers? Observing play­ers with vary­ing ex­pe­ri­ence, suc­cess rates for in-game open 20s ranged from 20% to 50%. The odds of two op­po­nents mak­ing eight con­sec­u­tive shots can vary greatly de­pend­ing on their skill level. Here are the odds of a dou­ble per­fect round. Our the­o­ret­i­cal sce­nar­ios show how even a slight drop in skill greatly im­pacts the odds. To wit­ness this rare event, both top play­ers must hit a hot streak at the same time. These per­cent­ages re­flect in-game at­tempts, where a play­er’s rhythm is dis­rupted by var­i­ous shots. In non-com­pet­i­tive, less plamiger­ent set­tings, their skills re­ally shine—like Shawn Hagarty, who set an un­of­fi­cial record with 64 con­sec­u­tive open 20s. However, real games are far more nu­anced and com­plex. Players — or their op­po­nents — of­ten miss early on. Here’s what the data re­veals af­ter an­a­lyz­ing 300 rounds from var­i­ous matchups in last sea­son’s tour­na­ments. At Which Shot an Open 20 is First Missed in Competitive Matches Note: Based on 300 rounds from fi­nal to quar­ter­fi­nal matches in the past year. More of­ten than not, the elu­sive dou­ble per­fect round is lost right at the start. But I’ve been dis­cussing this in the con­text of the most el­e­gant form — a “pure” dou­ble per­fect round, where all 16 shots are made as open 20s. Technically, though, a miss does­n’t com­pletely rule out a per­fect round. A per­fect round can (and of­ten does) in­clude a com­bi­na­tion of open 20s and ric­o­chet 20s, where a disc bounces in off the op­po­nen­t’s. Ricochet 20s by Justin Slater and Andrew Hutchinson. Watch on YouTube. The per­fect blend of aim and power is re­quired to per­fect shots like those. Try it your­self: can you achieve the feel-good ric­o­chet 20? Going for a 20 is­n’t al­ways the best or even a vi­able op­tion. Discs on the board in­tro­duce more ex­cit­ing sce­nar­ios that add lay­ers of strat­egy. Having all your discs on your side is usu­ally a strong de­fen­sive po­si­tion, but watch­ing your op­po­nent dis­man­tle it can be de­mor­al­iz­ing. That’s ex­actly what hap­pened in this round be­tween Andrew Hutchinson and Nolan Tracey. The Slater-Reinman round was the only dou­ble per­fect in a re­view of 445 highly com­pet­i­tive rounds in the past year. One thing is cer­tain: more skilled play­ers tend to keep the board clear and make open 20s at a higher rate, in­creas­ing the chance of glimps­ing a pure dou­ble per­fect round. If there’s one take­away, it’s that Crokinole is fun and the com­mu­nity is awe­some. Whether you’re play­ing to win or just flick­ing a few rounds with Grandma dur­ing the hol­i­days, it’s a great time. So, maybe you’re into Crokinole now? Here are some re­sources to help you get started, or go get some prac­tice in with the sim­u­la­tor. Buy a board here (or here, here, here) Player types are es­ti­ma­tions based on all open 20 suc­cess rates from 2023-2024 NCA tour­na­ment data. Competitive 20 suc­cess rates are from Shawn Hagarty’s im­pres­sive data. Recreational open 20 suc­cess rates are based on ob­ser­va­tions of 600 open 20 at­tempts from 10 in­di­vid­u­als with at least 50 at­tempts each. First missed shot data is from watch­ing play­off-rounds from all 2023-2024 tour­na­ments on Tracey Boards cov­er­age of events. Yearly NCA tour rank­ings data is based on the rank in July (at the end of the sea­son). Data from Crokinole Reference. The Pudding

is a dig­i­tal pub­li­ca­tion that ex­plains ideas de­bated in cul­ture with vi­sual essays.

This blog post de­tails how I found CVE-2024-6778 and CVE-2024-5836, which are vul­ner­a­bil­i­ties within the Chromium web browser which al­lowed for a sand­box es­cape from a browser ex­ten­sion (with a tiny bit of user in­ter­ac­tion). Eventually, Google paid me $20,000 for this bug re­port.

In short, these bugs al­lowed a ma­li­cious Chrome ex­ten­sion to run any shell com­mand on your PC, which might then be used to in­stall some even worse mal­ware. Instead of merely steal­ing your pass­words and com­pro­mis­ing your browser, an at­tacker could take con­trol of your en­tire op­er­at­ing sys­tem.

All un­trusted code that Chromium runs is sand­boxed, which means that it runs in an iso­lated en­vi­ron­ment that can­not ac­cess any­thing it’s not sup­posed to. In prac­tice, this means that the Javascript code that runs in a Chrome ex­ten­sion can only in­ter­act with it­self and the Javascript APIs it has ac­cess to. Which APIs an ex­ten­sion has ac­cess to is de­pen­dent on the per­mis­sions that the user grants it. However, the worst that you can re­ally do with these per­mis­sions is steal some­one’s lo­gins and browser his­tory. Everything is sup­posed to stay con­tained to within the browser.

Additionally, Chromium has a few web­pages that it uses for dis­play­ing its GUI, us­ing a mech­a­nism called WebUI. These are pre­fixed with the chrome:// URL pro­to­col, and in­clude ones you’ve prob­a­bly used like chrome://​set­tings and chrome://​his­tory. Their pur­pose is to pro­vide the user-fac­ing UI for Chromium’s fea­tures, while be­ing writ­ten with web tech­nolo­gies such as HTML, CSS, and Javascript. Because they need to dis­play and mod­ify in­for­ma­tion that is spe­cific to the in­ter­nals of the browser, they are con­sid­ered to be priv­i­leged, which means they have ac­cess to pri­vate APIs that are used nowhere else. These pri­vate APIs al­low the Javascript code run­ning on the WebUI fron­tend to com­mu­ni­cate with na­tive C++ code in the browser it­self.

Preventing an at­tacker from ac­cess­ing WebUIs is im­por­tant be­cause code that runs on a WebUI page can by­pass the Chromium sand­box en­tirely. For ex­am­ple, on chrome://​down­loads, click­ing on a down­load for a .exe file will run the ex­e­cutable, and thus if this ac­tion was per­formed via a ma­li­cious script, that script can es­cape the sand­box.

Running un­trusted Javascript on chrome:// pages is a com­mon at­tack vec­tor, so the re­ceiv­ing end of these pri­vate APIs per­form some val­i­da­tion to en­sure that they’re not do­ing any­thing that the user could­n’t oth­er­wise do nor­mally. Going back to the chrome://​down­loads ex­am­ple, Chromium pro­tects against that ex­act sce­nario by re­quir­ing that to open a file from the down­loads page, the ac­tion that trig­gers it has to come from an ac­tual user in­put and not just Javascript.

Of course, some­times with these checks there’s an edge case that the Chromium de­vel­op­ers did­n’t ac­count for.

My jour­ney to­wards find­ing this vul­ner­a­bil­ity be­gan when I was look­ing into the Chromium en­ter­prise pol­icy sys­tem. It’s in­tended to be a way for ad­min­is­tra­tors to force cer­tain set­tings to be ap­plied to de­vices owned by a com­pany or school. Usually, poli­cies tied to a Google ac­count and are down­loaded from Google’s own man­age­ment server.

Enterprise poli­cies also in­clude things that the user would not be able to mod­ify nor­mally. For ex­am­ple, one of the things you can do with poli­cies is dis­able the dino easter egg game:

Moreover, the poli­cies them­selves are sep­a­rated into two cat­e­gories: user poli­cies and de­vice poli­cies.

Device poli­cies are used to man­age set­tings across an en­tire Chrome OS de­vice. They can be as sim­ple as re­strict­ing which ac­counts can log in or set­ting the re­lease chan­nel. Some of them can even change the be­hav­ior of the de­vice’s firmware (used to pre­vent de­vel­oper mode or down­grad­ing the OS). However, be­cause this vul­ner­a­bil­ity does­n’t per­tain to Chrome OS, de­vice poli­cies can be ig­nored for now.

User poli­cies are ap­plied to a spe­cific user or browser in­stance. Unlike de­vice poli­cies, these are avail­able on all plat­forms, and they can be set lo­cally rather than re­ly­ing on Google’s servers. On Linux for in­stance, plac­ing a JSON file in­side /etc/opt/chrome/policies will set the user poli­cies for all in­stances of Google Chrome on the de­vice.

Setting user poli­cies us­ing this method is some­what in­con­ve­nient since writ­ing to the poli­cies di­rec­tory re­quires root per­mis­sions. However, what if there was a way to mod­ify these poli­cies with­out cre­at­ing a file?

Notably, Chromium has a WebUI for view­ing the poli­cies ap­plied to the cur­rent de­vice, lo­cated at chrome://​pol­icy. It shows the list of poli­cies ap­plied, the logs for the pol­icy ser­vice, and the abil­ity to ex­port these poli­cies to a JSON file.

This is nice and all, but nor­mally there’s no way to edit the poli­cies from this page. Unless of course, there is an un­doc­u­mented fea­ture to do ex­actly that.

When I was do­ing re­search on the sub­ject, I came across the fol­low­ing en­try in the Chrome Enterprise re­lease notes for Chrome v117:

Chrome will in­tro­duce a chrome://​pol­icy/​test page

chrome://​pol­icy/​test will al­low cus­tomers to test out poli­cies on the Beta, Dev, Canary chan­nels. If there is enough cus­tomer de­mand, we will con­sider bring­ing this func­tion­al­ity to the Stable chan­nel.

As it turns out, this is the only place in Chromium’s doc­u­men­ta­tion where this fea­ture is men­tioned at all. So with nowhere else to look, I ex­am­ined the Chromium source code to fig­ure out how it is sup­posed to work.

Using Chromium Code Search, I did a search for chrome://​pol­icy/​test, which led me to the JS part of the WebUI code for the pol­icy test page. I then no­ticed the pri­vate API calls that it uses to set the test poli­cies:

Remember how I said that these WebUI pages have ac­cess to pri­vate APIs? Well, send­With­Promise() is one of these. send­With­Promise() is re­ally just a wrap­per for chrome.send(), which sends a re­quest to a han­dler func­tion writ­ten in C++. The han­dler func­tion can then do what­ever it needs to in the in­ter­nals of the browser, then it may re­turn a value which is passed back to the JS side by send­With­Promise().

And so, on a whim, I de­cided to see what call­ing this in the JS con­sole would do.

Unfortunately, run­ning it sim­ply crashed the browser. Interestingly, the fol­low­ing line ap­peared in the crash log:

[17282:17282:1016/022258.064657:FATAL:local_test_policy_loader.cc(68)] Check failed: poli­cies.has_­value() && poli­cies->is_list(). List of poli­cies ex­pected

It looks like it ex­pects a JSON string with an ar­ray of poli­cies as the first ar­gu­ment, which makes sense. Let’s pro­vide one then. Luckily pol­i­cy_test_brows­er_proxy.ts tells me the for­mat it ex­pects so I don’t have to do too much guess­work.

So af­ter run­ning this… it just works? I just set an ar­bi­trary user pol­icy by sim­ply run­ning some Javascript on chrome://​pol­icy. Clearly some­thing is go­ing wrong here, con­sid­er­ing that I never ex­plic­itly en­abled this fea­ture at all.

For some con­text, this is what the pol­icy test page is sup­posed to look like when it’s prop­erly en­abled.

To prop­erly en­able this page, you have to set the PolicyTestPageEnabled pol­icy (also not doc­u­mented any­where). If that pol­icy is not set to be­gin with, then chrome://​pol­icy/​test just redi­rects back to chrome://​pol­icy.

So why was I able to set the test poli­cies re­gard­less of the fact that I had the PolicyTestPageEnabled pol­icy dis­abled? To in­ves­ti­gate this, I looked though Chromium Code Search again and found the WebUI han­dler for the set­Lo­cal­Test­Poli­cies func­tion on the C++ side.

The only val­i­da­tion that this func­tion per­forms is that it checks to see if lo­cal_test_provider ex­ists, oth­er­wise it crashes the en­tire browser. Under what con­di­tions will lo­cal_test_provider ex­ist, though?

To an­swer that, I found the code that ac­tu­ally cre­ates the lo­cal test pol­icy provider.

So this func­tion ac­tu­ally does per­form a check to see if the test poli­cies are al­lowed. If they’re not al­lowed, then it re­turns null, and at­tempt­ing to set test poli­cies like I showed ear­lier will cause a crash.

Maybe IsPolicyTestingEnabled() is mis­be­hav­ing? Here’s what the func­tion looks like:

This func­tion first checks if kPol­i­cyTest­PageEn­abled is true, which is the the pol­icy that is sup­posed to en­able the pol­icy test page un­der nor­mal con­di­tions. However, you may no­tice that when IsPolicyTestingEnabled() is called, the first ar­gu­ment, the pre­f_ser­vice, is set to null. This causes the check to be ig­nored en­tirely.

Now, the only check that re­mains is for the chan­nel. In this con­text, “channel” means browser’s re­lease chan­nel, which is some­thing like sta­ble, beta, dev, or ca­nary. So in this case, only Channel::CANARY and Channel::DEFAULT is al­lowed. That must mean that my browser is set to ei­ther Channel::CANARY or Channel::DEFAULT.

Then does the browser know what chan­nel it’s in? Here’s the func­tion where it de­ter­mines that:

If you don’t know how the C pre­proces­sor works, the #if BUILDFLAG(GOOGLE_CHROME_BRANDING) part means that the en­closed code will only be com­piled if BUILDFLAG(GOOGLE_CHROME_BRANDING) is true. Otherwise that part of the code does­n’t ex­ist. Considering that I’m us­ing plain Chromium and not the branded Google Chrome, the chan­nel will al­ways be Channel::UNKNOWN. This also means that, un­for­tu­nately, the bug will not work on sta­ble builds of Google Chrome since the re­lease chan­nel is set to the proper value there.

Looking at the enum de­f­i­n­i­tion for the chan­nels, we can see that Channel::UNKNOWN is ac­tu­ally the same as Channel::DEFAULT. Thus, on Chromium and its de­riv­a­tives, the re­lease chan­nel check in IsPolicyTestingEnabled() al­ways passes, and the func­tion will al­ways re­turn true.

So what can I ac­tu­ally do with the abil­ity to set ar­bi­trary user poli­cies? To an­swer that, I looked at the Chrome en­ter­prise pol­icy list.

One of the fea­tures pre­sent in en­ter­prise poli­cies is the Legacy Browser Support mod­ule, also called the Browser Switcher. It’s de­signed to ac­com­mo­date Internet Explorer users by launch­ing an al­ter­na­tive browser when the user visit cer­tain URLs in Chromium. The be­hav­iors of this fea­ture are all con­trol­lable with poli­cies.

The AlternativeBrowserPath pol­icy stood out in par­tic­u­lar. Combined with AlternativeBrowserParameters, this lets Chromium launch any shell com­mand as the “alternate browser.” However, keep in mind this only works on Linux, MacOS, and Windows, be­cause oth­er­wise the browser switcher poli­cies don’t ex­ist.

We can set the fol­low­ing poli­cies to make Chromium launch the cal­cu­la­tor, for in­stance:

Whenever the browser tries to nav­i­gate to ex­am­ple.com, the browser switcher will kick in and launch /bin/bash. [“-c”, “xcalc # https://​ex­am­ple.com”] get passed in as ar­gu­ments. The -c tells bash to run the com­mand spec­i­fied in the next ar­gu­ment. You may have no­ticed that the page URL gets sub­sti­tuted into ${url}, and so to pre­vent this from mess­ing up the com­mand, we can sim­ply put it be­hind a # which makes it a com­ment. And thus, we are able to trick Chromium into run­ning /bin/bash -c ’xcalc # https://​ex­am­ple.com’.

Utilizing this from the chrome://​pol­icy page is rather sim­ple. I can just set these poli­cies us­ing the afore­men­tioned method, and then call win­dow.open(“https://​ex­am­ple.com”) to trig­ger the browser switcher.

And that right there is the sand­box es­cape. We have man­aged to run an ar­bi­trary shell com­mand via Javascript run­ning on chrome://​pol­icy.

You might have no­ticed that so far, this at­tack re­quires the vic­tim to paste the ma­li­cious code into the browser con­sole while they are on chrome://​pol­icy. Actually con­vinc­ing some­one to do this would be rather dif­fi­cult, mak­ing the bug use­less. So now, my new goal is to some­how run this JS in chrome://​pol­icy au­to­mat­i­cally.

The most likely way this can be done is by cre­at­ing a ma­li­cious Chrome ex­ten­sion. The Chrome ex­ten­sion APIs have a fairly large at­tack sur­face, and ex­ten­sions by their very na­ture have the abil­ity to in­ject JS onto pages. However, like I men­tioned ear­lier, ex­ten­sions are not al­lowed to run JS on priv­i­leged WebUI pages, so I needed to find a way around that.

There are 4 main ways that an ex­ten­sion can ex­e­cute JS on pages:

* chrome.tabs in Manifest v2, which works sim­i­larly to how chrome.script­ing does.

* chrome.de­v­tools.in­spect­ed­Win­dow, which in­ter­acts with the in­spected page when de­v­tools is open.

While in­ves­ti­gat­ing this, I de­cided to look into chrome.de­v­tools.in­spect­ed­Win­dow, as I felt that it was the most ob­scure and thus least hard­ened. That as­sump­tion turned out to be right.

The way that the chrome.de­v­tools APIs work is that all ex­ten­sions that use the APIs must have the de­v­tool­s_­page field in their man­i­fest. For ex­am­ple:

Essentially, what this does is it spec­i­fies that when­ever the user opens de­v­tools, the de­v­tools page loads de­v­tools.html as an iframe. Within that iframe, the ex­ten­sion can use all of the chrome.de­v­tools APIs. You can re­fer to the API doc­u­men­ta­tion for the specifics.

While re­search­ing the chrome.de­v­tools.in­spect­ed­Win­dow APIs, I no­ticed a prior bug re­port by David Erceg, which in­volved a bug with chrome.de­v­tools.in­spect­ed­Win­dow.eval(). He man­aged to get code ex­e­cu­tion on a WebUI by open­ing de­v­tools on a nor­mal page, then run­ning chrome.de­v­tools.in­spect­ed­Win­dow.eval() with a script that crashed the page. Then, this crashed tab could be nav­i­gated to a WebUI page, where the eval re­quest would be re-run, thus gain­ing code ex­e­cu­tion there.

Notably, the chrome.de­v­tools APIs are sup­posed to pro­tect against this sort of priv­i­lege ex­e­cu­tion by sim­ply dis­abling their us­age af­ter the in­spected page has been nav­i­gated to a WebUI. As David Erceg demon­strated in his bug re­port, the key to by­pass­ing this is to send the re­quest for the eval be­fore Chrome de­cides to dis­able the de­v­tools API, and to make sure the re­quest ar­rives at the WebUI page.

After read­ing that re­port, I won­dered if some­thing sim­i­lar was pos­si­ble with chrome.de­v­tools.in­spect­ed­Win­dow.re­load(). This func­tion is also able to run JS on the in­spected page, as long as the in­ject­ed­Script is passed into it.

The first sign that it was ex­ploitable ap­peared when I tried call­ing in­spect­ed­Win­dow.re­load() when the in­spected page was an about:blank page which be­longed to a WebUI. about:blank pages are unique in this re­gard since even though the URL is not spe­cial, they in­herit the per­mis­sions and ori­gin from the page that opened them. Because an about:blank page opened from a WebUI is priv­i­leged, you would ex­pect that try­ing to eval­u­ate JS on that page would be blocked.

Surprisingly, this ac­tu­ally worked. Notice that the ti­tle of the alert has the page’s ori­gin in it, which is chrome://​set­tings, so the page is in fact priv­i­leged. But wait, is­n’t the de­v­tools API sup­posed to pre­vent this ex­act thing by dis­abling the API en­tirely? Well, it does­n’t con­sider the edge case of about:blank pages. Here’s the code that han­dles dis­abling the API:

Importantly, it only takes the URL into con­sid­er­a­tion here, not the page’s ori­gin. As I demon­strated ear­lier, these can be two dis­tinct things. Even if the URL is be­nign, the ori­gin may not be.

Abusing about:blank is nice and all but it’s not very use­ful in the con­text of mak­ing an ex­ploit chain. The page I want to get code ex­e­cu­tion on, chrome://​pol­icy, never opens any about:blank pop­ups, so that’s al­ready a dead end. However, I no­ticed the fact that even though in­spect­ed­Win­dow.eval() failed, in­spect­ed­Win­dow.re­load() still ran suc­cess­fully and ex­e­cuted the JS on chrome://​set­tings. This sug­gested that in­spect­ed­Win­dow.eval() has its own checks to see if the ori­gin of the in­spected page is al­lowed, while in­spect­ed­Win­dow.re­load() has no checks of its own.

Then I won­dered if I could just spam the in­spect­ed­Win­dow.re­load() calls, so that if at least one of those re­quests landed on the WebUI page, I would get code ex­e­cu­tion.

And that’s the fi­nal piece of the ex­ploit chain work­ing. This race con­di­tion re­lies on the fact that the in­spected page and the de­v­tools page are dif­fer­ent processes. When the nav­i­ga­tion to the WebUI oc­curs in the in­spected page, there is a small win­dow of time be­fore the de­v­tools page re­al­izes and dis­ables the API. If in­spect­ed­Win­dow.re­load() is called within this in­ter­val of time, the re­load re­quest will end up on the WebUI page.

Now that I had all of the steps of the ex­ploit work­ing, I be­gan putting to­gether the proof of con­cept code. To re­cap, this POC has to do the fol­low­ing:

Use the race con­di­tion in chrome.de­v­tools.in­spect­ed­Win­dow.re­load() to ex­e­cute a JS pay­load on chrome://​pol­icy

The BrowserSwitcherEnabled, BrowserSwitcherUrlList, AlternativeBrowserPath, and AlternativeBrowserParameters are set, spec­i­fy­ing /bin/bash as the “alternate browser.”

The browser switcher is trig­gered by a sim­ple win­dow.open() call, which ex­e­cutes a shell com­mand.

The fi­nal proof of con­cept ex­ploit looked like this:

And with that, I was ready to write the bug re­port. I fi­nal­ized the script, wrote an ex­pla­na­tion of the bug, tested it on mul­ti­ple op­er­at­ing sys­tems, and sent it in to Google.

At this point how­ever, there was still a glar­ing prob­lem: The race con­di­tion with .inspectedWindow.reload() was not very re­li­able. I man­aged to tweak it so that it worked about 70% of the time, but that still was­n’t enough. While the fact that it worked at all def­i­nitely made it a se­ri­ous vul­ner­a­bil­ity re­gard­less, the un­re­li­a­bil­ity would have re­duced the sever­ity by quite a bit. So then I got to work try­ing to find a bet­ter way.

Remember how I men­tioned that in David Erceg’s bug re­port, he uti­lized the fact that de­bug­ger re­quests per­sist af­ter the tab crashes? I won­dered if this ex­act method worked for in­spect­ed­Win­dow.re­load() too, so I tested it. I also messed with the de­bug­ger state­ment, and it ap­peared that trig­ger­ing the de­bug­ger twice in a row caused the tab to crash.

So I got to work writ­ing a new POC:

And it works! This nice part about this ap­proach is that it elim­i­nates the need for a race con­di­tion and makes the ex­ploit 100% re­li­able. Then, I up­loaded the new POC, with all of the chrome://​pol­icy stuff, to a com­ment on the bug re­port thread.

But why would this ex­act over­sight still ex­ist even though it should have been patched 4 years ago? We can fig­ure out why by look­ing at how that pre­vi­ous bug was patched. Google’s fix was to clear all the pend­ing de­bug­ger re­quests af­ter the tab crashes, which seems like a sen­si­ble ap­proach:

You may no­tice that it seems to con­tain an ex­cep­tion for the Page.reload re­quests so that they are not cleared. Internally, the in­spect­ed­Win­dow.re­load() API sends a Page.reload re­quest, so as a re­sult the in­spect­ed­Win­dow.re­load() API calls are ex­empted from this patch. Google re­ally patched this bug, then added an ex­cep­tion to it which made the bug pos­si­ble again. I guess they did­n’t re­al­ize that Page.reload could also run scripts.

Another mys­tery is why the page crashes when the de­bug­ger state­ment is run twice. I’m still not com­pletely sure about this one, but I think I nar­rowed it down to a func­tion within Chromium’s ren­derer code. It’s specif­i­cally hap­pens when Chromium checks the nav­i­ga­tion state, and when it en­coun­ters an un­ex­pected state, it crashes. This state gets messed up when RenderFrameImpl::SynchronouslyCommitAboutBlankForBug778318 is called (yet an­other side ef­fect of treat­ing about:blank spe­cially). Of course, any kind of crash works, such as with […new Array(2**31)], which causes the tab to run out of mem­ory. However, the de­bug­ger crash is much faster to trig­ger so that’s what I used in my fi­nal POC.

Anyways, here’s what the ex­ploit looks like in ac­tion:

By the way, you might have no­ticed the “extension in­stall er­ror” screen that is shown. That’s just to trick the user into open­ing de­v­tools, which trig­gers the chain lead­ing to the sand­box es­cape.

After I re­ported the vul­ner­a­bil­ity, Google quickly con­firmed it and clas­si­fied it as P1/S1, which means high pri­or­ity and high sever­ity. Over the next few weeks, the fol­low­ing fixes were im­ple­mented:

Eventually, the vul­ner­a­bil­ity in­volv­ing the race con­di­tion was as­signed CVE-2024-5836, with a CVSS sever­ity score of 8.8 (High). The vul­ner­a­bil­ity in­volv­ing crash­ing the in­spected page was as­signed CVE-2024-6778, also with a sever­ity score of 8.8.

Once every­thing was fixed and merged into the var­i­ous re­lease branches, the VRP panel re­viewed the bug re­port and de­ter­mined the re­ward. I re­ceived $20,000 for find­ing this vul­ner­a­bil­ity!

* May 1 - I sent the bug re­port to Google

* May 4 - Google clas­si­fied it as P1/S1

* May 5 - I found the bug in­volv­ing crash­ing the in­spected page, and up­dated my re­port

* May 6 - Google asked me to file sep­a­rate bug re­ports for every part of the chain

* July 8 - The bug re­port is marked as fixed

* July 13 - The re­port is sent to the Chrome VRP panel to de­ter­mine a re­ward

* July 17 - The VRP panel de­cided the re­ward amount to be $20,000

I guess the main take­away from all of this is that if you look in the right places, the sim­plest mis­takes can be com­pounded upon each other to re­sult in a vul­ner­a­bil­ity with sur­pris­ingly high sever­ity. You also can’t trust that very old code will re­main safe af­ter many years, con­sid­er­ing that the in­spect­ed­Win­dow.re­load bug ac­tu­ally works as far back as Chrome v45. Additionally, it is­n’t a good idea to ship com­pletely un­doc­u­mented, in­com­plete, and in­se­cure fea­tures to every­one, as was the case with the pol­icy test page bug. Finally, when fix­ing a vul­ner­a­bil­ity, you should check to see if sim­i­lar bugs are pos­si­ble and try to fix those as well.

You may find the orig­i­nal bug re­port here: cr­bug.com/​338248595

I’ve also put the POCs for each part of the vul­ner­a­bil­ity in a Github repo.

As AI-generated im­ages be­come in­creas­ingly preva­lent across the web, many users find their im­age search re­sults clut­tered with ar­ti­fi­cial con­tent. This can be par­tic­u­larly frus­trat­ing when search­ing for au­then­tic, hu­man-cre­ated im­ages or spe­cific real-world ref­er­ences.

At Kagi, we un­der­stand the im­por­tance of de­liv­er­ing high-qual­ity, rel­e­vant search re­sults. Our AI Image Filter fea­ture is de­signed to ad­dress this chal­lenge, giv­ing users more con­trol over the con­tent they see and pri­or­i­tiz­ing au­then­tic im­agery in search re­sults.

By de­fault, Kagi Image Search down­ranks im­ages from web­sites with a high pro­por­tion of AI-generated con­tent. Try the ex­am­ple search here.

In ad­di­tion to down­rank­ing, we have im­ple­mented an AI im­age la­bel­ing sys­tem. This fea­ture adds a small badge or icon to thumb­nails that are likely to be AI-generated con­tent. The la­bel helps users quickly iden­tify po­ten­tial AI im­ages with­out com­pletely re­mov­ing them from search re­sults.

You can use the AI im­ages fil­ter to com­pletely ex­clude web­sites with AI-generated im­ages from your search re­sults.

Note that, since there is cur­rently no re­li­able way to au­to­mat­i­cally iden­tify AI-generated im­ages with good enough pre­ci­sion, this fea­ture re­lies on the web­site’s rep­u­ta­tion rather than an­a­lyz­ing in­di­vid­ual im­ages. As a re­sult, some AI-generated con­tent may still ap­pear in the re­sults.

If you de­tect a web­site with AI or low qual­ity im­agery that slipped through our fil­ter, you can lower or com­pletely block it off in your search re­sults, us­ing our search per­son­al­iza­tion fea­ture.

Click on shield icon in your im­age search re­sults, the same as you al­ready can do in web search re­sults.

The de­ci­sion to im­ple­ment this fea­ture and have it turned on by de­fault is based on our AI in­te­gra­tion phi­los­o­phy and di­rect user feed­back.

This is far­ily new ter­ri­tory so do not ex­pect the de­tec­tion to be 100% re­li­able. We will be work­ing more to im­prove this in the fu­ture. As al­ways, help us im­prove Kagi by send­ing feed­back.

It is too early to say what the out­come will be in the on­go­ing fight be­tween Automattic and WP Engine, but the WordPress com­mu­nity at large is al­ready the loser. Automattic founder and CEO Matt Mullenweg has been us­ing his con­trol of the pro­ject, and the WordPress.org in­fra­struc­ture, to pun­ish WP Engine and re­move some dis­sent­ing con­trib­u­tors from dis­cus­sion chan­nels. Most re­cently, Mullenweg has in­sti­tuted a hos­tile fork of a WP Engine plu­gin and the forked plu­gin is re­plac­ing the orig­i­nal via WordPress up­dates.

In the be­gin­ning of the Automattic and WP Engine spat, many peo­ple hoped that the com­pa­nies would ratchet down the hos­til­i­ties—or at least leave it to lawyers to sort out while leav­ing the larger com­mu­nity out of it. Those hopes have gone un­re­al­ized.

WP Engine did try to opt for the le­gal-only route. The day af­ter the “reprieve” on the WordPress.org

ban ended, October 2, WP Engine filed a 62‑page

com­plaint against Automattic and Mullenweg per­son­ally, and asked for a jury trial. The suit’s claims in­clude con­trac­tual in­ter­fer­ence, com­puter fraud (for block­ing its ac­cess to WordPress.org), at­tempted ex­tor­tion, li­bel, and slan­der. In ad­di­tion, the suit asks for de­clara­tory judg­ment that WP Engine is not in­fring­ing on or di­lut­ing the WordPress, WooCommerce, and other trade­marks that Automattic named in its cease‑and‑de­sist let­ter.

That is, of course, a move that was un­likely to re­build any burned bridges be­tween Automattic and WP Engine. It was pre­dictable that the WordPress.org ban would re­main in place, that Automattic would re­spond to the suit, and per­haps coun­ter­sue WP Engine. However, to date, there has been no in­di­ca­tion of a coun­ter­suit or re­sponse to WP Engine’s law­suit. Instead, Mullenweg is us­ing other means to cause prob­lems for WP Engine—and those tac­tics have spilled over to the wider WordPress com­mu­nity in trou­bling ways.

Participating in the de­vel­op­ment of WordPress is not re­al­is­ti­cally pos­si­ble with­out log­ging into the site. Using WordPress.org is manda­tory for those who would like to con­tribute and up­date

plu­g­ins, ac­cess the

WordPress Trac (bug tracker) in­stance, and more. On October 9, a

new check­box was added to the ac­count lo­gin form on WordPress.org which reads “I am not af­fil­i­ated with WP Engine in any way,

fi­nan­cially or oth­er­wise.” If the box is left unchecked, users will get a prompt to check the box if they wish to pro­ceed.

Naturally, many con­trib­u­tors had ques­tions about this new check­box, since its word­ing is am­bigu­ous and any pos­si­ble con­se­quences are murky. It seems clear it would ap­ply to those em­ployed by WP Engine, but just how far does “” go? Does this ap­ply, for ex­am­ple, to em­ploy­ees of the many com­pa­nies that host their clients’ web sites on WP Engine? Customers with a sub­scrip­tion to one of WP Engine’s ser­vices? A num­ber of con­trib­u­tors have sought an­swers about this pol­icy in the WordPress Slack, with dis­ap­point­ing re­sults. A hand­ful have re­ported be­ing banned from the Slack in­stance af­ter these con­ver­sa­tions, ei­ther due to press­ing for an­swers or ques­tion­ing Mullenweg’s lead­er­ship.

Javier Casares shared that his ac­count was de­ac­ti­vated af­ter he asked a se­ries of ques­tions in a Slack

thread started by Colin Stewart. (Note that one needs to have a WordPress.org ac­count, and be signed in, to re­quest an ac­count on the WordPress Slack.) In the thread, Mullenweg said that the value of the check­box is not stored, but re­fused to clar­ify what qual­i­fies as an af­fil­i­a­tion with WP Engine. He ad­vised those who had ques­tions to “”.

Like what you are read­ing?

Try LWN for free for 1 month,

no credit card re­quired.

Casares said that most peo­ple agree that WP Engine should con­tribute more to WordPress, but that us­ing WordPress.org as part of the bat­tle is coun­ter­pro­duc­tive. He asked on Slack that the lan­guage be changed to in­di­cate a user does not work for WP Engine, but that sug­ges­tion was not taken up.

Another par­tic­i­pant, Terence Eden, asked

on Slack

whether he could send pull re­quests via GitHub if he was af­fil­i­ated with WP Engine. After an ex­change with Mullenweg that was less than help­ful, Eden replied:

He later re­ported on

Mastodon that his ac­count was de­ac­ti­vated. Andrew Hutchings, a con­trib­u­tor who works on WordPress as part of his work with the MariaDB

Foundation, par­tic­i­pated in the con­ver­sa­tion as well. He won­dered

on Slack

how many in­di­vid­ual con­trib­u­tors could af­ford a lawyer to ad­vise about the check­box and added “I work for a dif­fer­ent Foundation, one that

def­i­nitely can­not af­ford a lawyer for me to con­tribute.” He wrote on his blog about be­ing banned and said that he just wanted to work on the pro­ject:

That may not be an op­tion. During the check­box dis­cus­sion in the #meta Slack chan­nel Alex Sirota said: “Do you not un­der­stand what is hap­pen­ing here? It’s pretty sim­ple

in my opin­ion: you have to take a side.” Stewart said that if that was the in­ten­tion, then Mullenweg could say so him­self. Shortly af­ter, Mullenweg said, “I want you all to be in­formed and in­volved. Not to stay on the

side­lines.” Sirota’s ac­count has also been de­ac­ti­vated now, though it is not clear whether he was banned or de­ac­ti­vated the ac­count him­self.

Mullenweg had also asked Automattic em­ploy­ees to pick a side, shortly af­ter ban­ning WP Engine from WordPress.org. He wrote on October 3 that Automattic had ex­tended an “” to its em­ploy­ees. The com­pany pro­vided a buy­out pack­age of $30,000 or six months of salary (whichever was higher) to em­ploy­ees who wanted to leave be­cause they dis­agreed with Mullenweg’s ac­tions. Employees who ac­cepted the buy­out were im­me­di­ately ter­mi­nated and are not el­i­gi­ble for re­hire. According to the post, 159 people⁠—⁠8.4% of the com­pany⁠—⁠ac­cepted the of­fer.

WordPress’s pop­u­lar­ity has a lot to do with its plu­g­ins and themes. A vanilla WordPress in­stal­la­tion is miss­ing a lot of fea­tures that one might want or need to run a web site: back­ups, com­merce fea­tures, sta­tis­tics, con­tact forms, search-en­gine op­ti­miza­tion (SEO), man­ag­ing URL redi­rects, or adding ad­di­tional con­tent types to WordPress.

A large ecosys­tem has sprung up around WordPress to of­fer ser­vices via those plu­g­ins, paid ver­sions of plu­g­ins with ad­di­tional func­tion­al­ity, and paid themes to sim­plify site de­sign. In turn, that helps so­lid­ify WordPress’s place as the most pop­u­lar con­tent-man­age­ment sys­tem (CMS) on the web.

WP Engine pro­duces pop­u­lar plu­gin called Advanced Custom

Fields (ACF), which has more than two mil­lion in­stalls through WordPress.org. It al­lows de­vel­op­ers to add ex­tra con­tent

fields (called cus­tom fields) to WordPress’s edit screens. This might be used, for ex­am­ple, as part of adding a date

picker or an in­ter­face

to cre­ate photo gal­leries for a site. ACF is, in turn, used by or in con­junc­tion with a

large num­ber of other WordPress plu­g­ins such as Advanced Forms

for ACF and WPML

for trans­lat­ing WordPress sites.

The base ACF plu­gin is free, but it also has a paid

ver­sion (“ACF Pro”) with a yearly sub­scrip­tion. Both are avail­able un­der the GPLv2, but users must pay for ac­cess to up­dates on the Pro ver­sion and those come di­rectly from WP Engine.

On September 28, Mullenweg asked

on Slack whether ACF Pro should be in­cluded in WordPress core, the com­po­nents and func­tion­al­ity in­cluded in a de­fault in­stall of WordPress. That drew mixed re­sponses in the chan­nel. Some users noted that the abil­ity to add cus­tom fields was long over­due, but oth­ers had qualms

about tak­ing over ACF Pro “”. Richard Korthuis asked

what kind of mes­sage it would send to other de­vel­op­ers who cre­ate paid plu­g­ins: “No mat­ter what you think about WP Engine and the whole

dis­pute, this [sends] de­vel­op­ers the wrong mes­sage and would pre­vent

fu­ture in­vest­ments in new plu­g­ins”.

In a now-deleted

Tweet, Automattic an­nounced on October 5, a Saturday, that it had “” in ACF to WP Engine. The com­pany did not pro­vide fur­ther de­tails. John Blackbourn, the WordPress core se­cu­rity team lead, said

that Automattic had breached the Intigriti

Code of Conduct by “” the vul­ner­a­bil­ity pub­licly. Intigriti is a com­pany that runs bug-bounty pro­grams for com­pa­nies, in­clud­ing

WP Engine.

On October 7, WP Engine an­nounced a se­cu­rity re­lease of the plu­gin. The vul­ner­a­bil­ity it­self seems to be mi­nor, ac­cord­ing to the re­lease notes. It is not a flaw that can be ex­ploited re­motely and it only im­pacts “” where a user with ad­min­is­tra­tive priv­i­leges tries to at­tack other ad­min­is­tra­tive users, or tries to gain su­per-ad­min priv­i­leges on a multi-site in­stal­la­tion of WordPress. So far few other de­tails on the vul­ner­a­bil­ity be­yond that have been pro­vided. Another XZ backdoor it is not.

Because its de­vel­op­ers are now blocked from WordPress.org, WP Engine had to pro­vide its fix

to the WordPress Security team to have it up­loaded to the plu­gin di­rec­tory. There are also in­struc­tions

on up­dat­ing the plu­gin man­u­ally to re­ceive up­dates di­rectly from WP Engine.

Mullenweg made an an­nounce­ment

on October 12, an­other Saturday, “on be­half of the WordPress

se­cu­rity team” that ACF was be­ing forked as Secure Custom

Fields (SCF) un­der point 18

of the plu­gin

di­rec­tory guide­lines. That part of the guide­lines states, in part, that WordPress.org may “remove de­vel­oper ac­cess to a plu­gin in lieu

of a new, ac­tive, de­vel­oper” and “make changes to a plu­gin,

with­out de­vel­oper con­sent, in the in­ter­est of pub­lic

safety”. According to the post this move was “”.

Automattic has not merely forked the ACF code and made it avail­able un­der a new name to com­pete with WP Engine. That might raise a few eye­brows, but it would prob­a­bly be con­sid­ered fair game by most ob­servers.

Instead, it has forked the code and taken over the plug­in’s en­try, in­clud­ing all of its re­views, in the WordPress.org cat­a­log. The new plu­gin is be­ing sub­sti­tuted in place of ACF for all of the users who have in­stalled it pre­vi­ously. According to the an­nounce­ment on WordPress.org, sites that auto-up­date plu­g­ins will re­ceive the SCF plu­gin au­to­mat­i­cally. Some site own­ers may be un­aware that the plu­gin has been silently re­placed. According to a com­ment by Mullenweg on Hacker News on October 14, there have al­ready been 225k down­loads of the new plu­gin, and he es­ti­mated “at least 60%

of the sites with auto-up­grade on and us­ing .org for up­dates” have been moved to the fork.

This is not the first time a com­pany has taken con­trol of a pack­age dis­trib­uted through a cen­tral repos­i­tory, though it is rare. The left-pad

in­ci­dent in 2016, for ex­am­ple, saw npm,

Inc. re­store left-pad to the Node.js pack­age repos­i­tory af­ter its de­vel­oper, Azer Koçulu, re­moved it. That move, how­ever, was in­tended to re­duce dis­rup­tion to the Node.js ecosys­tem: the re­moval had bro­ken builds for thou­sands of pro­jects that had in­cluded the pack­age, and Koçulu had ef­fec­tively aban­doned it.

The takeover of ACF’s place in the WordPress di­rec­tory, on the other hand, is a puni­tive move by Automattic against an­other com­pany that reaches be­yond WordPress.org’s in­fra­struc­ture into mil­lions of WordPress in­stalls. Web de­vel­oper Charles Fulton wrote

about the in­ci­dent and said that this is “”; he won­dered if he needed to worry about up­dates to core WordPress that might in­ter­fere with ACF Pro.

Users of ACF Pro that de­pend on the WPGraphQL and WPGraphQL for Advanced Custom

Fields plu­g­ins may have real cause to be con­cerned that Automattic will look to break com­pat­i­bil­ity for ACF. WPGraphQL pro­vides a GraphQL

schema and API for WordPress sites and is a pop­u­lar plu­gin to use in con­junc­tion with ACF. Jason Bahl, the main­tainer of the plu­gin, an­nounced

on October 7 that he was leav­ing WP Engine to join Automattic. Additionally, he said that WPGraphQL is be­com­ing a “” for WordPress.

The con­cept of canon­i­cal plu­g­ins is loosely de­fined, but Mullenweg de­scribed

them in 2022 as of­fi­cial plu­g­ins that are the first choice for a type of func­tion­al­ity, but too niche to be in­cluded in the core dis­tri­b­u­tion. With WPGraphQL de­vel­op­ment un­der Automattic’s roof, it seems un­likely that com­pat­i­bil­ity with ACF will be a pri­or­ity.

Scott Kingsley Clark, who has been in­volved in a pro­ject to bring a fields API into the WordPress core, an­nounced

on October 13 that he was step­ping down from con­tribut­ing to WordPress core. The fields API

pro­ject on GitHub has been archived with a good­bye no­tice that states that it pains him to stop but that he is “done mak­ing ex­cuses for

Matt’s ac­tions and will not as­so­ci­ate my­self with core any

longer”. He added

on Mastodon.social that he was go­ing to re­main part of the WordPress com­mu­nity over­all, and con­tinue work­ing on the Pods plu­gin.

What hap­pens next, what Mullenweg will do next, is any­one’s guess. Mullenweg’s vendetta against WP Engine has spilled over into the com­mu­nity in a way that can’t eas­ily be ig­nored or avoided. His lead­er­ship of the pro­ject is be­ing re­peat­edly called into ques­tion by con­trib­u­tors, users, and out­side ob­servers. That will spill over, if it has­n’t al­ready, into the wider com­mer­cial ecosys­tem and have se­ri­ous con­se­quences for plu­gin cre­ators, cre­ative agen­cies, and host­ing providers who have in­vested a lot into WordPress.

More con­trib­u­tors are likely to step away, whether they do so pub­licly or sim­ply drift away and find other things to do with their time. Quite a few users on so­cial net­works have com­mented that they would no longer rec­om­mend WordPress and are look­ing for al­ter­na­tives. A fork, in ad­di­tion to ClassicPress, seems al­most in­evitable.

There is a le­git­i­mate con­ver­sa­tion to be had, or con­tin­ued, about the com­mer­cial­iza­tion of open-source pro­jects by com­pa­nies that do lit­tle to sus­tain open-source soft­ware but reap its ben­e­fits and pull rev­enue away from the com­pa­nies that do put in the work. That con­ver­sa­tion has been com­pletely eclipsed by Mullenweg’s ac­tions to pun­ish WP Engine.

Armin Ronacher, cre­ator of the Flask web frame­work for Python and par­tic­i­pant in launch­ing the Open Source Pledge, has some in­ter­est­ing

thoughts on the topic of mix­ing money and open source in light of the on­go­ing WordPress cri­sis:

He ob­serves that he has seen too many peo­ple in open source strug­gle “one way or an­other” as a di­rect or in­di­rect re­sult of work in open source. He says Mullenweg, like other cre­ators of open-source pro­jects, feels wronged by see­ing oth­ers find fi­nan­cial suc­cess from his pro­ject even though WordPress is un­com­monly suc­cess­ful “in terms of im­pact, suc­cess, and fi­nan­cial

re­turn for its cre­ator”. Mullenweg’s ac­tions, Ronacher said, “have alien­ated many who would oth­er­wise sup­port him. He’s turn­ing into a ’mad

king’”.

That is deeply un­for­tu­nate, be­cause the ques­tions about sus­tain­abil­ity of open-source pro­jects, and who prof­its from them ver­sus who pro­duces them, are in need of ad­dress­ing. Instead of hav­ing that

con­ver­sa­tion, Mullenweg has put ques­tions about gov­er­nance, cen­tral­ized soft­ware dis­tri­b­u­tion, and soft­ware sup­ply chains at the fore­front.

After decades of be­ing a poster child for the good­ness of open source, WordPress is be­com­ing a case study in the dan­gers of the com­pany-owned pro­ject model. Instead of be­ing the safe choice, WordPress is start­ing to be seen as the risky one—and that per­cep­tion may im­pact open source as a whole.

It may sound like a tall tale, but that is more or less the one re­counted in a re­cent pub­li­ca­tion by a team of sci­en­tists at the National Museum of Natural History (MNHN) and the CNRS, which ex­plains in the pages of the Journal of the Royal Society Interface how birds can sleep while stand­ing, with­out los­ing their bal­ance. We know horses and bovines are ca­pa­ble of this feat thanks to their four legs, but at first glance this does not seem so ev­i­dent for birds. Scientists agree that this sta­bil­ity comes from one thing: tenseg­rity. Created from the con­trac­tion of the words “tension” and “integrity,” tenseg­rity is the prop­erty of a struc­ture to re­main sta­ble and bal­anced thanks to the sub­tle in­ter­play of ten­sion and com­pres­sion in the el­e­ments of which it is made.

“The start­ing point for this re­search was try­ing to un­der­stand evo­lu­tion­ary mech­a­nisms via func­tional mor­phol­ogy, which stud­ies the re­la­tion be­tween an or­gan­is­m’s form and func­tion­ing,” points out Anick Abourachid, a spe­cial­ist on evo­lu­tion­ary bi­ol­ogy, and the Deputy Director of the Adaptive Mechanisms and Evolution re­search unit at the National Museum of Natural History. “We are es­pe­cially in­ter­ested in bird feet.” Studying the evo­lu­tion­ary mech­a­nisms in bird feet is of in­ter­est be­cause birds are a par­tic­u­larly ho­moge­nous group with re­spect to their struc­ture:  “They are all bipedal fly­ing di­nosaurs that, since the group’s ori­gin, have shared a struc­ture built to be aero­dy­namic. They all pos­sess, with no ex­cep­tions, a rigid torso,

un­der­parts for land­ing and tak­ing off, and wings.” What is more, this highly pre­served or­gan­i­sa­tional blue­print is ef­fec­tive every­where, as it can be found in birds liv­ing in all en­vi­ron­ments. “It is this ver­sa­til­ity that has al­ways in­ter­ested and in­trigued me. It was while dis­cussing with my col­leagues Philippe Wenger and Christine Chevallereau that I learned of the ex­is­tence of tenseg­rity, me­chan­i­cal sys­tems en­tirely main­tained by ten­sion.”

It should be noted that bird feet are dis­tinc­tive be­cause they are close, from a struc­tural point of view, to hu­man legs. “Birds are flexed bipeds, which is to say that when they are stand­ing, their en­tire body is bent. For hu­mans this is the equiv­a­lent of a pos­ture crouch­ing on one’s toes.” This pos­ture does not at first glance ap­pear to be com­fort­able, but birds re­lax in this po­si­tion, and can even sleep while stand­ing; in short, they are at rest, and con­se­quently con­sume less en­ergy. To un­der­stand how birds achieve this bal­ance, the sci­en­tists con­ceived a dig­i­tal model based on the anatomy of a small bird, the man­darin di­a­mond­bird (Taeniopygia gut­tata), a species be­long­ing to the passer­ine fam­ily. “It was by greatly sim­pli­fy­ing the body’s sys­tem, pre­serv­ing only what re­lates to stand­ing pos­ture, that we iden­ti­fied pos­tural sta­bil­ity,” Abourachid re­veals.

In this model, the body and foot bones were re­placed by bars, and mus­cles and ten­dons by more or less rigid ca­bles. The joints be­tween each bone in the feet were re­placed by pul­leys. “We be­gan the ex­per­i­ments by us­ing a sin­gle ca­ble that be­gan at the ‘bird’s’ pelvis and stretched to its feet, pass­ing through all of the joints (hip, knee, an­kle), and there­fore through all of the pul­leys.”

This en­abled the re­searchers to re­pro­duce the generic stand­ing pos­ture of birds, al­though their ren­di­tion was not at all sta­ble, which is sur­pris­ing given that we see them perched atop elec­tric ca­bles or tree branches with­out ever falling over. “Our bird model was bal­anced at only one point in space, whereas birds are nat­u­rally bal­anced in a mul­ti­tude of po­si­tions. So we im­proved its sta­bil­ity by us­ing mul­ti­ple ca­bles in­stead of just one, no­tably one that runs be­hind the knee in­stead of in front, as was the case in the ini­tial model.”

Birds do in­deed have a ten­don that passes be­hind the knee, go­ing through a lig­a­ment loop that keeps it aligned, a unique anatom­i­cal fea­ture. With four ca­bles—one run­ning be­hind the knee—the model be­came sta­ble, in other words the sys­tem can pas­sively re­tain bal­ance on its own like a roly-poly toy, even when ex­posed to a mi­nor dis­tur­bance.

The sci­en­tists also grasped that the qual­ity of the ca­bles–and hence of the ten­dons in bird feet–played a de­ci­sive role. “Birds are among the only an­i­mals with cal­ci­fied ten­dons that are prac­ti­cally os­si­fied,” ex­plains Christine Chevallereau, a Senior Researcher at the Nantes Laboratory of Digital Science(LS2N). “In our model, we un­der­stood that this prop­erty had to be taken into con­sid­er­a­tion in or­der to achieve sta­ble bal­ance. The bird needs these stiff ten­dons, be­cause when it stands, it must off­set the ef­fect of grav­ity in or­der not to tip over to one side of the branch. While this low elas­tic­ity may not seem to con­tribute to sta­bil­ity, that is not at all the case, for it lessens the ef­fect of the dis­tur­bances the bird is sub­ject to. This also al­lows for a much quicker re­sponse from the sys­tem, as it will have less of a ten­dency to de­form be­fore re­turn­ing to its po­si­tion of bal­ance.” Whether it is snow­ing, rain­ing, or windy, this tenseg­rity sys­tem al­lows birds to con­tinue sleep­ing, with­out fear of falling from their perch.

“The ad­van­tage bird’s de­rive from the tenseg­rity in their feet is based on the mech­a­nis­m’s pas­sive na­ture. The bird sub­se­quently does not have to think or con­cen­trate to re­main stand­ing. Everything is based on the sys­tem’s elas­tic­ity. This is a kind of em­bod­ied in­tel­li­gence where the body alone solves the prob­lem, with no in­ter­ven­tion by the brain, thereby do­ing so with­out con­sum­ing en­ergy,” Chevallereau adds.

Hirshhorn Museum and Sculpture Garden, Smithsonian Institution, don de Joseph H. Hirshhorn, 1974 / Collection Kröller-Müller Museum - Photos Onderwijsgek et Saku Takakusaki CC BY-SA 4.0 via Wikimedia com­mons

The mech­a­nis­m’s pas­sive char­ac­ter is sur­pris­ing, but it paves the way for high-im­pact ap­pli­ca­tions. “We should re­mem­ber that these mech­a­nisms are widely used in civil en­gi­neer­ing, as they make it pos­si­ble to lighten a struc­ture. The idea with this dis­cov­ery is to use such mech­a­nisms in ro­bot­ics in or­der to lighten masses in mo­tion, con­sume less en­ergy, use less ma­te­ri­als in con­struc­tion, and re­duce dan­ger in the event of a col­li­sion with an op­er­a­tor,” points out Philippe Wenger, a Senior Researcher at LS2N. Engineers have al­ready imag­ined bipedal ro­bots with tenseg­rity sys­tems al­low­ing them to main­tain a stand­ing pos­ture while bal­anced on un­sta­ble sur­faces, and do­ing so for long pe­ri­ods with­out con­sum­ing the least en­ergy.

You can now guide NotebookLM’s Audio Overview, guid­ing what the AI hosts fo­cus on and their ex­per­tise level, and ap­ply for the NotebookLM Business pi­lot pro­gram.

NotebookLM, a tool pow­ered by Gemini 1.5, helps users un­der­stand com­plex in­for­ma­tion by in­stantly be­com­ing an ex­pert on up­loaded sources. New fea­tures in­clude cus­tomiz­able Audio Overviews, al­low­ing users to pro­vide in­struc­tions for AI hosts and lis­ten to au­dio while work­ing within NotebookLM. Additionally, NotebookLM Business, an up­com­ing ver­sion of­fered via Google Workspace, will pro­vide en­hanced fea­tures for busi­nesses, uni­ver­si­ties, and or­ga­ni­za­tions, pri­or­i­tiz­ing data pri­vacy and se­cu­rity. Apply for the NotebookLM Business pi­lot pro­gram to gain early ac­cess to new fea­tures, train­ing, and email sup­port.

Summaries were gen­er­ated by Google AI. Generative AI is ex­per­i­men­tal.

NotebookLM is a tool that helps you un­der­stand in­for­ma­tion from your sources.

Now, you can cus­tomize Audio Overviews by giv­ing in­struc­tions to the AI hosts.

You can also lis­ten to Audio Overviews while work­ing in NotebookLM.

NotebookLM Business is com­ing soon with en­hanced fea­tures for busi­nesses and or­ga­ni­za­tions.

Summaries were gen­er­ated by Google AI. Generative AI is ex­per­i­men­tal.

NotebookLM is a tool for un­der­stand­ing, built with Gemini 1.5. When you up­load your sources, it in­stantly be­comes an ex­pert, ground­ing its re­sponses in your ma­te­r­ial and giv­ing you pow­er­ful ways to trans­form in­for­ma­tion. And since it’s your note­book, your per­sonal data is never used to train NotebookLM. Millions of peo­ple are al­ready us­ing NotebookLM to un­der­stand and en­gage with com­plex in­for­ma­tion, and to­day we’re re­mov­ing the pro­duc­t’s “Experimental” la­bel and re­leas­ing an­other round of fea­tures.Get more out of your Audio OverviewsWe’ve been de­lighted with the re­cep­tion of Audio Overviews so far, and we’re in­tro­duc­ing a pair of new fea­tures to­day:Guide the con­ver­sa­tion: Now you can pro­vide in­struc­tions be­fore you gen­er­ate a “Deep Dive” Audio Overview. For ex­am­ple, you can fo­cus on spe­cific top­ics or ad­just the ex­per­tise level to suit your au­di­ence. Think of it like slip­ping the AI hosts a quick note right be­fore they go on the air, which will change how they cover your ma­te­r­ial.Back­ground lis­ten­ing: You can also lis­ten to Audio Overviews while con­tin­u­ing to work within NotebookLM. Query your sources, get ci­ta­tions, and ex­plore rel­e­vant quotes with­out in­ter­rupt­ing the au­dio.

By tap­ping “Customize,” you can now guide NotebookLM’s Audio Overview, ad­just­ing what the AI hosts fo­cus on and their ex­per­tise level.

To try it out, fol­low these steps:Add at least one sour­ceIn your NotebookLM guide, tap “Generate” for an au­to­matic Audio Overview or “Customize” to pro­vide in­struc­tions for the AI host­s­Like al­ways, Audio Overviews are gen­er­ated dis­cus­sions and are not a com­pre­hen­sive or ob­jec­tive view of a topic, but sim­ply a re­flec­tion of the sources that you’ve up­loaded and any in­struc­tions you pro­vide.We’re an­nounc­ing NotebookLM Business, an up­com­ing ver­sion that will be of­fered via Google Workspace with en­hanced fea­tures for busi­nesses, uni­ver­si­ties and or­ga­ni­za­tions. From the start, NotebookLM has made data pri­vacy and se­cu­rity a top pri­or­ity, and we’ll con­tinue to do that.Start­ing to­day, you can ap­ply for the NotebookLM Business pi­lot pro­gram to get early ac­cess to new prod­uct fea­tures, train­ing and email sup­port. In the mean­time, you can con­tinue to use the free ver­sion of NotebookLM, and we’ll share more about the gen­eral avail­abil­ity and pric­ing of NotebookLM Business later this year.With over 80,000 or­ga­ni­za­tions al­ready us­ing NotebookLM, we look for­ward to wel­com­ing even more.

NotebookLM Business will be of­fered via Google Workspace, with more in­for­ma­tion com­ing later this year.

After months of wait­ing, we are fi­nally ready to un­box the lat­est ver­sion of Inkscape… meet 1.4, the Geek edi­tion, where ac­ces­si­bil­ity and cus­tomiza­tion reign.

Inkscape pro­ject de­vel­op­ers, most of them vol­un­teer con­trib­u­tors from coun­tries around the world, have been plug­ging away be­hind the scenes on new fea­tures, im­prov­ing cur­rent ones, bug fixes and set­ting the stage for the ar­rival of GTK 4.

Let’s dig into some of the new and im­proved fea­tures that en­able more cus­tomiza­tion and bet­ter ac­ces­si­bil­ity in Inkscape in a cool, geeky sort of way. Inkscape Power Users, this one’s for you!

The Inkscape 1.4 Filter Gallery di­a­log is your new en­try point into the world of fil­ters. Head to the Filters menu to find it and your fa­vorites more eas­ily, with pre­views by cat­e­gory or by typ­ing key words in the search bar. This in­cludes those cus­tom fil­ters you’ve added — look for them in the Personal cat­e­gory. Accessibility fea­tures here in­clude the abil­ity to change the size of the pre­view of thumb­nails.

For those of you seek­ing the ul­ti­mate in sym­me­try and ac­cu­racy, you’ll find the new grid se­lec­tor but­tons a quicker, more vi­sual way of iden­ti­fy­ing your grid of choice. For the new mod­u­lar grids, you can ad­just plenty of grid pa­ra­me­ters sep­a­rately, from height and width to hor­i­zon­tal and ver­ti­cal gaps — in­clud­ing ad­just­ments at the grid mod­ule (rectangle) level. Enable this op­tion by head­ing to doc­u­ment prop­er­ties.

Inkscape’s Swatches di­a­log has a fresh new face. It now in­cludes a drop-down menu with pre­views of color palettes. You can dis­play them with their col­ors’ names as a list or a grid. For Power Users, you can now in­crease the tile size, too. Search for your cus­tom swatches, or those of your cus­tomers, too. Import palettes from the di­a­log, in­clud­ing those from Adobe Color Book that use CIELAB colours, while sup­port for those with CMYK is still lim­ited for now. Transitioning from CMYK to RGB has been im­proved.

For those of you who have a thing for fonts, Inkscape 1.4 is your new go-to for cus­tomiza­tion. You’ll find an eas­ier route to but­tons for sort­ing glyphs and re­mov­ing pairs. Powerful cus­tomiza­tion at it’s finest in Inkscape!

Inkscape is test­ing out a uni­fied font browser pre­view. Activate this fea­ture in Preferences and restart. After that, you will ac­cess vi­sual pre­views for fonts with set­tings such as adding your own sam­ple text. Check for par­tic­u­lar font char­ac­ter­is­tics by search­ing fonts by col­lec­tion type. Click on the one you want and watch it be ap­plied to your text.

With Inkscape 1.4, you’ll now see that the on-can­vas han­dles are cus­tomiz­able by size, colour, stroke width, out­line and opac­ity. This will be up­dated live in Inkscape when the CSS file has been saved.

You can now tackle quick ed­its on raster (pixel) im­ages within Inkscape us­ing the Shape Builder tool. Load an im­age and se­lect sec­tions that you want to iso­late. Choose them with Shape Builder to clip them. Note that to edit them, you’ll need to re­lease the clip and then un­link the clone. This tool is use­ful for a quick fix, iso­lat­ing part or parts of an im­age quickly.

As of Inkscape 1.4, the Objective Attributes and Object Properties di­alogs have been rolled up into one. This one-stop-shop is where you can change the dif­fer­ent prop­er­ties of ob­jects, in­clud­ing ro­ta­tions and cor­ners.

If you use Inkscape to de­velop and pub­lish doc­u­ments, you’ll be happy to know that you can now add links from one page to an­other within a PDF doc­u­ment–think table of con­tents.

Additionally, Inkscape 1.4 can now open Affinity Designer files, adding more ver­sa­til­ity to the pro­gram.

Welcome, Dash, the lat­est icon set to be ac­ces­si­ble within Inkscape. For those of you who like cus­tomiz­ing, you’ll ap­pre­ci­ate this ad­di­tional set of 500 plus icons to ex­plore. These in­clude cur­sors, both scal­able and sym­bolic ver­sions, that work on light and dark themes.

That con­cludes our brief wan­der through some of the top fea­tures in­cluded in Inkscape 1.4. For more in­for­ma­tion, the Inkscape 1.4 Release Notes are up to date to with in­for­ma­tion on all the changes in­cluded in this edi­tion.

Get Inkscape 1.4 for Linux, Windows or ma­cOS!

If you have ques­tions for us, head to our web site and find our on­line com­mu­nity, where you can also find ways to get in­volved in the pro­ject.