Dyllon, Thanks for working on this project. I agree security is paramount, and failure to address it may simply result in in braking with the next security update to a browser.
However, I want to point out there are different use cases for tiddlywiki, where there is only one user, on a LAN or a trusted team, as opposed to Internet publishing. There are cases where adding a plugin that exposes a security issue is not an issue in many cases. Sadly Security is the "Tail that wags the dog" today and stops a lot of possibilities, but all it takes is accounting for context, such as only if on local host etc.... Regards Tones On Tuesday, 27 April 2021 at 05:28:02 UTC+10 [email protected] wrote: > I would caution on being too hasty with this. There are some serious > security implications with opening wikis hosted on the file system (i.e. > file://, not talking about local servers or TiddlyDesktop). > > Apparently permissions are shared pretty broadly for anything open on > file://. The code I shared is probably ok, but I have reported one issue to > the Chromium team that I would like to hear > their feedback on since it has some potential security implications for > TiddlyWiki. I know there are people who store very valuable data on their > wikis which is why I want to put a big caveat > on all this. > > Even with my current concerns, I believe that the API is very safe so long > as you serve the wiki from a local server (any local server, doesn't need > to be TiddlyWiki specific). For example, > launching a web server in a directory with the wiki via "python3 -m > http.server". There is less of a benefit over the tiddlywiki node server, > but I do think there is still a benefit. Since there > is almost no coupling between the server and TiddlyWiki, you can debug > things entirely in the browser and synchronization of state is easier to > think about. There is only the state on disk > and the state of the browser tab, no hidden state/watch issues with the > web server. > > I think expanding the code to support wiki folders would be great and > would help solve some of the issues around having images embedded in > portable wikis. > > I am planning on releasing this as an actual plugin, but in addition to > security and versioning, I want the plugin to: > > - Support versioning/backup like TiddlyDesktop. > - Have settings for the plugin to control stuff like logging from the > component itself without modifying code. > > > Thanks, > Dyllon > > On Sat, Apr 24, 2021 at 9:15 PM TW Tones <[email protected]> wrote: > >> Folks, >> >> This may be the opportunity to simplify saving and give the local storage >> plugin or its equivalent safe access to the local system. Thus users can >> access a read only online resource and use it as if it were a local app, >> with their own data stored locally. >> >> Any way to reduce the complexity of using, especially saving >> tiddlywiki(s) will increase adoption. If the logic and and setup can be >> included in the original wiki then they become eminently deployable with >> self documented setups. This could include backups, localisation or >> cloning, I can quickly do this now with Timimi already in place, if such >> facilities can be introduced without a two step, browser specific install, >> all the better. Yes, all the appropriate authorisation is needed for >> security. >> >> Tones >> >> >> >> >> On Saturday, 24 April 2021 at 17:42:18 UTC+10 Jeremy Ruston wrote: >> >>> Hi Dyllon, >>> >>> >>> I wrote a small module for saving using the Chromium file system API >>> (which is in the process of being standardized). >>> >>> Example TiddlyWiki 5 Saver Using HTML 5 File System Access API >>> (github.com) >>> <https://gist.github.com/slaymaker1907/7a04a6188179bfe113b122b1f51e22b5> >>> >>> >>> Great stuff, I’ve been following the File System API with interest, and >>> would be keen to get a saver in the core once the spec settles down. >>> >>> Here’s a link for those unfamiliar: >>> >>> https://web.dev/file-system-access/ >>> >>> I don’t know if any other browsers are planning to implement the API. It >>> seems like an obvious requirement for ChromeOS, but perhaps other browsers >>> will have less incentive to implement. >>> >>> The first time a save action is triggered, it prompts for a save >>> location but future saves should go to the same location. >>> >>> It's a bit dangerous because if saving fails, there is no way AFAIK to >>> disable the saver after it loads. I would be interested to know if anyone >>> knows a way to disable a saver after it has already loaded. >>> >>> >>> I think you’re already following the correct approach: for the save() >>> method to synchronously return false if the save cannot proceed so that the >>> next saver in the cascade gets a chance. >>> >>> Another thought with respect to the File System API is that it may be >>> possible to write a syncadaptor module so that we can support TiddlyWiki >>> folders containing individual .tid files in the browser. >>> >>> Best wishes >>> >>> Jeremy >>> >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "TiddlyWiki" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/tiddlywiki/IczqdIdC3lE/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tiddlywiki/6d3bc90f-54eb-4512-a56d-3a62931b75b4n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/tiddlywiki/6d3bc90f-54eb-4512-a56d-3a62931b75b4n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/582a4397-a681-424f-965b-1cd903738f95n%40googlegroups.com.
