LÖVE

BlackBulletIV: I don't think you thought through the problem very much before replying.

BlackBulletIV wrote: You're treating Love as if it's a gaming platform, not a framework for game development. There's a big difference between the two. Frameworks just provide services, like worrying about how to draw graphics, or use physics, but don't limit the developer from doing something outside of the scope of the framework. Imagine if SDL suddenly turned around and asked the user if the program could do a certain operation, or if Unity3D sandboxed the game developer from accessing the internet or files outside of a certain region without extra permission? I don't imagine a good response.

I don't think your mentioning of the difference between a "platform" and a "framework" really helps the sandboxing debate. Look at LÖVE for what it is, rather than what it is called. It is a program that is tailored for game creation that rather conveniently executes .love files. I have used SDL and I have used LÖVE for programming. No matter what words people assign to them to describe them; they are very different. It would feel very silly if SDL " asked the user if the program could do a certain operation"... I agree; but if LÖVE did it, it seems perfectly reasonable to me as both a user and a developer.

BlackBulletIV wrote:

akima wrote:Java has this feature and so does Adobe Flash.

Indeed, Java does have sandboxing, but no where near the level proposed. Java doesn't go asking the user for network and file access! As far as I know the main thing it does is protect from operations that are most likely to be really dangerous, like raw memory manipulation.

Perhaps I wasn't being clear enough about what element of Java I was referring to. I was talking about Java Applets. Which have precisely the level proposed. An Unsigned Java Applet is strictly caged into a security sandbox where theoretically any executing program cannot cause any damage to the user's computer or break their privacy. It's comparable to JavaScript running on a HTML page. A signed applet prompts the user before execution effectively "asking the user for network and file access"
https://secure.wikimedia.org/wikipedia/ ... t#Unsigned
https://secure.wikimedia.org/wikipedia/ ... let#Signed

BlackBulletIV wrote: Flash has a sandbox, because it's in the browser. The browser is a completely different field of play to the desktop, and requires much more security. If Love is able to get into the browser, a sandbox will be needed for that environment.

I do agree that security is very important for a program like Adobe Flash Player; more so than a program (like LÖVE) which can't be trigured into executing code by an arbitary website. But! the security sandboxing mechanisms offered by flash can still be very beneficial for LÖVE users. .love files will most likely be distributed from the web.

I think the whole idea of an entire game being packaged into a self-contained .love file is fantastic, and that feature should be exploited. Just install LÖVE and then download and double click a .love file to play it. It's a bit like an mp3 or a pdf or a .avi. It just so happens those 3 mentioned formats are reasonably safe to download and double click. I like the idea of LÖVE games being the same. Download and double click!

BlackBulletIV wrote: Have you heard of merged executables? (If not, see Game_Distribution) This shows again that Love is not a gaming platform. Imagine how out of place it would be if the game, fully enclosed in an executable (meaning the user has no idea it's being run by Love), suddenly popped up asking for permissions. This is totally unnatural for (at least seemingly) stand-alone games. The user will probably may get annoyed by the interruption, thinking "I've already given this thing permissions through the operating system!"

I consider most problems as just... problems... with a practical solution. I don't think "imagine this horrible scenario". I think "how can I make this work." The problem you just described has a simple solution. Merged executables, when built will have LÖVE security sandboxing features disabled by default. I can think of lots of ways of implementing this really cleanly. This is the best of both worlds.

BlackBulletIV wrote:

akima wrote:It isn't sensible for the user to trust games from a given website.

akima wrote:It isn't sensible for a user to trust a particular developer.

Indeed, it's not sensible for someone to run an executable from someone that has given little proof they're serious. It's almost always easy to tell when someone may have something malicious in their game, there might be little information, or it's a pirated game; those are the usual candidates for malicious code. But why do you trust the many game developers that have made their game in C++ which has no sandbox whatsoever? I know I would because of the amount information, and the reviews.

"Trust" in this context could extend to a very lengthy debate, but I will mention a few points to think about.

1. "But why do you trust the many game developers that have made their game in C++". I don't always trust developers who have made their game in C++. Sometimes I wont install a game on account of this. People don't have to aim for the lowest common denominator. Why not improve upon a standard practice?

• When I buy a game which is distributed as an executable file, some trust can be assigned to the developer on the basis that there is a money paper trail. It would be very difficult to sell a game and at the same time hide your identity. I wont go into the reasons why, but just think about it. Setting up a bank account / trying to find an intermediary willing to take heat for any dodgy activities you do on his/her account. If anonymity is removed some trust is gained. So I can assign some trust to some executables when I pay for them.

I'm not developing LÖVE so I wont be adding security sandboxing. As a gamer and a LÖVE-game developer I would personally like to see security sandboxing at some point in the future. My thoughts are that security sandboxing should be able to be added to LÖVE without loosing any of the freedom LÖVE currently offers to game developers and loosing the user-friendliness that LÖVE currently offers to users/gamers.

Actually, I'm thinking of an intermediate solution, which would require no sandboxing, but would handle the anonymity issues. What if we could sign .loves? This wouldn't make it more secure, but if you see a package signed by someone you trust (like the LÖVE devs, you're running our code anyway, aren't you? ), you'll be safe.

So basically, it's just a way of knowing who wrote it the game, for sure.

akima wrote:I think the whole idea of an entire game being packaged into a self-contained .love file is fantastic, and that feature should be exploited. Just install LÖVE and then download and double click a .love file to play it. It's a bit like an mp3 or a pdf or a .avi. It just so happens those 3 mentioned formats are reasonably safe to download and double click. I like the idea of LÖVE games being the same. Download and double click!

My thoughts exactly!

akima wrote:Merged executables, when built will have LÖVE security sandboxing features disabled by default.

I like this. Especially since we can still treat them as .loves and give them to sandboxed LÖVE if we want.

bartbes wrote:Actually, I'm thinking of an intermediate solution, which would require no sandboxing, but would handle the anonymity issues. What if we could sign .loves?

Interesting. Very interesting.

akima: Hmmmmm... I see what you're saying. (But trust me, I did think about the problem for awhile) Most of my post was targeting merged executables, but if it were disabled, and the user could be asked when running a .love file for special permissions, I'd be cool. A .love file is a bit more... "platformish".

Now, answering some specific points:

akima wrote:I don't think your mentioning the difference between a "platform" and a "framework" really helps the sandboxing debate. Look at LÖVE for what it is, rather than what it is called. It is a program that tailored for game creation that rather conveniently executes .love files. I have used SDL and I have used LÖVE for programming. No matter what words people assign to them to describe them; they are very different. It would feel very silly if SDL " asked the user if the program could do a certain operation"... I agree; but if LÖVE did it, it seems perfectly reasonable to me as both a user and a developer.

I was talking about it in the context of merged executables (which as I just mentioned was the main aim of my post). It would seem just as stupid as for a merged executable to ask for permissions as it would for SDL; to the user they both look the same. A .love file however, is a different story.

akima wrote:Perhaps I wasn't being clear enough about what element of Java I was referring to. I was talking about Java Applets. Which have precisely the level proposed. An Unsigned Java Applet is strictly caged into a security sandbox where theoretically any executing program cannot cause any damage to the user's computer or break their privacy. It's comparable to JavaScript running on a HTML page. A signed applet prompts the user before execution effectively "asking the user for network and file access"
https://secure.wikimedia.org/wikipedia/ ... t#Unsigned
https://secure.wikimedia.org/wikipedia/ ... let#Signed

Oh ok. But that's still the browser; not the desktop.

akima wrote:I consider most problems as just... problems... with a practical solution. I don't think "imagine this horrible scenario". I think "how can I make this work." The problem you just described has a simple solution. Merged executables, when built will have LÖVE security sandboxing features disabled by default. I can think of lots of ways of implementing this really cleanly. This is the best of both worlds.

I can agree on that basis then.

akima wrote:"Trust" in this context could extend to a very length debate, but I will mention a few points to think about.

1. "But why do you trust the many game developers that have made their game in C++". I don't always trust developers who have made their game in C++. Sometimes I wont install a game on account of this. People don't have to aim for the lowest common denominator. Why not improve upon a standard practice?

I wasn't saying you "always" trust a developer; I was merely pointing a couple of the reasons of why you would trust any developer at all. Maybe I didn't make that clear enough.

He he. Cool ok. That happens a lot with discussions. Different interpretations of words confusing the issue, or in this case one person (me) not properly interpreting what the other person meant. ^_^