[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3739 [TorBrowserButton]: SafeCache policy likely fails for https->http CORS (and reverse)
#3739: SafeCache policy likely fails for https->http CORS (and reverse)
----------------------------------------+-----------------------------------
Reporter: mikeperry | Owner: mikeperry
Type: defect | Status: new
Priority: major | Milestone: TorBrowserBundle 2.2.x-stable
Component: TorBrowserButton | Version:
Keywords: MikePerryIteration20110828 | Parent:
Points: 2 | Actualpoints:
----------------------------------------+-----------------------------------
Comment(by gk):
I have not had time to comment on ticket 3665 but I would not recommend
you to use the Referer as a fallback if using notificationCallbacks is
futile. There are scenarios where that does not help either (I encountered
one during my tests of our preliminary defense against HTTP Auth tracking
that uses as well notificationCallbacks to get the associated window of a
request/response and if none is available (or getting the window out of it
failed) I tried to get the Referer. I got one but that did not trigger the
separation logic...). Rather, I would suggest using getOriginatingURI()
available via nsICookiePermission and implemented by
@nozilla.org/cookie/permission;1. That solved the problems I had and will
probably not affect https -> http transitions. Maybe that's the silver
bullet we are looking for here. Or it may open new corner cases...
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3739#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs