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/f2967d6e-c4e4-4d5d-96df-00fbd4fce831n%40googlegroups.com.
