I agree that there are a lot of possible open "attack vectors", and keeping track of every one is not feasable.
Good conversation so far. I think the primarily concern is that TW will run obfuscated javascript without a refresh required. That should have an option to "Sandbox" that behaviour somehow, and let superusers unlock it. Thanks for the discussion! Best, Joshua Fontany On Wednesday, August 18, 2021 at 9:44:03 AM UTC-7 Mark S. wrote: > Really, it gets back to trust and reputation. > > A TW coder could write a tiddler that contains no javascript tiddlers, but > that, when run, creates a javascript tiddler that will later get run. So > you would never see javascript code during import. The core TW is already > pretty huge. Adding patch after patch for each imagined scenario eventually > renders TW less and less useful. > > Also, it hasn't been demonstrated what harm could be done even if your > standalone code was infiltrated. Could keystrokes be sent back to a server? > Could file blocks be written anywhere other than the download directory? Of > course on node or especially on any multi-user platform things become more > hazardous. In theory any server-based solution (e.g. node) could write to > your file system and possibly invoke code. In practice, I found it very > difficult to set up even when I wanted something like that. > > > > > > On Wednesday, August 18, 2021 at 9:22:27 AM UTC-7 R² wrote: > >> Excellent points John. Most users will indeed not review the full text of >> every single tiddler they import. I'm now thinking that pointing out which >> ones should indeed be reviewed more explicitly would be both easy and >> worthwhile. >> >> At the tm-import-tiddlers widget level, any JS that's being imported >> could be flagged, with a simple highlight inviting the user to review the >> code before confirming the import when standard declared JS is detected, >> and a more insistent alert when the code is hidden or obfuscated (as in >> Finn's Base64 example). A simple exhaustive filter search should be able to >> cover all or most cases, including content-type=application/javascript, >> <script>, <object>, <iframe>. >> >> I feel (at my very modest level of understanding) that this would add a >> significant extra layer of security when drag-and-dropping as users could >> react when seeing JavaScript being imported where none was expected — when >> simply importing a random content tiddler for instance. >> >> Given that new JS is only executable after rebooting the TW instance, >> even if the potentially malicious code is executed while parsing the >> imports, it shouldn't prove too much of an issue as the user with sudden >> doubts could immediately delete the imports and avoid any potential issues >> and would be invited to then share any concern with the TW community to >> understand if anything is wrong and nip the problem in the bud. >> >> Best, >> R² >> > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/74468696-b6ab-493f-a613-aa39f5914e49n%40googlegroups.com.
