Hi Adam As others have said, the primary goal of the current arrangement is to make it easier to detect/filter JS content by requiring it to be in a module tiddler. A secondary benefit of excluding inline JS is that it discourages blindly copying and pasting the kind of old-style DOM-based JS snippets that don’t work in TW5.
Funnily enough, I’ve just come across Secure EcmaScript which seems a good snapshot of the state of the art of safely executing untrusted JavaScript: https://github.com/Agoric/SES <https://github.com/Agoric/SES> Here’s a demo: https://github.com/jimpick/cabal-ses-bot <https://github.com/jimpick/cabal-ses-bot> Best wishes Jeremy > On 16 Jan 2019, at 23:25, AdamS <[email protected]> wrote: > > Thank you all. That's a lot of good information for my to look through and > cogitate on! > > Best wishes, > Adam > > On Wednesday, January 16, 2019 at 5:01:07 PM UTC, Matthew Lauber wrote: > Another issue with inline javascript specific to TW is that it interferes > with the parse/render/update loop. Let's say you include some inline > javascript in your tiddler. When is it supposed to execute? When rendered? > How often? Keep in mind that TW rerenders tiddlers if any of the state they > depend on changes (like the React Virtual DOM). These renders may not be > visible to you the user. And what happens when your javascript is executed > twice? Overall, it is a lot simpler to reason about, and less bug prone, to > require all javascript calls to be part of the parse/render/update loop. > > On Monday, January 14, 2019 at 8:09:46 PM UTC-5, AdamS wrote: > Hi Folks, > > I know it has been discussed a few times, but I keep coming back to the idea > of inline javascript. Or at least something javascript-ish > (javascript-esque?). I know the reason this capability isn't standard is > because of security issues. I don't have much experience with this sort of > thing, but I'm wondering how significant are the barriers to sanitizing > inline javascript. What would need to be stripped out of a script tag to > ensure that it would be safe? I'm guessing any DOM manipulation would be > right out, as well as access to the window object. But even if we could just > get a safe inline javascript for control flow, array, string, and number > manipulation, that could be pretty cool. Could this be securely done? > > Best wishes, > > Adam > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/tiddlywiki > <https://groups.google.com/group/tiddlywiki>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/8ddce635-574b-4a79-8ccd-027ef0fd6c17%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywiki/8ddce635-574b-4a79-8ccd-027ef0fd6c17%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/315AFD60-57E4-4E6D-9A4F-92A3A177A2A4%40gmail.com. For more options, visit https://groups.google.com/d/optout.
