Unfortunately not at the present time. These descriptors are very opaque and need to be saved essentially as is to IndexedDB.
However, I did come up with a proposal to the browser vendors that would allow this Allow for serializing and deserializing a handle as a string · Issue #295 · WICG/file-system-access (github.com) <https://github.com/WICG/file-system-access/issues/295>. If this were implemented, I could do that or even just save the handle to the wiki itself in a secure way. On Thu, May 13, 2021 at 12:46 PM 'Mark S.' via TiddlyWiki < [email protected]> wrote: > Could the file descriptors be encrypted before storage? Then when there's > a save the plugin could fetch the encrypted descriptor, decrypt it, and use > it for the save? > > On Tuesday, April 27, 2021 at 3:59:23 PM UTC-7 [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 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/3a052774-a404-4759-a668-1a7576be194an%40googlegroups.com > <https://groups.google.com/d/msgid/tiddlywiki/3a052774-a404-4759-a668-1a7576be194an%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/CAJsXKEM7xHTP20cTb7S%3DtTYf5L6%3D0MwtdwENd3rcgEWg%2BZmw1g%40mail.gmail.com.
