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: 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.
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"BlackBulletIV wrote: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.akima wrote:Java has this feature and so does Adobe Flash.
https://secure.wikimedia.org/wikipedia/ ... t#Unsigned
https://secure.wikimedia.org/wikipedia/ ... let#Signed
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.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 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!
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: 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!"
"Trust" in this context could extend to a very lengthy debate, but I will mention a few points to think about.BlackBulletIV wrote:akima wrote:It isn't sensible for the user to trust games from a given website.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.akima wrote:It isn't sensible for a user to trust a particular developer.
- "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.
), you'll be safe.
