Lemma Soft Forums

For a while I've considered adding some sort of save-file sync system to Ren'Py. The vision I have is being on a position where I can save a game on my desktop, load that save on my tablet, save again when I'm done with the train ride, and then load the game again on my laptop when I get to my destination. What's been holding me back is that this requires a web service component, and I don't really want to have to run that myself.

I'm considering integrating support for Dropbox into Ren'Py. The idea is that Ren'Py games could choose to display a Dropbox button. When that button is chosen, Ren'Py will open a page on Dropboxes's website, allowing players to log in. Once logged in, the player will be given a code that they can type into Ren'Py to finish the connection.

Once connected, saves will be both saved locally and uploaded to the server. Loading would be done from the dropbox-hosted file or the local file, whichever is newer.

This wouldn't require any software beyond Ren'Py, as there's a simple MIT-licensed dropbox client I could include as part of Ren'Py. It would be secure - Ren'Py would never see your Dropbox password, and the token Dropbox gives us would be limited to accessing Ren'Py-related files. And it would be opt in - if you don't enable Dropbox support, Ren'Py would not behave any differently than it does today.

I'm not sure I like tying Ren'Py to a commercial service - but I don't think it is a huge problem in this case. Games would keep working if Dropbox went down, but would be limited to being saved locally.

What do people think? Are there reasoned objections to this plan? Would you use it? (I don't want to spend time on code nobody else would use.)

Hi PyTom,

I don't see any negative effects about this idea. I personally am a dropbox user and i also find it somehow frustrating that i can't combine my saves from tablet/smartphone with the desktop version of the game.

I totally like the idea and would use this feature

Several of my users asked such a feature, so for sure if you do it, I would add it to my games

If there is nothing negative to RenPy, yeah, why not? It would be a good feature for RenPy. BTW, Dropbox would allow us doing this, right? Using their service to save games?

LVUER wrote:If there is nothing negative to RenPy, yeah, why not? It would be a good feature for RenPy. BTW, Dropbox would allow us doing this, right? Using their service to save games?

I'll have to submit it for approval, but I think they'll allow it.

The big question in my mind is if they'll allow us to use one app id for all Ren'Py games, or if each game will need to go through the dropbox approval process separately. I'd like to offer people the choice of enabling for a single game and enabling for all Ren'Py games - but that may or may not be possible.

Not talking a centralised location here, but a player's own Dropbox account?

Sslaxx wrote:Not talking a centralised location here, but a player's own Dropbox account?

Yes.

More specifically, Dropbox has the idea of an "App Directory". So a Ren'Py game would have access to its save files, and those from other Ren'Py games, but not the other contents of your account.

I'd have no access to the saves at all, unless you chose to send them to me for some reason.

PyTom wrote: The big question in my mind is if they'll allow us to use one app id for all Ren'Py games, or if each game will need to go through the dropbox approval process separately. I'd like to offer people the choice of enabling for a single game and enabling for all Ren'Py games - but that may or may not be possible.

Eh...sorry for a technical concern here. But Ren'Py is open source right? And each game is a standalone isn't it? So each game that is made with Ren'Py, in theory, could have modified the engine to such a huge extend that they might be fundamentally different from how a Ren'Py is supposed to function, up to and including how file access work. So it just seem to me that, while more convenient, it just won't make sense for a single approval to be allowed for all Ren'Py games.

That's an issue with all open-source things, though. There's nothing stopping someone from taking an approved game and modifying the code after it's been released.

This is really Dropbox's problem - the implementation looks pretty simple, so I'll probably just write the code and submit it to them, and see what they say. The worst they can say is "No", in which case I'm out a little bit of work. (Or I could move on to Google Drive or some other service.)

I'm against this idea simply because of reasons stated on IRC. It seems like it could be vulnerable, and I don't like the idea of affiliating RenPy with a cloud service.

If someone wants to back up their saves, there's nothing stopping them already. Why waste time with a completely new feature?

A Ren'Py savegame can execute arbitrary code when loaded (which is why you should never load a save that someone else gave you outside a sandboxed account). Storing them on a central server would, at a minimum, give the server operator the ability to take over the (desktop, not dropbox or wherever!) account you're playing the games under by modifying your saves.

Savegame exchange requires hardening the load/save mechanism so that it can no longer execute arbitrary code. I'm working on a hardened load system for Black Closet, but it is currently nowhere near finished, and I expect it to be a lot more brittle than the insecure load currently used. (For example, my custom classes require a bunch of explicit hooks to sanitize the data being loaded). It's also a rather large undertaking, and I'm not at all confident that I'll be able to catch every single potential code-execution vulnerability.

While I'd consider adding optional online save/persistent data exchange to my games, I'm personally not comfortable depending on servers that I don't control myself - so even if I were implementing save sharing, I wouldn't use a Dropbox backend.

I'm all for it. It's completely optional, so if people are upset with it they don't have to use it. I know I'd use it for sure.

I think Spiky is totally right about this. Since (maliciously created) Ren'Py save files can execute python code, we have a problem - if either the server or one of the user's computers gets compromised, the save sync system could compromise all of the computers in the synchronization group. I guess I could try to deal with this by warning the user - but if a user didn't understand the warning, and had their system compromised this way, I'd feel terrible.

I don't see any way to change the savefile format without making Ren'Py significantly less flexible. And so, I don't think we can have save-sync support, to dropbox or elsewhere.

I'd like to thank Spiky for a reasoned analysis that saved me from making a huge mistake.

Wait a minute... I thought that everyone are already supposed to take precaution against malicious code for simply downloading a game from this forum at all, even if the games are made with Ren'Py? After all, Ren'Py is so flexible that it can be patched into anything, so pretty much any games downloaded from here, whether Ren'Py or not, should be considered to be a fully functional programme. There is nothing to prevent a game posted here from being compromised in advanced by say, a computer virus on the creator's computer, or perhaps because the creator is purposefully making a game that is a virus. And since everyone already took the precaution, the issue with the danger of save files is moot.
Perhaps in the future, maybe Ren'Py will be made more secure so that games made with Ren'Py is literally incapable of causing problem, then that automatically will handle any problems with the save files right?

Sure. And I think it's historically been reasonable to trust creators with a reputation. What's new here is that the save-sync system would turn Ren'Py into an infection vector. So with save-sync, you could have:

1) Computer A is compromised by a virus that infects Ren'Py save files.
2) Save-Sync moves the infected files over to computer B.
3) The user loads the save on computer B, and computer B becomes infected.

I go back and forth as to if this is a risk I could plausibly ask people to choose to accept.