Sounds like you’re reinventing Java and Silverlight.
Maybe. But when we open up the sandbox of the VM we have to do something. And because it’s possible that something like Vorple might one day be included in Inform 7 I’d like to come up with a solution that doesn’t require the user to approve every story file they play, both because it would be annoying, and because it would train people to approve everything without thinking.
Now you could already be evil and write a game which would delete other game’s data files. But web terps are a lot more vulnerable because with an iframe you could do that without the user’s knowledge. (This is possibly already possible? I haven’t tried.) There are other concerns too, because a malicious script could not only delete stuff, but get access to your library/play history etc and send it elsewhere on the net.
Sure, you definitely need some kind of security system if you’re going to let the game pass arbitrary code out to its host. But this is the point in the process where I’d be reconsidering whether that’s worth doing, at least with a JavaScript host. I mean, if you want Java, it’s right over there.
No one wants java. We want html and javascript. Even davec seems to have moved away from silverlight.
Well, I continue to be baffled by the desire to force JavaScript into roles it’s unsuited for, but surely in any case there’s a better alternative than reinventing the sandbox – that sounds like the kind of thing only Bruce Schneier should do, like inventing a new encryption algorithm. Maybe come up with a set of useful external tasks and let the game just invoke them, which would have the added advantage of being platform-independent?
Signing is a good solution I think, and libraries already exist: kjur.github.com/jsrsasign/ Just have to decide if the code footprint of such a library is acceptable. I think that one is around 10kb which is fine.
I agree with vaporware. This is the wrong direction. Any system that needs concern itself with security in this day and age is a really bad idea. Working with the constructs of the standard web is the way to go.
That being said, when I open up my portal, I’m unlikely to allow anything but image, text, and game file uploads. If someone wants to alter the JavaScript code base, they’ll have to work with me on that.
I still don’t see why anyone is building anything custom regarding styles. The browser has solved this (like it or not) with CSS and JavaScript and HTML. Let the author identify context and let the browser do the rest.
David C.
textfyre.com
Unless we deny everyone the ability to use these new features at playif.com security will be something we need to address. I want people to be able to make a game with vorple or maybe a html version of glimmr, upload it to the archive and instantly send their friends a link to iplayif.com. There is a place for curated portals, but that’s not what parchment is.
Denying everyone the ability to embed arbitrary code for visitors’ browsers to execute doesn’t seem like such a bad idea.
This approach works fine when the context is “room header” or “emphasized text”, but anything beyond that requires custom, author-provided styles.
I don’t see how this is different from web publishing in the general case. Anyone can upload arbitrary code to a site and browsers will execute it if they visit that URL. In that respect a story file with a malicious JS payload is not very different from an HTML file.
I have assumed, perhaps in error, that the random port-binding feature in TADS Web UI games is sufficient to defeat the same origin policy and keep each instance of each story file separate for the purposes of DOM manipulation. An individual story file might not be safe to run, but the author still has the problem of driving traffic to that URL.
Perhaps a similar approach could be adopted for iplayif.com - host each story file on a distinct subdomain, generated from its IFID or a subset of its hash value, and offer a “pretty” URL that redirects into that domain before serving the content from the subdomain’s root.
A key difference, as you note, is that in general you can’t post your scripts to someone else’s site. Browsers assume that everything hosted in the same place comes from the same authority, so sites go to great lengths to prevent arbitrary JS from being uploaded and served. Serving each game from a different domain would mitigate that, I believe. The browser knows how to sandbox; let it take care of that instead of cooking up your own security scheme.
Another difference is that in most web publishing, you need the ability to run arbitrary JS code because all your code is JS, and you need to manipulate the DOM because you aren’t using another windowing system on top of that. The necessity of running arbitrary JS code from inside a Glulx/Glk game is questionable, and it seems like at least one major use case is to paper over shortcomings in Glk instead of solving them portably.
I agree that browsers are better suited to the sandboxing task. I suppose my point was that since authors inclined to post malicious code online could do so without using IF formats, it seems unreasonable to tell authors that they can’t include arbitrary code in an IF format because it might be malicious. That just ties the hands of everyone else without imposing any undue hardship on the bad actors.
Portals add an interesting angle because malicious code hosted on a trusted URL is much more dangerous than malicious code hosted elsewhere. But portals aren’t the key constituents; authors are. Given a choice between hosting a game yourself and having access to the full power of a modern browser, versus hosting it elsewhere and hewing to someone else’s vision of how your game should look and feel, I think most authors would opt for the former.
For me the appeal of running arbitrary JS code is precisely the ability to ignore the limitations of Glk. I like Glk and I think it does a tremendous job of abstracting away implementation details in a world where everyone knows what IF is supposed to look like and authors are happy with the status quo.
Once you remove those assumptions, Glk starts to look more like a straitjacket. It’s fine to push for improvements to the more onerous restrictions (like the custom styles limit) but at the end of the day this only substitutes one Grand Unified Theory of IF for another. It still amounts to dictating terms to content creators.
I agree about the value of bypassing Glk when its assumptions are inappropriate, but I think games that want to do their UI with HTML/CSS/JS shouldn’t be using Glk at all.
When Dave decided Glk didn’t suit his needs, we developed a separate IO system and extended the library to use it, in such a way that games could be compiled to run on both. (Guncho uses it too but arguably should be using yet another system.) I think this is better than turning Glk into something that’s effectively platform-specific.
When I say work with me, I mean in to offer the ability to run the code on your own server. Textfyre would host the game file, but it’s certainly possible to offer the same sort of testing capabilities that Facebook and Twitter offers. Once you have it all worked out, you send me all of your code and I run security checks on it to make sure it’s not doing anything evil. Then it gets added to the Textfyre server and your game is played happily from anywhere. There are no limitations. Everything that can be done in a browser is available to the author.
And using the Zifmia extension to define everything by context opens up a whole new world of UI awesomeness. You don’t have to do things my way. You absolutely can do things your way.
David C.
textfyre.com
I don’t think this will help, because I’d still want each subdomain to have access to the Parchment library database/filesystem (and potentially some day to a cloud server we would sync that database with).
I was planning to design my own IO system, but Zarf’s latest plan was so close to what I wanted that I don’t feel the need any more. It may not be an entirely new IO system, but I don’t think that’s a problem, as it is a substantially parallel system within Glk. This has the advantage of not needing to reimplement timers/sound/file handling etc, which would be the case if we designed an entirely independent system.
And of course the library/extensions will be written to support both traditional Glk and Glk+HTML+JS. Even the highly experimental Vorple does that now. And as I understand it the new Glk calls will still work in a non HTML environment. So Glk+Vorple will support Glk 0.7, 0.8 on a traditional terp, and 0.8 on a HTML terp.
You wouldn’t need to reimplement those, since they already exist in JavaScript. The HTML-based IO system would basically just be a pipe between the game and the browser. The way this is shaping up now, you’re implementing that anyway, plus all the rest of Glk which is now redundant.
That’s not how I understand it. Functions to display HTML documents, receive messages from HTML documents, and call into JavaScript aren’t going to work without a browser engine. How could they?
That would be fine if relying on the browser were only necessary for games that wanted to stretch the bounds of IF with fancy tricks involving AJAX, multimedia, etc. But HTML/CSS/JS now seems to be the official (and only) way to do a lot of text styling, including some very basic styling that’s supported by xterms, IRC clients, and Z-machine version 1.1, so any games that use that will also be limited to running in a browser.
If garglk embeds webkit they will probably want to keep their old sound/file system code around as it will probably be more reliable than implementing those features in JS. The same for timers too… negotiating with embedded browsers is a big hassle and you can probably get more precision by directly accessing the system timer. And all the unicode stuff will be much nicer not in HTML. I think about a third of GlkOte’s code is unicode tables.
What I meant is that the style and paragraph functions will work in a non-HTML terp. If you want to add a CSS parser to your console terp go ahead, there are several available. And I’d like it if someone standardised garglk’s true colour support!
That’s a great example of why it’s a mistake to cram everything into Glk. There’s nothing Glk-specific about Unicode case conversion or normalization! But since those functions were put in Glk instead of an Inform library or Glulx itself, they’re now only available when running under Glk. Likewise, any interpreter that wants to support HTML for output will now have to implement the rest of Glk, and any game that wants to output HTML will have to negotiate the rest of Glk to get there, even when it doesn’t use sound or files (or when it prefers the HTML5 audio/storage APIs).
That seems like overkill for something as far removed from HTML as Guncho or Floyd, although it’s not out of the question. But adding a JavaScript engine would be, so I’m concerned about anything that’s going to encourage or require games to become dependent on JS.
As would I – and more generally, support for ad-hoc styles – but it looks like I’m going to have to do it single-handed (unless you’re offering to help? 
).
Hell, a CSS-based approach would work if there were something like glk_{set,begin,end}_style_name that translated to HTML’s “style” attribute instead of “class”.
Zarf has done a lot of stuff I don’t understand. Maybe the unicode stuff is in Glk so that it doesn’t have to care about encodings, whereas if it was in Glulx land then you’d need to care whether it was stored as bytes or words or whatever.
No interpreter ever has to implement all of Glk. Big parts of it are put behind gestalt selectors.
And just to air a gripe, I really don’t like the dispatch system. Maybe it makes sense in C. It doesn’t in JS.
As to inaccessible games on Floyd, I think the responsibility is the author’s. I do expect that the extensions for this HTML stuff will be written with portability in mind, or else I’ll help fix them until they are.
It shouldn’t be hard to get garglk’s extensions standardised. I should request some glk selector codes, and I can write unit tests etc. But the main person who can make it happen is Ben. I looked through garglk’s code but I couldn’t see how the magic happens.
Much more useful would be a glk function that takes a CSS selector and a JSON object of CSS properties to apply to the matched elements. That will be an essential function that no doubt anyone writing custom JS will make, but a glk function might be better.