cool! I didn't know, which is why I wanted to ask before I assumed

my only problem with her initial work was that nearly everything she highlighted (which were all good points) were things that we haven't changed since google!

so my initial feedback was "we'll put all that in the backlog. how about the things we've made worse?"

that should make it easier not to take (even constructive) criticism personally!

yeah - but i want a bit of tough love! I've asked her to look at the icosa integration next. the stuff in beta

the main benefit of knowing a ux person is looking at stuff is that it's had a profound effect on my motivation to fix UX issues!

from a quick skim, it looks like a really nice list

https://discord.com/channels/783806589991780412/804251629993197618/1407117119535185973 This looks interesting!

1000 stars! 🎉 https://cdn.discordapp.com/attachments/803747594378936361/1411095042449342566/image.png?ex=68b3682a&is=68b216aa&hm=729b5b82e7f40e46a8e9c980531f020f6acb7af2915fb1a4f551fe21639ae815&

@PerlinWarp | PeterW huge congratulations on your tech finally seeing the light of day 😄 👏

Oh nice. A CVE before breakfast.

And I thought I had a nice easy day fixing Godot shaders.

> On Microsoft Windows systems, the presence of a registered custom URI handler for a vulnerable application or handler name could increase the risk of exploitation. If a custom URI scheme is present and can be invoked on the target system, an attacker who can cause that URI to be opened could trigger the vulnerable library-loading behavior without needing direct command-line access. Potential exploitation remains constrained to the privileges of the targeted application and to the data and services accessible to that process. Entities that routinely create registered URI handlers for Unity applications are encouraged to contact Unity directly at security@unity3d.com.

We don't register a url handler?

Jokes on them! We already allow any url to trigger command line actions. Checkmate hackers!!

Given that we have full disk access, this could kinda sorta be considered a big deal on Quest. OTOH, they're single user systems and if someone wants to deliver malware, they'll label it GorillaTagModProV2.apk or something like that and just get the user to click through 😉

none of our api commands can access files outside of Media Library or Sketches (let alone outside of Open Brush itself). I'm fairly sure we check for directory traversal attacks but I would welcome a security review of any kind!

the one thing i'm slightly wary about is the fact that any webpage can have a link to http://localhost:40074/some/api/command and trick users into clicking it. However - none of the API commands can do anything dangerous currently. It would be easy for some complex chaining of functionality in the future to slip something in.

i don't fully understand the scope of the CVE @mikeage in some cases it talks about android intents, then windows url handlers. to be on the safe side we should probably upgrade both blocks and brush to use unity 2022.3.67f2

beta and prod obvs.

or we could patch the release binaries if that's easier.

I wasn't thinking about an API command, but about loading a different shared object with our permissions. But it's pretty unlikely. Upgrading, though, to a new Unity seems sensible

And this might be a good time to think about Beta->Prod in general 🙂

not for a week or so. i've got too much coming up

our normal timeline is months, so a week to start thinking is already good!

i'm still a bit stumped about how to handle the UK Online Safety Bill and I've been mostly avoiding thinking about it

i guess i could hide icosa integration temporarily 😕

i'm also really not in the mood to do marketing at the moment but maybe i can just, erm, not do any and release anyway 🙁