Thanks all for considering this; I think the best way to limit risks is to provide plugins in trusted libraries, from trusted sources. then people could also install these in an empty html and run a vulnerability test using a plugin designed to highlight risks. As soon as a library contains something doggy the community can react.
To facilitate this I would like an easy way to collect and publish a library from a single file wiki, then the well known and trusted people can publish libraries that they themself can check or anyone in the community. Libraries contain plugins frozen in a moment of time, Only libraries so tested would be listed publicly. With all other sources the designer can run a (latest) vulnerability test published on tiddlywiki.com and if we must we can blacklist or whitelist plugins or "signatures" in this vulnerability tester. In another discussion I am also calling for a hash tool which although not invulnerable would add another layer of testing, mostly to see which system tiddlers have being modified, and this would just make cheating more difficult. The power we have on our side is the community and the ability to collect and centralise data in a way that "outsiders" have more work to do before they can compromise anyone to a large extent, ie make it harder and cause diminishing returns. We can also ensure we have trusted sources and be able to test them. In this light we may even benefit from people hacking, because we can identify the vectors and respond. But finally I want to reinforce in many wiki editions or personal on my desktop/mobile only, I do not want features crippled, diminished or destroyed for when the wiki may be placed on an internet facing editable platform. This is why I think the vulnerability test tool has the greatest value. Horses for courses. Regards Tones On Thursday, 19 August 2021 at 08:55:14 UTC+10 joshua....@gmail.com wrote: > 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 tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/9eb178c2-17fd-4bf5-b8a3-2b77fba0d8d6n%40googlegroups.com.
