And no, we cannot safely allow mutators that haven't been whitelisted any access to the perk code.
If you do a search I believe Xienen has done a more detailed explanation post on this exact subject.
Indeed he has, but if memory serves the explanation was a bit underwhelming. If I recall, my interpretation of it strongly implied that the Steam connection code is entirely within UScript, which might've been simpler to implement at the time but doesn't sound like a sensible decision from a security perspective. I know he did say that connections to Steam stats and achievements servers can't be flagged "read-only", and in a choice between letting questionable mutators send write requests unrestricted and denying the connection altogether, the latter is obviously superior, but it begs the question of why UScript code can access the connection in the first place.
If there is any particular reason why the following is not possible to do, or for that matter has already been done but for some reason is impossible to secure, then I apologise in advance; but I would've thought the more robust solution in the long term would be to implement the Steam connection subsystem entirely in native code, providing UScript access via a very restrictive API, the native implementation of which could silently discard write requests at its own leisure without them ever reaching the connection itself. The native module would interact with the whitelist checking and other validation code (which I assume is already native) to determine whether or not to honour write requests. Meanwhile the UScript definition of its "class" would merely provide simple "read" and "write" functions, along with another function returning a Boolean to indicate whether or not the latter will actually do anything (e.g. for the interface code, so it can report a more accurate message about why perk progress won't be saved). With this strict encapsulation scheme in force, the only way for UScript code to write to the Steam connection would be through a native layer that would dishonour all write requests in non-whitelisted environments, so dodgy mutators on Bob's Whorehouse could say "give me 60 million fire damage pls" all they like, but it would never amount to anything.
If for some reason the above is not feasible, I'd be curious to know why.
EDIT: And I do realise that changing from an entirely UScript implementation to the one described above would constitute a significant amount of work, but I honestly think it'd be worth it.
EDIT 2: And by "simple read and write functions" I mean "read and write progress for X perk", not "read and write TCP streams", since the latter is obviously an implementation detail with which the UScript side needn't concern itself.
