I'm playing around trying to find a way to municate between two browsers on the same network to establish WebRTC without a server roundtrip (no STUN/ICE/TURN). Basically an alternative to the approach found here, where the "handshake" is done via copy/mail/pasting.

After sifting through all the cross-browser-munication examples I could find (like via cookies or WebTCP) plus a bunch of questions on SO (like here), I'm back to wondering a simple thing:

Question:
If Alice and Bob visit the same page foo.html while on the same network and they know each others' internal assigned IP addresses, are there any ways they can municate purely with what is available on the browser?

This excludes non-standard APIs like Mozilla TCP_Socket_API, but other than that all "tricks" are allowed (img tags, iframes, cookies, etc.).

I'm just curious if I can listen to someone on the same network "broadcasting" something via the browser at all.

Edit:
foo.html will be on static server, no logic, no ICE, no shortcut.

Edit:
Still not a solution but a websocket server as Chrome extension es closer. Example here: almost pure browser serverless WebRTC

I'm playing around trying to find a way to municate between two browsers on the same network to establish WebRTC without a server roundtrip (no STUN/ICE/TURN). Basically an alternative to the approach found here, where the "handshake" is done via copy/mail/pasting.

After sifting through all the cross-browser-munication examples I could find (like via cookies or WebTCP) plus a bunch of questions on SO (like here), I'm back to wondering a simple thing:

Question:
If Alice and Bob visit the same page foo.html while on the same network and they know each others' internal assigned IP addresses, are there any ways they can municate purely with what is available on the browser?

This excludes non-standard APIs like Mozilla TCP_Socket_API, but other than that all "tricks" are allowed (img tags, iframes, cookies, etc.).

I'm just curious if I can listen to someone on the same network "broadcasting" something via the browser at all.

Edit:
foo.html will be on static server, no logic, no ICE, no shortcut.

Edit:
Still not a solution but a websocket server as Chrome extension es closer. Example here: almost pure browser serverless WebRTC

• javascript
• html
• browser
• webrtc
• p2p

• 1 From where is foo.html served? – Bergi Commented Nov 26, 2014 at 12:02
• Good point. Could be same network. – frequent Commented Nov 26, 2014 at 12:03
• I meant: If foo.html is server by a server (which is reachable from both clients), then it's probably most easy to set up an ICE server at that location. Would be more interesting if foo.html is app-cached, or a local file, or served by one of the two "clients". – Bergi Commented Nov 26, 2014 at 12:22
• So then the more interesting approach, because I don't want to use ICE – frequent Commented Nov 26, 2014 at 12:27
• If it's a static server (no server-side-languages) then the answer is still no. Interestingly enough you'll have munication between the two but not in any way you would be able to usefully control. The only way you can currently get a web browser to talk directly to another is by using STUN/TURN/ICE servers. The browser needs one of these servers in order to make the initial handshake. Without it, you have no way for the browser to listen for ining munications and therefore you literally have nothing to go on for P2P in a browser except for third-party browser addons and extensions. – Jonathan Gray Commented Nov 26, 2014 at 13:25

4 Answers 4

Yes, you can establish a direct connection between two browsers over the local network using WebRTC. It requires the use of ICE, but that does not mean that an outside STUN or TURN server is needed. If the browsers are on the same network, ICE will succeed with only the local candidates of each browser.

STUN/TURN is needed only in order to guarantee that two endpoints can establish a connection even when they are in different networks and behind NATs.

In fact, if you use most of the WebRTC example applications (such as apprtc) with two browsers connected in a local network, ICE is most likely to select and use the pair of local addresses. In this case a channel allocation on a TURN server will be made, but it will not get used.

In your WebRTC application, you can disable the use of STUN/TURN by passing empty iceServers when you create the PeerConnection.

While the MDN documentation lists WebSocketServer as a client API, I don't think this is accurate (maybe they wanted to document there how to write a server).

At the moment, I know no standard way to create a server socket on a web browser. I know a couple of attacks to scan the local network but most of them rely on an active server outside the network, that is you connect to a server and get JavaScript back which opens a WebSocket connection. Via that connection, I can take full control over the client and have it open more WebSockets with local IP addresses to scan the internal network.

If internal web sites don't implement CORS correctly (see here), I can access all internal web sites where the current user is currently logged in. That is a devious attack vector which allows external attackers to browser internal documents without cracking anything. This page has a demo of the attack.

Even Flash won't let you create a server socket.

If you allow a Java applet and the Java version on the client is very old or the user blindly clicked "OK", then you can create server sockets.

Related:

• Socket Server in Javascript (in browsers)?

This could be explained easily. The answer is it's not possible. In order for alice and bob to municate at all without a third-party, at least one of them needs to be listening for ining connections. Not possible using a standard web browser alone.

You can take a look at this

https://github./jed/browserver-client

I think that you can easily create an http server with javascript and send messages from one browser to another

With Nodejs you can achieve the same.