10 interesting stories served every morning and every evening.




1 647 shares, 57 trendiness

Adobe's new image rotation tool is one of the most impressive AI concepts we've seen

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.

...

Read the original on www.creativebloq.com »

2 488 shares, 24 trendiness

Using Cloudflare on your website could be blocking RSS users

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.

...

Read the original on openrss.org »

3 378 shares, 40 trendiness

Welcome to Crokinole, the greatest game you’ve never heard of.

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.

...

Read the original on pudding.cool »

4 375 shares, 19 trendiness

Escaping the Chrome Sandbox Through DevTools

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.

...

Read the original on ading.dev »

5 243 shares, 17 trendiness

Dungeons and Interfaces · Wiki · Andrew Kravchuk / cl-fast-ecs · GitLab

...

Read the original on gitlab.com »

6 229 shares, 19 trendiness

AI Image Filter for Search Results

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.

...

Read the original on help.kagi.com »

7 227 shares, 8 trendiness

WordPress retaliation impacts community [LWN.net]

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 ACFs 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.

...

Read the original on lwn.net »

8 210 shares, 8 trendiness

Why birds do not fall while sleeping

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.

...

Read the original on news.cnrs.fr »

9 203 shares, 24 trendiness

Customizing your Audio Overviews and introducing NotebookLM Business

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.

...

Read the original on blog.google »

10 201 shares, 27 trendiness

Inkscape launches version 1.4, with powerful new accessible and customizable features

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.

...

Read the original on inkscape.org »

To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".

10HN is also available as an iOS App

If you visit 10HN only rarely, check out the the best articles from the past week.

If you like 10HN please leave feedback and share

Visit pancik.com for more.