I was just looking at ## Hidden Setting: HTML Parser Sandbox
as it is new in 5.2.0
The following thought arose. When using tiddlywiki at file:// rather than http/https there may be an argument that this is a more secure environment. I was thinking the example of the above hidden setting if using the less secure option was desired, perhaps it could be be reengaged if the wiki was found at a url rather than file.
Basically I wonder if there would be value providing a mechaisium to allow settings valid in more secure file:// use to be re-engaged when the wiki is not on file://.
Basically at wiki load determine if the wiki is at file:// and activate one group of settings and if otherwise another group of settings. This can be done based on $:/info/url/protocol which suggests perhaps it makes sense to allow a response for other protocols or url conditions. For example a Wiki may reject access if not found at a given URL or hostname
$:/info/url/hostname
What I propose is a simple solution (file:// vs not File://) in the standard distribution with a plugin for more sophisticated responses to the info tiddlers for more advanced applications.
Your ideas please
- I would be keen to hear from those who understand what I am talking about and can see the implications of my idea.
- If you feel you understand the implications of using a tiddlywiki at file:// addresses rather than others such as http and https, or even at non standard ports I would like your thoughts on the difference.
Note: I use most private single file tiddlywikis at file:// addresses using Timimi and some at a http://127.x.x.x addresses both of which could be considered private and safer allowing more permissive settings. The idea that as soon as the tiddlywiki is published outside this private domain more restrictive settings will be applied automatically seems to make sense. This could also be an in wiki way to redirect on http if not https. access.