A few people in the other thread assumed that it was required to fork the code to disable those filters. That’s not the case, the filters can be configured, and are off by default.
To hide the reputation system, here’s a line of CSS that admins can add in the admin area to hide it for every user
That CSS line can also be used by any user wanting to hide the score at the user level.
I get that many people are concerned about is scoring systems, but it seems a lot more worrying to me that it allows arbitrary code execution.
You mean the Javascript that would need to be written and added by the instance admin? Something that any admin with infra access could do anyway? Hardly seems arbitrary at all. ACE usually means something not intended.
I too think the top commenter here hasn’t quite understood what they are seeing in this picture. 😅
Well, just copy and pasted rather than written. I would have hoped that infra read-level permission, infra write-level permission and admin interface permissions were all separate to begin with, even if the person who spun up the instance obviously has all three.
You do need a level of trust in an admin, of course, but wide open text boxes for putting in code are a questionable system design choice, in my opinion. It adds an extra point of possible entry that then relies on the security of the overall admin interface instead of limiting it to what should require highest level infra admin permissions to access. And if it is something that would be limited to someone who has those, then what is the actual utility of having a textarea for it in the first place?
Oh, I love it. So much freedom to customise our instance without having to rebuild the Docker image or fork the codebase.
Out of curiosity, what sort of customizations are you doing with it? I’m just a bit surprised that docker rebuild or a non-trivial fork would be needed, so I’m assuming they’re pretty big changes.
Some instances have used it to do something like a dynamic message of the day. That is the most I have seen it used for so far.
Edit: See the top of the main content pane of anarchist.nexus as an example.
So far I’ve only changed the colour theming, but I like freedom in general. One thing I want to do at some point is change the font of any instance of the string MULTIVERSE, My partner suggested it as a cool branding idea
Wait what? I read in other threads the code was bad, not I didn’t think it’d be this bad.
They’re just making shit up. In their mind I guess Javascript that is intentionally included by an admin to customize their instance counts as ACE. In that sense any webserver you ever browse to is capable of ACE.
Any webserver you browse is possibly capable of ACE depending on the implementation. When it starts to hold user data is when that starts to be a big concern. The more points of entry, the more that needs to be secured.
I don’t have any experience with piefed admin, or any opinion on piefed itself, just too many years of web admin experience. And as soon as I see intentionally made doors that allow code input, I start to worry about how much experience the devs who made it have with web admin.
Booo. Here I was hoping for something serious to spice up the news and it just turns out it’s “it runs on a browser”.
I’m not a spice merchant, and most exploits rarely involve a single step. This screenshot is just a system design red flag.
You’re free to examine the repo yourself and find your own spice, my 5 min look tells me that piefed needs to expend a significant amount of effort on infosec to maintain user trust in the longer term.
Sorry, pal. It’s a good software.
As others have pointed out, it does still require (with some caveats about the infra setup) the user to be an admin. But if someone manages to get in to the interface, or another person is granted admin access who shouldn’t have been, it makes it more risky than it needs to be. It also for me is a design choice that indicates other parts of the system should be carefully examined for how they’re handling and sanitizing input.