Closed Bug 765378 Opened 12 years ago Closed 11 years ago

SecReview: Notifications Back End - Websockets

Categories

(mozilla.org :: Security Assurance, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: curtisk, Assigned: dchanm+bugzilla)

References

Details

(Whiteboard: [action item])

SecReview tracking bug
Actions regarding the review of the dependent bug should be tracked here.

are websockets torn down when going to privacy mode?
I talked to mcmanus about websockets and private browsing. Websockets are torn down when a tab is closed. [1] There is on outstanding question about the interaction with hiddenDOMWindow [2]

smaug: Can you comment on the hiddenDOMWindow interaction? Does dom-window-destroyed and/or dom-window-frozen get dispatched to a hidden window on entering private browsing?



[1] - http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsWebSocket.cpp#1609
[2] - https://github.com/jbalogh/services-central/blob/notifications/services/notifications/utils.js#L24
I know nothing about private browsing.
ehsan or jdm might know.
Why would we want to tear them down when going into private browsing mode?
Ehsan: Are you referring to the notifications use case or in general? I'm not concerned with the general usecase since the tab with the event handler is no longer around on entering private browsing.

For the notifications use case, it depends on the expectation from JR and team.  It seems weird to me that a websocket would be persisted if the rest of the browser state is "reset".

JR: What is the desired user experience? continue receiving notifications? queue up all notifications received in PB? other?
I don't know a lot about WebSockets, so I was trying to gather more information.  What are the notifications use cases?
(In reply to Ehsan Akhgari [:ehsan] from comment #6)
> I don't know a lot about WebSockets, so I was trying to gather more
> information.  What are the notifications use cases?

We're adding push notifications to Firefox, so the use case is having an always-open connection to the notification server so you receive messages as soon as they're sent. That connection uses a WebSocket attached to the hiddenDOMWindow.

The technical question here: when I go to Private Browsing Mode, does the hiddenDOMWindow get reset? If no one knows the answer, I can find out through experimentation eventually.

The decision yet to be made is whether you should continue receiving notifications when you switch to private browsing mode.
(In reply to Jeff Balogh (:jbalogh) from comment #7)
> (In reply to Ehsan Akhgari [:ehsan] from comment #6)
> > I don't know a lot about WebSockets, so I was trying to gather more
> > information.  What are the notifications use cases?
> 
> We're adding push notifications to Firefox, so the use case is having an
> always-open connection to the notification server so you receive messages as
> soon as they're sent. That connection uses a WebSocket attached to the
> hiddenDOMWindow.
> 
> The technical question here: when I go to Private Browsing Mode, does the
> hiddenDOMWindow get reset? If no one knows the answer, I can find out
> through experimentation eventually.

Are you talking about the hidden DOM window we use on the Mac?  Or something else?  (We don't touch the former when going into the PB mode).

> The decision yet to be made is whether you should continue receiving
> notifications when you switch to private browsing mode.

Do you send things like cookies over this channel?  Do the requests get cached?
(In reply to Ehsan Akhgari [:ehsan] from comment #8)
> Are you talking about the hidden DOM window we use on the Mac?  Or something
> else?  (We don't touch the former when going into the PB mode).

I'm talking about the hiddenDOMWindow attribute on the AppShellService: https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIAppShellService#section_2

> > The decision yet to be made is whether you should continue receiving
> > notifications when you switch to private browsing mode.
> 
> Do you send things like cookies over this channel?  Do the requests get
> cached?

The channel receives messages intended for the user of your normal profile. It sends an authentication token on setup, so if we kept the channel open, it would be bound to the identity of the "normal browsing mode" user.
(In reply to Jeff Balogh (:jbalogh) from comment #9)
> (In reply to Ehsan Akhgari [:ehsan] from comment #8)
> > Are you talking about the hidden DOM window we use on the Mac?  Or something
> > else?  (We don't touch the former when going into the PB mode).
> 
> I'm talking about the hiddenDOMWindow attribute on the AppShellService:
> https://developer.mozilla.org/en/XPCOM_Interface_Reference/
> nsIAppShellService#section_2

No, we don't handle this window especially for PB at all.

> > > The decision yet to be made is whether you should continue receiving
> > > notifications when you switch to private browsing mode.
> > 
> > Do you send things like cookies over this channel?  Do the requests get
> > cached?
> 
> The channel receives messages intended for the user of your normal profile.
> It sends an authentication token on setup, so if we kept the channel open,
> it would be bound to the identity of the "normal browsing mode" user.

Then the channel needs to be closed during PB mode.

Note that over in bug 723353, we're looking to switch to a per-window private browsing mode.  In that mode, it would be fine for the channel to remain open, as long as the notification is not shown on private windows (I don't know how the UI for the notifications is implemented.)
This looks to be resolved. We may have to revisit the bug for per-window private browsing.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.