Hi Adam > Thanks for the info. I guess I'm just wondering if there is a convenient way > to filter out some features of JS and allow others to go through. I see lots > of plugins that provide atomized functionality of simple capabilities of > javascript. It just seems to me that if it were possible to build an > effective filter, one might be able to have all that functionality in the > core without bloating tw. > > The Secure EcmaScript is really interesting. Though I wonder if there is a > simpler way to do this without executing the code in a sandbox environment. > Is it possible to, in the parsing stage, identify blacklisted keywords, and > if those words appear, don't make a script tag out of the code? Or maybe (if > a blacklist would be too large) just have a list of whitelisted words and > symbols (including a set of allotted variable names). If the code is built > only of these parts, then a script tag is made of it. Else, it doesn't run. > Or it throws an error or something. > > I'm fairly new to JS and programming generally; so this may all be hopelessly > naive of me. I just wonder if the bloat of multiple (and sometimes > overlapping) plugins to perform string, numerical, JSON, or array > manipulation could be reduced.
Your questions are exactly the right ones if you are interested in digging into this area. My understanding is that it is only possible to use static analysis to sanitise a language like JS in very restricted situations. So I think most tools are actually transpilers that use a JavaScript parser to make an abstract syntax tree for the source code, and then to transliterate that back into JavaScript with the addition of guard functions that check the safety of operations dynamically. Best wishes Jeremy > > Best wishes, > > Adam > >> On Friday, January 18, 2019 at 9:16:31 PM UTC, Jeremy Ruston wrote: >> 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 >> >> Here’s a demo: >> >> 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]. >>> 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/8ddce635-574b-4a79-8ccd-027ef0fd6c17%40googlegroups.com. >>> For more options, visit 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/1726d702-9a30-4682-92f1-fe0427743abb%40googlegroups.com. > For more options, visit 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/96A0812A-B453-4D82-8F71-59BB5DCE1255%40gmail.com. For more options, visit https://groups.google.com/d/optout.
