> This seems a major cutback.and as such is really bad news. It's definitely a nuisance, and part of a complex and deep discussion about security topics that is pretty confusing. But there are lots of mitigations, and I don't think the situation is as bad as you think.
> Does that mean that none of what we call transclusions these days will > work in TiddlySpace?!? The <<tiddler>> macro transclusion would continue to work. Do you mean the way that a tiddler that is intended for transclusion can use computed parameters to adapt itself to the tiddler in which it is transcluded? > Would it be reasonalbe to ask for an ability to allow users to turn on > "insecure mode"? Yes, perfectly reasonable, as long as them turning on insecure mode doesn't also force any other spaces that include that space to also switch to insecure mode. The plugin that I mentioned in my previous post would work like more or less like that: install the plugin and computed macro macro plugins will work for you when you visit the space as a logged in user, and for guests who are not logged in. > Why not simply handle transclusions like plugins instead... security- > wise? Meaning: to require a standard tag indicating that something is > a transclusion which only then allows for parameter > evaluation ...otherwise not. There really should be no diffference in > managing transclusions or plugins as both contain executable code. Are you suggesting that computed macro parameters could be enabled on a per-tiddler basis with a systemSomething tag? That's a reasonable approach - we could then filter out that tag for safe transclusions. > I understand the concerns, but I think it were better to advise users > on their responsibility as to "know" what they include and to improve > a user's ability to evaluate the reliability or stability of such > content by seeing user votes on these things or knowing trustworthy > authors, etc. I think you're supporting the earlier point about social solutions being more effective than technical solutions. However, this business with the computed macro parameters is more basic than that: it's tightening things up to gain us the ability to reliably filter dangerous content. If we build the system such that all wikicontent can potentially contain executable javascript we would be inviting fun and games like today's twitter worm: http://arstechnica.com/security/news/2010/09/twitter-worms-spread-quickly-thanks-to-blatant-security-flaw.ars > I also understand that anything {{eval}} presents possible security > issues. But, would you mind explaining precisely how malicious users > can hijack another users space? Alice constructs a space to store her study notes, and share them with the rest of her class Malevolent Bob constructs a space that claims and appears to be a funky new theme with animated kittens Alice includes the kittentheme space Bob has secretly included code in the kittentheme space that vandalises all the private and public tiddlers of the host space, replacing every fifth word with "miaow" Because Bob's code is running with the same authority as Alice's user account, it can do anything it likes - including deleting content by removing all revisions There are endless examples of malicious payload that Bob might try including shutting other uses out of a space or sending spam. Social measures aren't always going to be enough: Bob might actually not be malicious at all, but just have chosen a poor password so some joker could steal his account. > How is disallowing parameter evaluation not just but one of a of a > myriad of (potential) security problems and therefore maybe not worthy > restricting as there is plenty more, equally exploitable room for > manipulation? The vectors through with executable code can hide in wikitext are actually pretty much limited to computed macro parameters and <script> blocks. Of course, plugins can introduce new macros that do execute code derived from wikitext, but at least those plugins themselves can be filtered. > Of course, no client-side manipulation should be able to compromise > the server, but (potentially) only a user's data instead. That's correct. > This issue feels to me like - yet again - (maybe just a false sense > of) security comes at the cost of utterly restricting degrees of > freedom... which I most always tend to find rather unfortunate. There is a solution which I haven't mentioned because I don't think we currently have the resources to implement it. The idea would be to manually parse and execute the computed parameter expressions in JavaScript, and thus to restrict them to safe operations. There's a project called Caja that does something similar on the server. > So here is my vote for a policy that reads like this: "Put plugins and > transclusions on an equal standing while letting users decide on how > secure they need their spaces and contents to be (or user managers on > the security level of members in the user group they are to > manage ...if something like that should ever be developped.)" Letting users decide is exactly what we're trying to do: but that means letting users who include a space decide whether or not they want to include executable code when they include a space. It can't be decided by the users that are publishing spaces. My apologies again about the timing and miscommunication of the change. Best wishes Jeremy > Kind regards, Tobias. > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/tiddlywiki?hl=en. > > -- Jeremy Ruston mailto:[email protected] http://www.tiddlywiki.com -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
