For those interested, I've wrapped this code into a proper plugin at slaymaker1907/TW5-browser-nativesaver (github.com) <https://github.com/slaymaker1907/TW5-browser-nativesaver>.
The main additional features I added were: - A settings page (Control Panel/Saving/HTML Native File System Saver) - Ability to disable saver from said settings page (should be able to disable it and then use another saver if desired) - Ability to turn on/off logging to dev console - If served via a webserver like "python3 -m http.server", it saves the file location to IndexedDB so you don't have to constantly reselect the file to save to when you reload the page. Note that for enhanced security, I recommend using a specific port for the webserver and/or "yourwiki.localhost:8000" (any *.localhost domain should just resolve to localhost, but the browser should treat it as a separate domain). I'm currently working on adding support for automatic backups like TiddlyDesktop. In the future, I may also support saving as a wiki folder which should increase performance as well as allowing. *I highly recommend using a backup solution like Dropbox, GoogleDrive, OneDrive, etc. since versioning is not supported out of the box. Just something which allows you to recover the document from a specific time period.* The plugin itself should either work or fail gracefully, this recommendation is more for situations where the wiki gets corrupted due to a disk issue or because of some other faulty tiddlers/plugins. You'll thank me later. On Wednesday, April 28, 2021 at 7:49:00 PM UTC-6 TW Tones wrote: > Jeremy et al, > > I think if we could at least make it look like a PWA functionally. Please > bare with my level of technical knowledge, but I believe I can see > something appearing in the fog of these issues. > > Given initial saving to IndexDB is workable if not reliable in the long > term, I wonder if we provided a tool in Tiddlywiki to save the Wikis index > db, or the wiki itself out to file as a backup? In fact as a start we could > use this to trigger local backup (See Mario's and others "Savers"). Noting > the backups would not be html or other "executable", thus stopping them > subsequently being loaded with all local permissions etc... > > I have always thought that a mechaisium to logout of tiddlywiki would be a > nice option. We could autosave to the backup then logout, which would > trigger a save to file (even if we must get a dialogue) A little code or > cookie may be able to detect if the tiddlywiki no longer holds a matching > last file save it would prompt to load the backup from a known folder. This > method may have the added advantage that all backups can be files under the > browser downloads folder thus have the necessary browser rights. > > The above method also means you will find your tiddlywiki at the URL where > you hosted it, no need to address files unless you have a failure or during > the "occasional" backup to file. Such addresses can be local dns or IP > address that is only hosting the original (read only wiki), the content is > off in IndexDB and backups to the downloads folder. Of import here is you > must continue to have access to the original, but all subsequent content is > localised (owned by the user). > > Finally we could host dozens of empty.html files on a static server (by > other names / domains), perhaps some preloaded editions, then tiddlywiki > users can find one of these as a starting wiki and design and add content > on top of there. eg todo.tiddlywiki.com sandbox.tiddlywiki.com > mywiki.tiddlywiki.com with smart server management these could all be the > same html file plus installable packages. > > Once more experienced, once they have a server or saver Timimi they can > export their wiki to a specific local location , until then just use them > at the address, but bound within a browser. > > I truly hope to make the use and design of tiddlywiki so seamless then we > can surely attract more people with lower level skills so they can start on > the journey. > > Tones > > On Wednesday, 28 April 2021 at 18:55:43 UTC+10 Jeremy Ruston wrote: > >> Hi Dyllon >> >> We actually have the same issue with the GitHub saver module: it saves >> the access token to local storage, which is subject to the same peculiarity >> of all file: URIs counting as a single origin. Thus, if an attacker can >> induce a user to download an HTML file and open it in the browser then they >> can exfiltrate all the access tokens. >> >> I think Google’s answer would be “don’t use file URIs to manage sensitive >> data”, but it makes me sad that there’s so much erosion of the users power >> to manage their own data locally. I think the alternative is to run >> TiddlyWiki as a PWA, but that would subject us to browser compatibility >> issues, and give end users a much more obscure mental model. >> >> Best wishes >> >> Jeremy >> >> On 27 Apr 2021, at 23:54, 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/d519dc2c-43ae-4c31-b423-37c062bcf70fn%40googlegroups.com.
