Storing persistent data (implicit cookie) with XUL

RESOLVED DUPLICATE of bug 295994

Status

()

Core
Security
--
major
RESOLVED DUPLICATE of bug 295994
15 years ago
10 years ago

People

(Reporter: Mitchell Stoltz (not reading bugmail), Assigned: dveditz)

Tracking

(Depends on: 1 bug, {privacy})

Trunk
privacy
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
(Reporter)

Comment 1

15 years ago
Created attachment 104910 [details]
Example: persist1.xul

Here is Georgi's example.

Comment 2

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

Comment 3

15 years ago
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.
Status: NEW → ASSIGNED
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 
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...
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.
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

13 years ago
This makes all of our cookie prefs and managers useless, in theory. Thus
severity major.
Severity: normal → major
Keywords: privacy
(Assignee)

Comment 9

13 years ago
Thanks for rescuing this needle from the obscurity of the haystack, Ben. Taking.
Assignee: security-bugs → dveditz
Status: ASSIGNED → NEW
OS: Windows 2000 → All
Hardware: PC → All

Comment 10

13 years ago
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.
(Assignee)

Comment 11

13 years ago
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.
Depends on: 248207

Comment 12

12 years ago
Dup of bug 295994?

Comment 13

12 years ago
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.
(Assignee)

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 295994
You need to log in before you can comment on or make changes to this bug.