Hi Jeremy,

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. 

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] <javascript:>> 
> 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] <javascript:>.
> To post to this group, send email to [email protected] 
> <javascript:>.
> 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
>  
> <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.
>
>
>

-- 
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.

Reply via email to