heh, I've got a box of fun but after some close/won't fix's/rejected (example 1727, which was reject/merged and still exists as a bug last I tested, over a 8 months later and has existed since time immemorial) I don't really see the point in reporting any more (including some high P server security issues).
Straw for me was "well in theory it is a issue, but"
"Closed, Duplicate" is the correct status for this.
This means:
We close this report, because we already have a report covering exactly this.
I assume the really bad wont fix you talk about is:
T1740 - Local client chunk cache files can be used to reconstruct entities seen on multiplayer
Well, it is a multiplayer game, you already upload your blueprint to the server, and they can in theory also get it.
Reconstructing a ship from local client cache is in theory possible, but will miss
all information about links, weapon grouping, logic, display modules and settings.
And as you most likely wish your client displaying the ship to other users, those clients will need to know the raw block data to render it.
So there are two approaches to fix this:
a) encrypt all raw blockdata sent to clients with a specifc key and give this key to the client for a short time to load the ship and have it in memory, then make sure the key does not work any more.
- + you cannot reconstruct the blueprint from the local cache anymore without excessive computing power
- - blockdata is still in the client memory and can be grabbed from there
- - sending encrypted data + key to client does not increase security at all just adds another detour and impact in performance
b) convert blueprints to models before sending
- + raw blockdata is never sent to client and all functionality can be obfuscated
- - ANY ingame editing of ships will be limited to only apply for new copies, you cannot edit the ship on the fly anymore
- - damage "block by block" is not possible any more
- - a complex light setup with different states by logic may require a thousand different model variants being sent to the client to cover all possible situations (or alternatively: disable all dynamic content on the ships...)
So I still back this decision to not fix this.
As a) would not stop anyone with enough knowledge and effort to grab the data
and we can not prevent it to be on the client in any way without using b).
Is that the one where you spit out your credentials to the server?
Never heard about this,
did anyone report it?
By design the credentials are not sent to the server at any time (OAuth2 if you want to read more about it).
Feel free to contact me if you have any details on this.
- Andy
