[Quekid5]

AFAICT there's nothing inherently insecure about server-encrypted data on the client. You have to secure that encryption, but fundamentally it Should Be Fine(TM).

Now, deserializing arbitrary objects which might contain code?... that's crazy town, but it was a different time.

[mjevans]

This is an area where 'fine' rapidly becomes problematic.

Remember that the dataset is often going to be small, and frequently will contain known or easily guessed strings. Uncompressed, often at predicable locations.

There are whole classes of cryptographic vulnerabilities which might result from either not compressing (compression should in theory would normalize entropy over the stream) or using a compression algorithm that results in a predictable dictionary, length, or other value in the same location (if junk padding isn't used properly).

Also, sending the state from client to server might open replay attacks and all sorts of other horrid situations.

Security depends on doing everything correctly all the time; this context IMO just feels open to too many plausible and unknown (potentially introduced in the future) vulnerabilities.

[Quekid5]

> Remember that the dataset is often going to be small, and frequently will contain known or easily guessed strings.

This is why modern crypto is designed to be resistant to prefix attacks, rainbow attacks, why CBC is considered a good idea, etc. soo....

Yeah, you're being paranoid about the wrong things, I think.

EDIT: FWIW, I was being a bit cheeky with the Fine(TM) thing, but if you get the "process" bits about encrypting the thing you send to the browser (and will be returned to you) right, you should really be in a position about as good as if the encryption itself had been compromised.