Hi Dyllon! Many thanks for the detailed answer and clarification!
I hope someday we could have this native saving feature! It would be very convenient to be able work with Tiddlywiki without any extra requirements! Best wishes Mohammad On Wed, Apr 28, 2021 at 3:29 AM Dyllon Gagnier <[email protected]> wrote: > @mohammad.rahmani the security issue is actually relevant to TiddlyWiki > even if the file itself is secured. > > Google decided this was a duplicate issue so I can disclose the issue in > full. 1202597 - Security: File Access API Permission Bypass - chromium > <https://bugs.chromium.org/p/chromium/issues/detail?id=1202597#c3> > > You can save file/directory handles to IndexedDB (like localStorage, but > more confusing) so that you don't need to select the TiddlyWiki > file from the file picker each time you refresh the tab/open it. However, > Chromium has a bug/design which considers everything from file:// > to be from the same origin/domain. This means if you download and double > click on some "malicious.html" it could just scan IndexedDB > and use the same descriptors TiddlyWiki saved for convenience. > > Here is a potential outline of this attack: > > 1. You save teaminfo.html to a shared drive which includes > passwords/valuable docs/etc. > 2. You are writing some Rust code and have the docs open (which the > rustdoc tool conveniently generates for you locally). > 3. Someone, NSA/Russia/whoever, compromised some libraries docs and > inserted malicious JS. > 4. This malicious code gets the file descriptor by scanning IndexedDB > and uploads it to some remote location. > 5. If you happen to have said wiki open in another tab (as I > personally often do), it can also overwrite this file and then be > ransomware. > > *How to avoid this:* > > - Do not save file descriptors to IndexedDB > - The code I posted doesn't save to IndexedDB, so this is for > people modifying the code. > - I am working on a proper plugin for this and my plan is to only > save descriptors if not served from file://. > - Use a static server like "pythom -m http.server" > - Firefox doesn't support this API yet, but they seem to be more > strict with same origin than Chromium. > - Wait for Chromium to actually fix this issue and enforce a better > origin policy for IndexedDB. > > > On Mon, Apr 26, 2021 at 8:26 PM Mohammad Rahmani < > [email protected]> wrote: > >> >> >> On Mon, Apr 26, 2021 at 11:58 PM Dyllon Gagnier <[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. >>> >>> >> This looks very promising! Having a simple method for saving is very >> essential in many use cases! While I understand your concern for security >> issues, I think still this approach of saving TW is very useful and >> demanding! >> >> >> >>> >>> 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/CAJsXKEMU2-R3asA6jOZOB35NQca7mpaxnT%3D%3D6sZiev6XVvWG-g%40mail.gmail.com >>> <https://groups.google.com/d/msgid/tiddlywiki/CAJsXKEMU2-R3asA6jOZOB35NQca7mpaxnT%3D%3D6sZiev6XVvWG-g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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/CAAV1gMCuej%2Bg6Aup7WXRdQco4yo5OXyiBeZqb4BMkVa%3D%2BBXOhw%40mail.gmail.com >> <https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMCuej%2Bg6Aup7WXRdQco4yo5OXyiBeZqb4BMkVa%3D%2BBXOhw%40mail.gmail.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/CAJsXKEMvmHaNG-uwkJAyuHOJd8ZpSkkoimx-qEhPmdM%3DW%3D8TqA%40mail.gmail.com > <https://groups.google.com/d/msgid/tiddlywiki/CAJsXKEMvmHaNG-uwkJAyuHOJd8ZpSkkoimx-qEhPmdM%3DW%3D8TqA%40mail.gmail.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/CAAV1gMCi1gJXWGxT4q4yL2oSUONCKcLwa9Y6RFOWS3mvkf-LAQ%40mail.gmail.com.
