1534148 - Sending tab to device from private window should open private window on the receiving device

Status: NEW

(Firefox :: Sync, defect, P2)

Description

[rht1369]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Sending a tab between devices should respect the Private state of origin. This is important, as the user's identity could be revealed when a tab switches from private to normal state. Let's assume device A and B are linked to the same account.

Steps for Firefox (Desktop)

--- On device A

1. Open a Private Window/Tab
2. Right-click on the Private Tab and select "Send Tab to Device"
3. select device B

Steps for Firefox for Android

--- On device A (Android device)

1. Open a Private Window/Tab
2. Tap the menu icon (three dots)
3. Tap "Send to other devices"
4. select device B

Actual results:

--- On device B
Tab opens in a normal Firefox window (not a private window)

--- On device B (Android device)
Tab opens in as a normal tab (not a private tab)

Expected results:

--- On device B
If a private window is open the tab should open in the private window, otherwise a new private window with the tab should be opened

--- On device B (Android device)
Tab should open in as a a private tab

Comment 1

[laszlo.bialis]

Hi,

I can reproduce this issue between Firefox Nightly 67.0a1 20190314094420 and Release 65.0.2. Indeed when a tab is sent from private browsing mode to another browser (device) the tab is opened in normal mode. Assigning a component to get a start on this.
Thanks for your contribution.

Comment 2

[Lina Butler [:lina]]

Send Tab doesn't currently send private window state at all, but I think we can add it.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

We should probably start thinking about containers too and I believe if you squint a little, a private-browsing is basically a container.

Comment 4

[rht1369]

(In reply to Mark Hammond [:markh] from comment #3)

We should probably start thinking about containers too and I believe if you squint a little, a private-browsing is basically a container.

While I also had noticed containers and believe it is a good idea to support them, I didn't mention them in this bug report to avoid clumping the two issues together for these reasons:

• While supporting containers is a "nice to have" feature, support for Private browsing is necessary. Private browsing at its core behaves differently and therefore is used differently as opposed to containers. While containers keep user sessions separate, private browsing does more to keep the identity of the user safe: e.g., Content Blocking, Do Not Track, clearing browsing history, etc. I think support for private browsing takes precedence and is inherently a flaw from privacy standpoint in the Send Tab feature as it stands.
• While all instances of Firefox on all platforms support private browsing, containers are added using an extension. It is not guaranteed that the installed extensions are the same across all instances of Firefox using the same account. This is definitely the case, for example, for Firefox on Android vs PC. You guys know more about that, but at some point containers were shipped as a feature in Nightly but I'm not sure if it ever came to Firefox. And because of that not all users are aware of the existence of containers.
• Even if the Containers extension is installed on all the instances of Firefox for one user, the extension does not require (and in fact should not require) the user to have the same list of containers in all instances of Firefox on different devices. For example, at work a user might have "work" and "personal" containers. But at home they might have "gmail account 1", "gmail account 2", etc.

I think a separate bug report should be made for supporting containers because of the complications involved in it. That way the lack of urgency for delivering support for containers would not delay delivery of support for private browsing.

Comment 5

[Diana Robinson]

Attachment: same problem

Thanks from paytreadwiszbe1976.