271861 - prefetched page sets cookie even if not viewed

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, defect)

Description

[Marcello Perathoner]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)

I don't know if this is broken by design or a bug.

I wrote an application to read books online (see url). This application sets a
cookie to remember the page no. of the last page viewed by the user. This app
also prefetches the next page in the book if the browser supports prefetching.

The problem is: the prefetched page modifies the cookie the viewed page has set.
With prefetch on the cookie points to a page the user has not yet seen. 


Reproducible: Always
Steps to Reproduce:
1. turn prefetch and cookies on
2. go to: http://www.gutenberg.org/catalog/world/readfile?fk_files=8448&pageno=5
3. you are reading page 5, page 6 is prefetched
4. Dont go to page 6 but click on "my bookmarks"
5. Click on "continue reading"


Actual Results:  
You are now reading page 6.

Expected Results:  
You should be reading page 5.

Comment 1

[Alec Flett]

google just added prefetch support for firefox.. 
http://www.google.com/googleblog/2005/03/enhanced-searching-with-firefox.html

this suddenly becomes a bigger privacy issue

Comment 2

[Alec Flett]

nominating for 1.0.3 - this means arbitrary sites can set cookies even if you
never technically visit them, as long as they are among the first results of a
google search.

Comment 3

[Mike Connor [:mconnor]]

This is probably not 1.0.3 material, since its more of privacy than a security
issue, and would require something in the way of a backend solution that's
possibly going to break sites.

I'm not familiar with the standards related to prefetching, but it seems like a
lot of sites would have bad reactions if we didn't handle cookies, and this
would heavily negate the benefit of prefetching.

Comment 4

[[e-mail]]

For the privacy issues, I don't think we should do anything. Prefetching would
lose value if we disabled cookies during pageload, but that doesn't exclude the
possibility of us providing a pref for users to flip themselves. I don't really
see what the change in the privacy situation is (relative to no prefetching),
though - given that it's pervasive behavior for sites to embed ads on their
pages, which set cookies. The user that cares about this will have "protected"
themselves in some way, e.g. a sensible session-only cookies option or a
whitelist option. The user that doesn't will likely not care about the extra
cookies prefetching will introduce. Those that do can simply disable prefetching.

wrt the site bustage, that seems like something we'd want to fix. I see two
solutions:

(1) site authors disable prefetching for such sites, knowing that prefetching
breaks in such situations

(2) we provide some kind of "cookie sandbox" for prefetched pages. If the link
is visited, we "replay" the actions necessary to set the cookies into the
backend; otherwise, we just throw them away.

Note that (2) would also have an effect on privacy, since we'd be treating all
prefetches as sandboxed such that nonvisited links could never set permanent
(nonsession) cookies.

Or maybe there's a solution to this that site authors could employ? darin?

Comment 5

[Alec Flett]

Well, the problem is that basically every site that comes up as a "first hit" on
google now has the opportunity to track your searching... each time they come up
as a "first hit" whether or not I visit that site. This could easily be used 

this is the same reason we block 3rd party cookies by default... think of a
prefetch like an embedded image.. if I am a web page on http://www.foo.com/ and
have an embedded image <img src="http://www.bar.com/"> then bar.com can't set a
cookie - that's today's behavior as I understand it. The same should be true of
prefetched pages.

Comment 6

[[e-mail]]

(In reply to comment #5)

I think some of your 1st para got chopped off.

> this is the same reason we block 3rd party cookies by default...

Actually it's not, we just blanket accept in both fx and suite :/

If we considered the prefetched pages a 3rd party cookie by default, we'd still
leave open the possibility of breaking them, and the user wouldn't have any idea
why. It's kind of a skitzophrenic case; from a privacy perspective the preloaded
site is initially a 3rd party, but once you click it becomes a 1st party. A
cookie sandbox would be the only way to effect this change, short of reloading
the page. I can't think of any other objects (images etc) that would care, so I
think cookies are the only problem here...

We could, of course, just disable cookies for prefetching and accept the site
bustage. I personally don't like that.

Technically, a cookie sandbox would be a pain to implement. We'd need to hold a
separate instance of nsCookieService (to maintain a dynamic cookie list, since
site content may depend on the interaction of fresh cookies with existing
cookies) and associate it with the load somehow, so that we use the right one
for each site. Then we'd have to sync them when the user opens the site. At
which time the main one may have changed - pretty tough...

Comment 7

[timeless]

some of us already need sandboxes.

is it really that hard to mark cookies as "magic" such that they're temporary
(session only) unless the user visits the site in which case their standard
behavior is applied (and the magic bit is trashed)?

Comment 8

[Mike Connor [:mconnor]]

If I'm using prefetch in a web app, and there's a report that's pretty heavy,
and usually the next page viewed, but it's a bit slow to load/create, I'm going
to think about prefetching that.  But if my app is using cookies to manage
sessions, and we sandbox the prefetched page, then the cookies already stored
won't send, so the app prefetches a login page.

I'd rather just leave it to people concerned with privacy to disable prefetch.

Alec: can't the sites already get referrer/IP info without cookies? What is the
significant difference for the average user between getting and not getting cookies?

Comment 9

[Darin Fisher]

WONTFIX.  Disable prefetching if you are concerned about this problem.

Remember: Websites can anyways use a variety of JavaScript based prefetching
techniques, including loading page contents into a hidden <iframe> or <img> tag.
 Mozilla's support for link prefetching gives the browser more control over the
prefetching process so that it can be perform prefetches in a more efficient
manner.  Breaking prefetching by disabling cookies will only discourage its use,
leading people to resort ot JS based approaches as workarounds.

I think the webapp author could work around the problem described by checking
for the "X-moz: prefetch" header.

Comment 10

[Daniel Veditz [:dveditz] (OOO: back Aug 26)]

This kind of change is way out of scope for a 1.0.3 release.