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 <http://todo.tiddlywiki.com>
sandbox.tiddlywiki.com <http://sandbox.tiddlywiki.com>
mywiki.tiddlywiki.com <http://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
o The code I posted doesn't save to IndexedDB, so this
is for people modifying the code.
o 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/
<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,
visithttps://groups.google.com/d/topic/tiddlywiki/IczqdIdC3lE/unsubscribe
<https://groups.google.com/d/topic/tiddlywiki/IczqdIdC3lE/unsubscribe>.
To unsubscribe from this group and all its
topics, send an email
[email protected].
To view this discussion on the web
visithttps://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
[email protected].
To view this discussion on the web
visithttps://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,
visithttps://groups.google.com/d/topic/tiddlywiki/IczqdIdC3lE/unsubscribe
<https://groups.google.com/d/topic/tiddlywiki/IczqdIdC3lE/unsubscribe>.
To unsubscribe from this group and all its topics, send
an email [email protected].
To view this discussion on the web
visithttps://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 [email protected].
To view this discussion on the web
visithttps://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]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/d519dc2c-43ae-4c31-b423-37c062bcf70fn%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/d519dc2c-43ae-4c31-b423-37c062bcf70fn%40googlegroups.com?utm_medium=email&utm_source=footer>.
