Request: sv_debug Flag and Client Debug Mode

Hello there,

currently (at least in the german userbase) it became a common thing to use the NUI Devtools to steal resources and designs.

Some other modification™ restricts the usage of development tools (Console, WebView Console, etc) by setting a flag on the server and client. In that case, when the client and server haven’t set (eg.) sv_debug, those features are unavailable.

Example Implementation #1:
This behavior could be implemented by adding a setting to the client (debug mode) and a flag (sv_debug) to the server.

If the client has debug mode enabled and connects to a server with sv_debug disabled, the connection is rejected.

If only the server has the debug option enabled, the connection is continued, but the client still has no access to the debugging functions.

Only if both parties (server and client) have the debugging option enabled can the debugging and development tools.

Example Implementation #2:
Another way of implementing this would be by adding specific permissions for using devtools.
I don’t know whether this would be possible, as those restrictions would probably already have to take effect on the connection initialization.

2 Likes

Thats a good Idea!

(20 Chars)

5 Likes

No. Why? You’ll only see people selling ‘devtools bypasses’ and such in response to this kind of misfeature, and then the next feature request will be ‘please fix devtools bypass’ as you’ll have been lulled into a false sense of security by a toggle existing.

Are you asking the same thing from browser vendors? ‘Please disable F12, people can “steal” my content!!’

4 Likes

People selling bypasses would actually be better then the situation right now. Everyone can access it for free, that way they would need to buy the bypass at least. This and the request I made about the dumping is nothing what you can just ignore or say things Like “they’ll Always have a way to do it” and yes, they will but why would you want to make it that easy? It has no worth in building your server when everyone just copy’s from it.
Cheers.

3 Likes

And by then ‘everyone’ will as well, except now you’ve made a black market of ‘leaks’ into even more of a black market.

Do things server-sided using game state natives. There’s hardly any need nowadays for doing non-UI code on the client.

5 Likes

Just because there will be people who would write workarounds for this, isn’t it necessary to implement such simple “security measures”? There are already security methods implemented for resources, such as encrypted cache / rpfs. So why not implement something for NUI as well.

Some people put a lot of work into their UIs - or even hire a designer for that. In the current state, one could just go ahead, open the CEF’s Developer Console and grab what he needs.

Currently it is served on a silver platter (together with some resource dumpers) according to the motto “take what you need”.

1 Like

Good Thing +1

1 Like

That’s the case with any website though.

1 Like

Of course thats the case with any website - and I’m very well aware of that. But what’s the point of making half part of it inaccessible and completely ignoring the other part? Why is it such a big issue, to restrict certain commands and tools (which are intended for developers) to the nomal user - or give the server operator to do such at his discretion?

Yes, it’s CEF. It’s a webbrowser in a game. But it’s mostly used for in-game assets/ui, so it should be treated as such - just like you encrypt the cache and rpfs. Why are y’all making this such a big deal that it’s not possible to do so, if it clearly is - and seemingly works on other, comparable modifications?

Because it doesn’t provide a real use and makes actual development take additional steps to do. And this isn’t even a question that should be answered by anyone here as this is a legal issue and not an issue of “ow he stole my shit!!! cfx fix pls!!!”. Literally no one cares but the server owners themselves.

If your NUI related browser stuff is so important to you, maybe, just maybe don’t put it somewhere where someone can “steal” it.

1 Like

Okay, and the community of FiveM is built upon server owners, which take the time and money to start such project just to get everything stolen by some script kiddo with a cheap resource dumper and some included, openly available tools directly included into FiveM. It just looks that you welcome such behaviour - if so, why even care about encrypting the cache - just reenable the included lua executor then.

I would guess sending a DMCA takedown (or the legal pendant in the country of the requester) wouldn’t do much either. I can indeed imagine that they would then be rejected on the grounds that Cfx only provides the platform, but each server owner is responsible for their servers alone. Unfortunately, there are also no tangible operators for many servers, so contacting them is also impossible. Feel free to correct me if I am wrong.

I really don’t want to cause “controversy” or sound aggressive here (English is not my native language), but I don’t really understand the procedure and the reasoning behind it. Why is something like this not at least made more difficult? Of course, there will be people who try to bypass the mechanism, but you can at least make it more difficult at first instead of serving everything on a silver platter.

2 Likes

This was in a much simpler time, before there was any black market for infinite (re)sale of cheating tools. That specific ‘security method’ is also long-since ‘bypassed’, and same goes for any updates to it.

It, again, also serves to give people a ‘false sense of security’, as would this. It only hasn’t been removed because it would invalidate existing on-disk cache, and make existing servers incompatible with updated clients, both of which are not a viable choice to make.

The point is, as said above, that at the time it was deemed a sensible option. The landscape changed, and now neither are sensible, but removing the old cache obfuscation is not viable.

Then go to these ‘comparable modifications’ if they’re so comparable and they serve your needs better.

Nobody even said this is ‘impossible’, we could easily do this, but a) the way you suggested is, suffice it to say, completely retarded (convoluted, unneeded, the brainchild of a person with worms for brains perhaps - it sounds an awful lot like a half-solution some other ‘competitor’ attempts would have implemented), and b) we won’t, as it would serve no goal other than lead to a false sense of security, and only lead to chances of regressions, which lead to idiots crying ‘stuff is broken’; bypasses, which lead to idiots crying ‘omg fix bypass’; it’d take time, which already is highly scarce; all in all there’s more downsides to implementing any such change (where we still won’t ‘lol restrict devtools fully’ based on a server variable, that’s just dumb as shit, at best we’d just disable nui:// from fetching assets from resources without ui_page if that’s not a thing yet as this is how random ‘dumpers’ work, but even that’d break compatibility perhaps with some resource on some private server of some streamer in a country where nobody speaks English).

As above, the only reason ‘we encrypt the cache/rpfs’ is a decision made based on the landscape four years ago, that would be hard to revert compatibly. There’s a gazillion parsers that bypass this as well as allowing downloading directly from a joined server, that would also be impossible to ‘fix’ compatibly, as well as lead to the same risk of regressions, continued bypasses and time-wasting as your precious feature would.

In the end, no matter what is done, nobody will be happy.

Again, let’s reiterate the scenarios for your feature:

  1. We implement this, you’re happy, but it regresses for a week, users will be crying in our fucking faces for a week while we hurry to figure out what went wrong but don’t have any repro as it only breaks on some rando-shit servers that we don’t have access to with the owners and players only being able to write in moon runes.
  2. We implement this, it works, you’re happy, but there’s a bypass, and people (maybe even you) will cry that we should add more anticheat for this bypass, which we might, but it regresses and leads to daily crying of ‘omg false baaaaaaan cfx we will sue you! you suck so hard’ without any way to reproduce.
  3. We don’t do this, and only you and the community you sent to vote-brigade this issue complain, but we’re saved from the risk of having crying from everyone else except every few weeks this topic comes up and we can just say ‘nah, this is intentional’ and 90% of people asking just don’t ask again.

See, not changing anything is the ideal solution.

2 Likes

Also, again, you do really sound aggressive in the end, even if you’re not trying to.

We don’t ‘care about encrypting the cache’, this code is unchanged since 2016 except for a few fixes for performance and DoS issues caused directly by it. It’s easier to keep it than to remove it.

Re-enabling the built-in executor is intended at some point in the future when there’s a common framework for people to use that does state routing validation server-sided and enforced entity lockdown, for the time being it was only disabled as a crazy fuckton of retards came crying and started spreading crackpot theories and insults all over everywhere, and it didn’t have the desired effect of stopping the sale of illicit hacks either.

Stolen would imply it’s no longer on your server. Plagiarized, maybe, but by then you can trivially report violation of your copyright to, say, support@fivem.net and the relevant server will get blocklisted.

That’s why support@fivem.net was originally opened: license violations, not for the insane amounts of misguided spam it is getting now from the world’s most likely Darwin Award candidates.

Similarly, this project was started to have an open sharing-based community where people shared content and competed based upon data, not the current way-too-popular layer atop a series of black market content releaking, infinite foreign players, abusers and the likes, in an ecosystem where a billion of people started ‘MP mods’ after us but instead of working with us they started their own projects plagiarizing large portions of our code disregarding any current and former license terms, keeping all their code to themselves, and being completely unwilling to cooperate, forcing us to ‘compete’ and constantly be ‘compared’ to other mods, and getting infinite crying when we do something, when we don’t do something, when we do something wrongly, when we don’t know about something that happens in the ‘RP’ community, and where everything somehow has to be about money.

As to that latter point, I know you’re going to mention ‘hurr but the Patreon stuff’ - note this was only introduced 2 years in as a final ‘giving in’ to the fact the community didn’t give a rat’s ass about sharing but only wanted to illicitly profit off of the project without giving anything back content-wise, money-wise or anything-wise except for crying, crying and crying.

2 Likes

I actually posted the link to this thread only in one discord server that was created by me and some others for server operators in the D-A-CH region - mainly for exchange and mutual help.

I noticed that - and I really understand the reaction, especially when you have to deal with such idiots every day. Even if the whole thing didn’t have the desired effect, I probably wouldn’t have reacted differently. :'D

That was actually the final part of my previous answer. I didn’t think that in this case there would actually be a reaction, because on other platforms (not even necessarily GTA) they simply respond with the statement that you should contact the (sometimes intangible) server operator directly. Thank you for clarifing this, I’ll gladly make use of it. Are there any requirements what I should put into that e-mail, except proof and the offending servers IP?

I wouldn’t have actually mentioned the Patreon stuff. I had supported the project for several months (also independently of the Element Club Perks) and would do so again as soon as my financial means allow it. I really appreciate your work on FiveM and I’m willing to pay a little money for it every month.

All in all, thank you for the time and the detailed explanation of your position on this issue. :slight_smile:

1 Like

On a closing note, I’d like to mention that if there were a cleaner solution to allow individuals to detect and prevent plagiarism, it’d be offered quite easily. There’s one simple act, namely that a server owner can’t reuse content if the base FiveM client rejects it loading on a server it “doesn’t belong to”.

The only thing precluding such a ‘clean solution’ from existing is that detecting plagiarized content, even if the target makes small alterations, is a bit of a hard-to-solve problem that has companies exist dedicated to this kind of task. There might be a quick trick for this, but none comes to find at this time.

2 Likes

Typically not, an easy way to verify said proof would be nice, but generally, given the level playing field regarding downloading of instant assets the issue you so much want fixed actually makes it easier to verify if someone is in fact using plagiarized content.

This might happen if the ‘original author’ of the asset is hard to determine, since this kind of complaint is oftentimes made to get ‘back’ at someone.

Some sort of asset history tracking would definitely have been a cute feature, but so far a tad difficult to implement cleanly.

On that note, this should turn into a work item to have a tad cleaner workflow for blocking a server - I’m wondering if we could have a warning timer, perhaps… ah, another change for the new svkey backend.

2 Likes

Once again, thank you very much for the detailed explanation of the position and the time invested in this topic. After the breakdown of the individual elements, it was actually understandable for me why such a feature cannot be implemented or why it doesn’t make sense to implement such.

Asset tracking would actually be nice-to-have, especially for such cases. Again, the implementation is a big task that takes time - full understanding that this cannot and will not happen right away. Thanks a lot for the insight into future plans and for the time invested in general at FiveM.

In this regard, I think that the topic can be closed. Thanks :slight_smile:

1 Like