Poncho28 wrote: »

Just a recommendation if ZOS isn't already doing this, but a client-side save of our account database (DB) would be helpful. Every time we log in we could accept an account save here [C:\Program Files (x86)\Zenimax Online\The Elder Scrolls Online\game\client]. It could be hashed with a 256 bit key to maintain integrity (some users would try to break their DB and rewrite their account). This way if the server ever loses our account, we'd have a local copy just in case.

Anyways, thanks for reading.

I'm not sure if you are aware, but a lot of data used to be stored client side. It was... not good.

There's a reason our characters are stored server side now.

sarahthes wrote: »

Poncho28 wrote: »

Just a recommendation if ZOS isn't already doing this, but a client-side save of our account database (DB) would be helpful. Every time we log in we could accept an account save here [C:\Program Files (x86)\Zenimax Online\The Elder Scrolls Online\game\client]. It could be hashed with a 256 bit key to maintain integrity (some users would try to break their DB and rewrite their account). This way if the server ever loses our account, we'd have a local copy just in case.

Anyways, thanks for reading.

I'm not sure if you are aware, but a lot of data used to be stored client side. It was... not good.

There's a reason our characters are stored server side now.

Yes, am aware and thank you for bringing that up. I believe it was way back during v1.6 where bots were floating through the air to harvest nodes.

I was wondering if there was a way where a client-side save could be achieved using a hash standard to protect the integrity of our save. e.g., a local copy would have to be used, a hash is provided to ZOS, ZOS compares the hash with their copy of the hash, if the XOR result checks out then the local copy is allowed to be used for login and use (rewrite on ZOS' side).

https://csrc.nist.gov/Projects/cryptographic-standards-and-guidelines

Just a thought.

Unfortunately, there's an old saying in programming "Never trust user input" That extends to User data as well. you can employ all the hashing, XORing and double checking in the world, but someone somewhere is guaranteed to find an exploit and use it to inject malicious data in to the pipe somewhere.

The old Meme of the school child who's father named him Robert'); DROP TABLE Students;-- has truth to it.

While it's a pain in the butt on the surface from our perspective, it's an even bigger pain in the butt pumping compute resources on both ends in to constantly validating, sanitizing and checking data sets only to one day discover it was all for naught because some clever cookie found a way to inject something that lets them slip bad data in under the radar anyway (See previous threads on the great bot plague) - when you can do less compute intensive work by negating the need to do so in the first place. Server side data processing and storage is more secure overall and foregoes the need for all those checks from the start.

There's probably already a lot of processing going on to sanity check the incoming message buffer from the client as it is.
(at least I hope there is...)

ragnarok6644b14_ESO wrote: »

It was fine - the reason they turned that off was to be the flagship game for Stadia (which didn't allow client side processing or storage for obvious reasons).

Changing combat processing and systems just to support Stadia was one of the worst decisions imo.

The reason it was turned off was because cheating was rampant in Cyrodiil and I suppose in the PvE zones as well. Players flying around dropping unlimited comets on the battlefield tended to be not much fun.