[Cancelled]Dropbox Integration for Save File Synchronization

[papillon]

The other issue is that people are used to considering the risks in downloading and running a complete game, but not necessarily used to considering a save file as dangerous.

There are a lot of places that distribute, say, 100%CG-unlock saves for games, or saves with boosted stats in RPGs, and people don't generally consider them as dangerous in the same way they would a random exe. Neither would many anti-virus programs, I don't think.

[jack_norton]

Yes after reading Spiky post I agree (I didn't think about it before).
Better play safe - those great antivirus program already flag many games .exe as virus when is totally false, imagine if someone spread a virus through Ren'Py, it would be a disaster

[PyTom]

I've been thinking this over, trying to see if save synchronization could be made secure enough to be acceptable.

I think it should be possible to secure the save files against a malicious server operator. The way to do this would be to sign each savefile with information the server does not know, and hence can't forge.
I'm wondering if a warning - perhaps each time you load a synchronized file - would be enough to deal with the security problem. I think it would be possible to place an identifier in each save file, which we can check to see if the file was created locally. If it wasn't, we could issue the warning: "This save was not created locally. If the person or computer creating this save file is malicious, it could damage your computer. Are you sure you want to proceed?"

How is this handled for Magical Diary (and soon LLTQ)? Do those games not use Steam Cloud?

[Elmiwisa]

Ah I see. When I made the point about how people should already take precaution when playing a Ren'Py game, what I meant is that they would do some standard precautionary measure such as scanning for possible infection, playing only a new account with restricted access and no administrative privileges, pull off the Internet cable before starting the game, and do not store any personal information on the computer/phone. So no matter what the game does, either by itself or by loading a malicious save file, it could not possible cause any problems.
From the replies, seems like they are not as standard as I thought.

As for issue with file tampering on a server, how about you make it so that Ren'Py game will come with a new persistent variable or something. Whenever the player install a new game on multiple device, they need to input some sort of encryption key, which is stored into that persistent variable; and the player is supposed to enter the same key on all their copy of the game. When a game is saved, it automatically encrypt with that key. Then when the file is synchronized, the updated file is stored in a new location first. When the game attempt to load the save file, it check to see if a new version is available, then attempt to decrypt it, and load it. If the decryption and loading is successful, it is assumed that the file have not been tampered with (it game will probably crash if the file were tampered with, since after decryption most likely it will be full of nonsense data), in which case the game overwrite the old version.

[papillon]

If it wasn't, we could issue the warning: "This save was not created locally. If the person or computer creating this save file is malicious, it could damage your computer. Are you sure you want to proceed?"

How is this handled for Magical Diary (and soon LLTQ)? Do those games not use Steam Cloud?

We haven't actually touched the Steam Cloud, no. The only feature we've used is the achievements.

I'd probably consider a warning to be sufficient but Spiky cares more about this stuff than I do and was in the middle of doing a security audit on savegames for his own reasons before stumbling over this thread, so I'll wait for him to comment.

pull off the Internet cable before starting the game

If you play all your games on individually shielded computers that can't contact the internet, save cloud storage would be utterly useless to begin with.

[Spiky Caterpillar]

I think it should be possible to secure the save files against a malicious server operator. The way to do this would be to sign each savefile with information the server does not know, and hence can't forge.

Cryptographic signing would be an option, with the (big!) advantage of sticking the sanitization code in a single auditable place. The downside is that it introduces key generation/management problems, and, while it protects against a malicious server, it doesn't protect against the case where one of a player's computers has been compromised and the others are clean.

I'm wondering if a warning - perhaps each time you load a synchronized file - would be enough to deal with the security problem. I think it would be possible to place an identifier in each save file, which we can check to see if the file was created locally. If it wasn't, we could issue the warning: "This save was not created locally. If the person or computer creating this save file is malicious, it could damage your computer. Are you sure you want to proceed?"

A warning every single time you load a remote-created file isn't useful for save-sync systems, because then the normal user behaviour is going to be to click the big red PROCEED button for both saves produced on their other computers and saves injected by hostile third parties. You'd want each save to come with a public key and to cache the keys, SSH-style, so the scary warning only shows when trusting a new computer. This still leaves MITM vulnerability the FIRST time you trust each computer, but that can be alleviated with out-of-band key validation.

playing only a new account with restricted access and no administrative privileges

Some of us do, but an awful lot of players play with the same account they used to buy the game and most UIs in common use are oriented towards the assumption that all your programs have access to everything on your user account. For example, Steam launches all games in the same account (and, on Linux, assumes users are willing to grant root privileges to that account), and so many Windows programs assume that all files are writable by everyone that Microsoft decided kludging per-user filesystem views into the OS was a better idea than returning 'permission denied' errors when a process tries to write something it shouldn't.

Whenever the player install a new game on multiple device, they need to input some sort of encryption key, which is stored into that persistent variable; and the player is supposed to enter the same key on all their copy of the game. When a game is saved, it automatically encrypt with that key. Then when the file is synchronized, the updated file is stored in a new location first. When the game attempt to load the save file, it check to see if a new version is available, then attempt to decrypt it, and load it. If the decryption and loading is successful, it is assumed that the file have not been tampered with (it game will probably crash if the file were tampered with, since after decryption most likely it will be full of nonsense data), in which case the game overwrite the old version.

I like the notion of encrypting any save going over the network, but secure key generation and exchange is hard (in the sense of being a pain for players) - and, again, doesn't protect against the case where one of the computers producing saves is compromised.

Saves on the local machine probably should not be encrypted - I don't like the notion of losing my saves because I forgot my encryption key, that would suck.

I'm also not sure what legal restrictions would apply to distributing open-source encryption modules in conjunction with a closed source game from our respective countries. Anything we distribute has to be export-legal from both .us and .uk.