177988 - Storing persistent data (implicit cookie) with XUL

Status: RESOLVED DUPLICATE of bug 295994

(Core :: Security, defect)

Description

[Mitchell Stoltz (not reading bugmail)]

There is a small privacy issue with XUL and persistance.
Even if cookies are disabled (but js enabled, it is possible to store
persistent information on the user's browser thru XUL's document.persist().
Attached file persist1.xul demonstrates the persistance - enter some text,
click remember, close the browser, visit the page again, result - the text
is remembered.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

Attachment: Example: persist1.xul

Here is Georgi's example.

Comment 2

[Nicholas Allen]

It looks like only the page that set this XUL "cookie" could read the value back
(not a cross site hole).  Is this correct?

Comment 3

[Mitchell Stoltz (not reading bugmail)]

Can we make the XUL document function |persist()| inaccessible by XUL pages on
the Web (make it chrome-only?) If so, I'll do that. If doing so would break many
pages or Web apps, then I'm going to wontfix this, since the privacy violation
is minor.

Comment 4

[Brendan Eich [:brendan]]

How do you propose to find out whether any remote XUL app would be broken? 
Maybe find all the remote XUL apps known to the community and to google, and
test them.  That sounds hard, and likely to produce positives.  I'd say WONTFIX
now, save time ;-).

Or, how about making persist() fail if cookies are disabled for the site that
served the .xul page that calls persist (or disabled globally)?

/be 

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Is there any way for the user to see, from the browser, that this "cookie" has
been set? Is there any way to delete it from the browser? If the answer to
either of these questions is "no", then I don't think this should be wontfixed
(and I suspect the answer is "no" to both).

We are very concened about cookies, and some people are practically paranoid
about them. Consequently we have pretty amazing controls for cookies. That
should be our cue that anything that offers similar functionality should be
dealt with the same care. 

At a minimum there should be a hidden pref to turn this feature off for remote
XUL. Enabling/disabling based on your cookie settings seems almost reasonable,
the biggest trouble IMO being that if you first enable and then disable a site,
it may have set something in the meanwhile that you do not know about and can
not get rid of (as I assumed in the first paragraph). Could these persistent
settings be cleared when you clear cache, cookies, history, or something?

I would suggest checking a collection of XUL apps from mozdev and seeing if they
use this feature. I wouldn't go so far as to try and test every XUL app you can
find. If you know of any app that actually does remember settings, they should
be naturally checked. One thing that comes to mind is the XUL-based
newsaggegator at http://www.xulchannels.com/ where you can add a channel,
although I don't know if that affects all users or just you. Asking a few
knowledgeable XUL developers might give a fast answer as well...

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Also, another way to disable this for remote content would be to fail without
throwing and only post a warning to the JS console. I think that would be most
likely to not break any existing apps.

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Sorry, I am a bit slow today... I think we already "have a hidden pref" solution
by making document.persist noAccess. I hope that works for XUL docs as well... 

Comment 8

[Ben Bucksch (:BenB)]

This makes all of our cookie prefs and managers useless, in theory. Thus
severity major.

Comment 9

[Daniel Veditz [:dveditz]]

Thanks for rescuing this needle from the obscurity of the haystack, Ben. Taking.

Comment 10

[Benjamin Smedberg]

Please note:

1) document.persist() is not the only way this happens. Adding a
persist="attributename,attributename2" to any element with an ID will persist
that attribute in the localstore.

2) This is an important part of ordinary remote-XUL applications and should not
be unconditionally turned off. Use the cookie preferences as appropriate, and
perhaps add a "localstore-cleansing" mechanism if somebody clears cookies.

Comment 11

[Daniel Veditz [:dveditz]]

Yes I should have mentioned that... only controlling script access to the
persist property wouldn't work. And yes, persist is a useful and legitimate part
of a web application.

This will have to depend on the UniversalPhishing privs bug rather than invent
yet another mechanism or list of privileges.

Comment 12

[Jesse Ruderman]

Dup of bug 295994?

Comment 13

[poelzi]

With Bug #144795, disallowing persist would render remote xul applications into
a useless state, because there is no way to store anything on the client side.