> When I try to save, I get this message: [...] > What is it trying to do?
It's trying to save the file to the disk. This is not a normal operation for sites viewed in a web browser (imagine any website could access your hard drive), so you need to confirm that TiddlyWiki is indeed a trusted application before it can save changes.
But what exactly is it doing? Am I opening up any kind of security
hole by allowing this? Is there a way I can view the setting in
Firefox that is being changed?
> When I try to save [from FireFox], I get this message:
> A script from "file://" is requesting enhanced abilities
> that are UNSAFE and could be used to compromise
> your machine or data
> Allow or Deny
> But what exactly is it doing? Am I opening up any kind of security
> hole by allowing this? Is there a way I can view the setting in
> Firefox that is being changed?
It is asking for permission to READ the existing TW document file from
your local hard drive, so it can then insert the changed tiddlers from
the currently loaded document into that file content, and then WRITE
that file content back to your hard drive... In other words: it's
saving the changes in your document!!!
So... why does this create a warning? Because, underneath the hood,
TiddlyWiki is still just a web page, and ALL web pages running in your
browser MUST ask for permission before accessing your local hard
drive. That's just basic, common-sense security. You don't want
random web sites that you visit to start reading/writing your locally-
stored files!
However, while TiddlyWiki is a web page, and CAN be opened from a
*remotely-hosted* document (i.e., an "http" URL), it is mostly
designed to opened and used as a *locally-stored file* (i.e., a "file"
URL), and NEEDS to be granted permission to access the local hard
drive in order for some key TW core functions (such as saving changes)
to work properly.
Unfortunately, even though one could presume that "file://" is, by
definition, a "trusted source" -- after all, it is YOUR drive, and YOU
opened the TW document in the first place -- the browser still asks
for permission to access the local hard drive from that locally-loaded
document.
I suggest that, once you are comfortable with the idea, you simply
"Allow" the file:// access and also [x] "remember this decision", so
you aren't nagged to death with security warnings.
Fortunately, the browser treats "file://" as a separate domain from
all other remote domains, so granting permissions to locally-stored
documents won't create any security holes when accessing remote web
sites.
To find the internal FireFox setting:
1) look for "prefs.js", a file that is automatically written by
FireFox to store your current browser settings. Under Windows, this
is generally located at:
-----
C:\Documents and Settings\Your Name\Application Data\Mozilla\Firefox
\Profiles\abcdef12345.default\prefs.js
-----
2) Open that file with a plain text editor (make sure FireFox is NOT
running at the time!), and find these two lines (or similar):
-----
user_pref("capability.principal.codebase.p0.granted",
"UniversalXPConnect UniversalBrowserRead");
user_pref("capability.principal.codebase.p0.id", "file://");
-----
3) Delete those lines to restore FireFox's default "ask for
permission" state for the "file://" domain
HTH,
-e
Eric Shulman
TiddlyTools / ELS Design Studios
If you are in the paranoid side and dislike granting EVERYTHING from
the file: "host" the same privileges, you may want to consider
1. Using per-file privileges
2. Using Prism (formerly known as WebRunner). Prism is more forgiving
regarding privileges for file: urls. My guess is that this is based on
the assumption that you are more likely to control what files you open
with Prism than with Firefox.
Regarding per-file privileges, the fact is that Firefox does not make
it simple: no wildcards accepted; even urls with '#' are treated
differently than without it.
You'll need to follow Eric's detailed recipe, and delete the catch-all
entry in prefs.js. The chromedit extension could make this steps
simpler
http://webdesigns.ms11.net/chromeditp.html (note that I don't have
this extension installed; I used to be a happy customer of a
discontinued earlier version)
For every file that you want to grant privileges you'll need to add
something like
user_pref("capability.principal.codebase.tiddly0.granted",
"UniversalXPConnect");
user_pref("capability.principal.codebase.tiddly0.id", "file:///C:/bla/
MyTW.html");
user_pref("capability.principal.codebase.tiddly1.granted",
"UniversalXPConnect");
user_pref("capability.principal.codebase.tiddly1.id", "file:///C:/bla/
Another.html");
The annoying thing is that updating user.js only has effect when you
re-start firefox. This can be done dynamically, but the recipe is not
simple. Something simpler could be set together, and I hope to put
something together some not so busy day. Meanwhile, these pieces could
help.
* Code for a XUL bookmarklet that lists privileged urls. The
bookmarklet has to be used in a chrome privileged tab, like
chrome://browser/content/aboutDialog.xul or about:config
http://tiddlywiki.pastebin.com/f71f3df70 * Code for a bookmarklet that prompts you for a file name that you
want to grant privileges to (I wrote it years ago, and know it to work
with file urls and my naming conventions, soits general usefulness may
be limited)
http://tiddlywiki.pastebin.com/f64e15186 * Recipe to have code with chrome privileges without too much trouble:
http://xdexavier.blogspot.com/2007/01/my-browser-my-rules-my-chrome.html
Wow! What a long essay for something that Eric already answered
perfectlly well!
-Xv
On Dec 11, 7:55 pm, Eric Shulman <elsdes...@gmail.com> wrote:
> > When I try to save [from FireFox], I get this message:
> > A script from "file://" is requesting enhanced abilities
> > that are UNSAFE and could be used to compromise
> > your machine or data
> > Allow or Deny
> > But what exactly is it doing? Am I opening up any kind of security
> > hole by allowing this? Is there a way I can view the setting in
> > Firefox that is being changed?
> It is asking for permission to READ the existing TW document file from
> your local hard drive, so it can then insert the changed tiddlers from
> the currently loaded document into that file content, and then WRITE
> that file content back to your hard drive... In other words: it's
> saving the changes in your document!!!
> So... why does this create a warning? Because, underneath the hood,
> TiddlyWiki is still just a web page, and ALL web pages running in your
> browser MUST ask for permission before accessing your local hard
> drive. That's just basic, common-sense security. You don't want
> random web sites that you visit to start reading/writing your locally-
> stored files!
> However, while TiddlyWiki is a web page, and CAN be opened from a
> *remotely-hosted* document (i.e., an "http" URL), it is mostly
> designed to opened and used as a *locally-stored file* (i.e., a "file"
> URL), and NEEDS to be granted permission to access the local hard
> drive in order for some key TW core functions (such as saving changes)
> to work properly.
> Unfortunately, even though one could presume that "file://" is, by
> definition, a "trusted source" -- after all, it is YOUR drive, and YOU
> opened the TW document in the first place -- the browser still asks
> for permission to access the local hard drive from that locally-loaded
> document.
> I suggest that, once you are comfortable with the idea, you simply
> "Allow" the file:// access and also [x] "remember this decision", so
> you aren't nagged to death with security warnings.
> Fortunately, the browser treats "file://" as a separate domain from
> all other remote domains, so granting permissions to locally-stored
> documents won't create any security holes when accessing remote web
> sites.
> To find the internal FireFox setting:
> 1) look for "prefs.js", a file that is automatically written by
> FireFox to store your current browser settings. Under Windows, this
> is generally located at:
> -----
> C:\Documents and Settings\Your Name\Application Data\Mozilla\Firefox
> \Profiles\abcdef12345.default\prefs.js
> -----
> 2) Open that file with a plain text editor (make sure FireFox is NOT
> running at the time!), and find these two lines (or similar):
> -----
> user_pref("capability.principal.codebase.p0.granted",
> "UniversalXPConnect UniversalBrowserRead");
> user_pref("capability.principal.codebase.p0.id", "file://");
> -----
> 3) Delete those lines to restore FireFox's default "ask for
> permission" state for the "file://" domain
> HTH,
> -e
> Eric Shulman
> TiddlyTools / ELS Design Studios
Thank you both very much for taking the time to explain this so well.
I figured it was pretty safe to grant this permission since it was
caused by a file from a trusted site, but loosening security in any
way always makes me nervous when I'm not familiar with what is being
requested.
> loosening security in any way always makes me nervous when I'm not > familiar with what is being requested
You're absolutely right; this should be made clearer. I'm somewhat incapacitated right now (hand surgery), but I'll see whether I can write a wiki page on the issue (based on Eric's and Xavier's responses), in a couple of weeks maybe.
