Sandboxing (poll)

[slime]

Yes. LÖVE is designed for games. Games should do no evil.

That's right, but LÖVE is good for other things too.

SFML is designed for games but can do other things (it's essentially a lower level LÖVE, AFAIK), and to my knowledge it has none of sort of sandboxing discussed in this thread.

[Rad3k]

SFML is designed for games but can do other things (it's essentially a lower level LÖVE, AFAIK), and to my knowledge it has none of sort of sandboxing discussed in this thread.

To my knowledge, LÖVE is not SFML. Also, SFML is for C++, which means that the only form of distributing ready-to-use applications is through binary executables, so the idea of sandboxing just doesn't apply there. SFML (unlike LÖVE) doesn't have any kind of official player for games made with it, so there is no control over what the game does, unless you sandbox it on the OS level.

But this is all irrelevant. Do you see any problems with the solution I proposed?

[Taehl]

What if Love was sandboxed in every aspect by default, but any Love app could request any part of the sandbox to be removed - at which point, Love would pop up a window saying what the app was requesting and asking the user's permission for it.

I suppose to keep the permission window from getting annoying, Love could save the user's answer with the checksum of the .love file, and maybe have an option (disabled by default) to automatically accept all sandbox-removal requests. Or something like that.

[Robin]

What if Love was sandboxed in every aspect by default, but any Love app could request any part of the sandbox to be removed - at which point, Love would pop up a window saying what the app was requesting and asking the user's permission for it.

That is exactly what I plan on putting in SELÖVE. Although not every part is removable --- the debug library, for instance, could be used for privilege escalation.

[Xkeeper]

I say no. It's nice to see that the debate is fairly even, though.

Among other reasons, I sometimes use LOVE for things that aren't games. It's a very simple interface to graphics, sound, and similar libraries without having to do a lot of work. All of this prompting/requesting/acknowledging crap has already been done (it's called Windows Vista and nobody ever talks about it for that reason); it gets in the way, and...

Let's just say that you wanted to download a level from Teh Internets. If you wanted to save this level (because it was fairly large, for caching, whatever)... Surprise! You just interrupted your user with a warning dialog because a file was saved.


I was under the impression that LOVE already restricted file access to the directory the game was running in anyway. Is that different or not working now?



On a side note, with LOVE being open-source and under a permissible license, if you say "It's sandboxed!", nothing will stop anybody from releasing a simple LOVE game using a custom EXE tacked on that has the sandboxing stripped out. And they would be able to say "Well, it's LOVE, so it's sandboxed!" When you make no assumptions none of this is possible.




In all honesty I don't think it is worth the trouble. Restricting the things someone can do because of an assumed possibility (that can easily be exploited in a billion different languages, no less) just feels like a mess.

Wow, this post was all over the place.

[Robin]

Among other reasons, I sometimes use LOVE for things that aren't games.

I can see why this is useful for you, but LÖVE is primarily for making games. You can't surprised if the devs decide to ignore the periphery audience.

I was under the impression that LOVE already restricted file access to the directory the game was running in anyway. Is that different or not working now?

If you use the Lua io library, you still have access to the rest of the file system. SELÖVE removes access to that, though.

On a side note, with LOVE being open-source and under a permissible license, if you say "It's sandboxed!", nothing will stop anybody from releasing a simple LOVE game using a custom EXE tacked on that has the sandboxing stripped out. And they would be able to say "Well, it's LOVE, so it's sandboxed!" When you make no assumptions none of this is possible.

This is why I am in favour of the platform model: LÖVE lends itself so well to it. Everyone downloads LÖVE from a trusted source, and downloads .loves as if they were smart phone apps, without having worry it will mess up their computer. (Malware does exist around here, only few people have noticed.)

[slime]

On a side note, with LOVE being open-source and under a permissible license, if you say "It's sandboxed!", nothing will stop anybody from releasing a simple LOVE game using a custom EXE tacked on that has the sandboxing stripped out. And they would be able to say "Well, it's LOVE, so it's sandboxed!" When you make no assumptions none of this is possible.

This is why I am in favour of the platform model: LÖVE lends itself so well to it. Everyone downloads LÖVE from a trusted source, and downloads .loves as if they were smart phone apps, without having worry it will mess up their computer. (Malware does exist around here, only few people have noticed.)

That might work for your regular game here that someone makes and gets < 50 downloads, but what about something like mari0? It's not fair to ask people to download a program to run the game that they already downloaded, especially if all the program does is run the game. That model won't work well at all on platforms like Steam or the Mac App Store (i.e. real distribution places), either.

[bartbes]

If you'd actually knew what robin's standpoint was, that'd help. I actually agree with him.

Basically, he's saying that as long as it's a random .love file found here (or elsewhere), you should be able to run it safely within love (but I reserve this role for selove). He's not saying everything needs a dialog asking for permissions, he's saying a game needs to ask for permissions once, when it tries to not use love's api. (Something like the io library, networking possibly, but standard stuff like love.filesystem or love.graphics won't need a dialog.)
Of course, he also knows that once you distribute as a .exe all bets are off. But that's with any system, you can't ever see whether a .exe does what it says on the tin.

[Robin]

Thank you, bartbes, that is exactly my position on this.

[Xkeeper]

I guess a decent compromise would be to have something in conf.lua that sets variables if it will need "sandboxed" privileges later, and LOVE can present a dialog box before starting the file or whatever.

Combined with saving the result somewhere it should be sufficiently out-of-the-way enough to not be a massive pain.