Security, Security, Security.

[FullBleed]

@vladmandic

One of the things that bothers me about A1111's SD webUI is that it just doesn't seem to be very security focused.

There is only one anonymous code maintainer. You'd think a project this big and popular could use a couple more with a 2 person pull request review/approval. That would enhance security and reduce bugs.

I've seen security PR's sit for longer than they should.

There is nothing in the "Security Policy" section of the git with suggestions about what users and devs should and should not do.

Once you have a bunch of extensions that are being auto-updated, what's to stop a dev from slipping in something malicious?

Even though we have the safetensor format, there are places it seems like unsafe formats are still being used and I don't think the risk is properly prioritized (i.e. why aren't ti files safetensor?) I know this isn't specifically a webUI issue, but it could warn or push the issue and change perspective and adoption... At least make people opt into the risky behaviour rather than ignoring it.

This is a fairly technical/enthusiast project and there are a lot of non-technical users who are willing to blindly do just about anything anyone tells them to do to get things working, get a little bit more performance, add a new super feature, or use a particular model/lora/ti, etc. Ignorance is bliss... until it's not. ;) I'm seeing more anti-virus programs flag some things lately (most are, presumably, false-positives... but it tells me that they might actually be "looking" at these files more closely now. And that usually means that there is a growing threat profile.)

So, I was wondering, given your background with data protection... how do you rate the safety of this corner of SD? What do you think could be done better?

[vladmandic]

this is a long & complicated topic. first, 110% cudos to automatic for creating this repo.
few things i found have done differently?

• state chould not be in gradio components. yes, that was quicker in the early days, but makes decoupling gradio from actual sd code nearly impossible now.
• user api (/sdapi/) should not be in gradio. gradio is not designed to be an api server. yes, it has fastapi instance inside it, but lets leave that one for gradio alone. i'd implement api as a separate http server. especially when using webui to listen on external ip - gradio should always llsent only on loopback and never be exposed. minimize surface area and expose only actual user-facing api.
• extensions should be split into near-core vs user-mode. for example, lora is something that needs to be near-core and should be able to integrate deeply with server. and such extensions should go through verification process. the rest (any normal extension)? well, it should be pure user-mode - it should not be allowed to have its own installer that modifies system libraries and brings in anything it wants. i think this is by far the biggest security issue (and reliability as well). actually, as ecosystem grows, more extensions should transition to using api vs attempting code integration with core - that is always bound to fail in the long run.
• safetensors vs ckpt vs pt vs bin. its less of an issue that people give it since ckpt can go through same "safe" verification process as safetensors. imo, safetensors are overblown. its designed to be easy-to-use, but doesn't mean that ckpt cannot be made safe (same for pt).
• review/oversight. well, i said it before in some conversations - once any open-source repo has that many users, its time to move it to org ownership (its easy to setup a free org on github) and assign multiple owners. it just cannot live ownership of a single person. then owners can vote in/out other maintainers and setup review process.

there is much more that can be said on this topic, i tried to be brief as possible here.