1079648 - Pref on TCPSocket on desktop Firefox / all gecko targets and hide it only behind tcp-socket permission

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

I'm not aware of a bug on enabling mozTCPSocket/TCPSocket more widely.  Currently, it's enabled in the following targets and disabled by default everywhere else:
- b2g in b2g/app/b2g.js (enabled from the get-go on bug 733573)
- desktop webapprt in webapprt/prefs.js (by bug 892833)
- android webapprt in mobile/android/chrome/content/WebappRT.js

Because the security model assumes privileged apps (and therefore apps), it's possible we're already where we want to be right now by having b2g and the webapp runtimes have the preference enabled and nowhere else.

It's also possible that the way mozTCPSocket ends up in the global namespace (using JavaScript-nagivator-property) is a bad/legacy idea and this would involve some WebIDL changes or what not.

meta-note: I'm still never sure which component TCPSocket bugs go in but I've been filing them here in Core :: Networking and no one has complained, but that doesn't mean they shouldn't go someplace else.

Comment 1

[Josh Matthews [:jdm]]

I imagine this belongs in the DOM component given the nature of the request.

Comment 2

[Patrick McManus [:mcmanus]]

fwiw tcp socket leads to some seriously bad security practices.. b2g can basically argue for it because it needs to be compatible with existing bad security practices (e.g. plaintext pop3), but this is not a footgun we should be spreading around further than absolutely necessary.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> It's also possible that the way mozTCPSocket ends up in the global namespace (using
> JavaScript-nagivator-property) is a bad/legacy idea

Yes, it is.  See bug 885982 for fixing that.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Patrick McManus [:mcmanus] from comment #2)
> fwiw tcp socket leads to some seriously bad security practices.. b2g can
> basically argue for it because it needs to be compatible with existing bad
> security practices (e.g. plaintext pop3), but this is not a footgun we
> should be spreading around further than absolutely necessary.

Right, raw network sockets are dangerous.  I'm not suggesting that we remove the requirement for the origin to have the "tcp-socket" permission check.  But the idea is that if we have an actual granular protection on TCPSocket, then having the big on/off boolean off on some of our platforms is somewhat inconsistent.  But maybe it's okay and advisable for the use-cases.

The current use-case I'm thinking of us are basically email apps.  For the Gaia email app we'd like to create a desktop version.  And https://whiteout.io/ is trying to create a multiplatform email app too; they're even in the marketplace (but searching for it is disable until various bugs/issues are ironed out).

Our protection mechanism requires the apps to be privileged (and thereby blessed by an app store) in order to get the permission.  As noted above this may mean desktop Firefox and Android Fennec are already okay because of the separate webapp runtimes.  Then the only question is whether the extra preference is actually helping people or just frustrating them when they try and run the code locally in the browser (after explicitly blessing their origin).

Comment 6

[Felix E. Klee]

Another use case is communication with devices, e.g. Wi-Fi enabled cameras: 

https://marketplace.firefox.com/app/theta-control 
https://marketplace.firefox.com/app/trigger

Those apps stopped working, which I reported in: 1106259 (is that really a duplicate?)

Comment 7

[Jet Villegas (inactive)]

We need this feature for Shumway (see bug 1125156) to support RTMP use-cases (eg. live streaming video) 

http://www.adobe.com/devnet/rtmp.html

...but the origin checks won't be there (as they aren't in Flash today.) That's not a concern if we can keep the data from leaking out of Shumway. We'll do the security reviews, and make any changes required in Shumway to maintain data security. 

Plan A is to leave the transport logic in Shumway (content privilege.) We may add a domain whitelist to restrict this to sites we test (eg. live sports) to keep users safe.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jet Villegas (:jet) from comment #7)
> We need this feature for Shumway (see bug 1125156) to support RTMP use-cases
> (eg. live streaming video) 

You're probably going to want to prioritize bug 1059081 getting fixed then.

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Reword the summary based on comment 4. I don't see a reason why we don't do that.

That said, you could easily sideload an add-on and change the pref (and grant the permission on a specific URL together).

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

It turns out bug 1286530 mooted the preference and the "tcp-socket" permission in the patch found at https://reviewboard.mozilla.org/r/63962/diff/2#index_header (the actual commit is everything squashed).

TCPSocket is now exposed only to the system principal by TCPSocket::ShouldTCPSocketExist().  There is no preference check, there is no permission check.  If you have a non-WebExtensions add-on (executing with the system principal), TCPSocket should be available to your Window/System global.  If you have a WebExtensions addon, TCPSocket will not be exposed and you must wait for bug 1247628 to be addressed.

Relatedly, UDPSocket still is slightly different.  It went from a "udp-socket" permission check to being ChromeOnly.  Its WebIDL exposure still depends on "dom.udpsocket.enabled" being set to true, which is still only the case for b2g.  (And WebRTC doesn't care about the WebIDL exposure, it accesses things via nsIUDPSocketChild.  Bug 1247628 is also probably the right bug to follow for having UDP access in WebExtensions.