Research
Security News
Quasar RAT Disguised as an npm Package for Detecting Vulnerabilities in Ethereum Smart Contracts
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
@browser-network/network
Advanced tools
The Network is a peer to peer, decentralized, browser based network. It uses WebRTC to connect directly from browser to browser. Every browser window connects to many others, creating a robust network through which messages can be sent.
Using the app is participating in the network.
There's nothing to mine.
The network is designed to have an arbitrary number of nodes come up and down for an arbitrary length of time
Messages are mathematically guaranteed to come from who they say they're from
Therefore is not hampered by the switchboard's ability to simultaneously hold many websocket connections.
The Network can be dropped into any web app via npm or cdn and the app will become an interconnected network of all the users who currently have the app open.
A million and one things can be done with such a network. The original impetus for writing this was to create a decentralized database of sorts to enable truly serverless real time state updates on the web. This could be used for something like a social network to great effect. It'd mean no intermediary between users and their data. Each user does some of the work of saving states and communicating on the network. The incentive to run the code is to use the app.
Really anything that requires real time capabilities will work with this. What immediately comes to mind:
Self Healing - when a connection breaks, a node on the network establishes a new connection with another node. The network internally gossips WebRTC handshake information to (re)establish connections with disconnected nodes.
Lightening fast - the network establishes many connections usually within one second of starting up.
The only external reliance is on a lightweight http only switching service which has a small resource footprint. Note it does not rely on websockets, just regular http requests.
This software can be run in both browsers and in node.js. That means you can have a permanent network node set up somewhere headless in a node.js process if you want.
This software defines a set of message protocols that can be used with any other webRTC enabled hardware. This means one network is not limited to having browsers and node.js instances only - phones implement webRTC in browsers, and webRTC is enabled natively for both Android and iOS.
If you do want full uptime and a similar user experience to an app with a server,
you can just leave a browser window of your app open. Another way of saying this,
is the only programming you have to do to have a real server is opening up a
browser window :P Note that if you wish to do slightly more programming, you can
also run a node.js node with the same networkId
, and it will act as a headless
browser window, fulfilling all the same functionality as a browser window would.
Cryptographic security - Network uses eccrypto
to ensure veracity of messages.
It's cryptographically difficult to spoof or modify a message that's not your own.
This feature can be turned on for more security or off for faster performance if
your network doesn't need to be secure.
When you first open the webpage, the app does need some way to find at least one node on the network. So we have a switching service.
Once we connect to another node that's in a network (by we here, I mean a node, if the reader will allow), then we'll start to hear messages from our "neighbor" nodes, which is to say, those in the network we're directly connected to. The messages may originally come from those neighbors or they may not. Each message has a ttl (time to live). If we receive a message with a ttl > 1, we decrement it and pass it along on to our neighbors. In this way, the whole network can receive messages even though not every node is connected to each other.
Some of the messages we'll be hearing will be open connection information (rtc "offer" SDP info). If one of those is for someone we're not yet connected to, we'll generate a response (rtc "answer" SDP info based on the original offer), and send that response back out into the network to the node that originally sent it. If they receive it, a direct connection will be established. It's by this means that the network is self healing.
There are various schemes in place for efficiency.
config.maxConnections
).The switching service can facilitate a connection between any two nodes that are not already connected. So if you're a node who isn't yet connected to the network, you'll ping the switching service and find and connect to one node who's already in the network. Then immediately you'll start receiving connection information from other nodes in the network and you'll rapidly bolster your connectivity.
The switching service has negligable processing and memory footprints. It operates only in memory, it doesn't need a database or write to disk in any way. The switching service will be exchanging small JSON data with various nodes in the network so it will use some small bandwidth. But it's important to note that this is not anything like a cryptocurrency miner, the resource usage of the switching service is meant to be as small as possible.
One service can handle multiple apps so you will probably not have to run one. However if you do want to run a switching service, a node.js implementation is available here.
npm install @browser-network/network
or
<script src="//unpkg.com/@browser-network/network/umd/network.min.js"></script>
This is about the simplest app I could come up with - it lets you send and see messages in the browser console.
<!doctype html>
<html lang="en">
<body>
<script src="//unpkg.com/@browser-network/network/umd/network.min.js"></script>
<script>
const network = window.network = new Network.default({
switchAddress: 'http://localhost:5678', // Run npx `@browser-network/switchboard` to get this running locally
address: 'my-address-' + Date.now(), // Each window should have its own address, hence the Date.now()
networkId: 'test-network' // Everyone using this id will receive messages from each other
})
network.on('message', console.log)
let counter = 0
setInterval(() => {
counter += 1
network.broadcast({
// Fer message differentiation
type: 'amazing-hello-message',
// Pass around data
data: 'This is message number ' + counter,
// identifier for the library or subsystem using this message.
// Allows for a complex system to not have to worry about message
// type collisions, or to be bombarded by network or library level
// messages.
appId: 'my-cool-app-id'
})
}, 1000)
</script>
</body>
</html>
Copy and paste that html into some html file of your choosing on your machine. Then in one terminal:
npx @browser-network/switchboard
And in at least two more, open your html file. You should start to see messages being passed back and forth in the console.
First up, instantiate a Network.
// If you're cool bringing Browserify into your build process, you can require
// these straight up:
import Network from '@browser-network/network'
import { generateSecret } from '@browser-network/crypto'
// However, if you don't want to use Browserify in your build, and you're cool
// with statically linking to these libraries (which means any libraries you and
// Network share will be duplicated in your final build), you can do this, which
// is what I normally do using Network:
import type Network from '@browser-network/network'
import type { generateSecret as GenerateSecret } from '@browser-network/crypto'
const Net = require('@browser-network/network/umd/network').default as typeof Network
const { generateSecret } = require('@browser-network/crypto/umd/crypto') as { generateSecret: typeof GenerateSecret }
// One of the goals for this library is to be really nicely typed. As such, TypeScript
// users can pass in what kind of messages they'll be sending/receiving, and the library
// will help you out a ton when sending messages and receiving them. Note when you receive
// a message, it'll always by of type `MyMessage & Message`, where `Message` is defined internally
// in Network. It's exported for convenience.
type MyMessages = {
type: 'hello-message',
data: { greet: 'Hello!' }
appId: 'my-app-id'
} | {
type: 'goodbye-message',
data: { part: 'Goodbye :(' }
appId: 'my-app-id'
}
// `new Net` if you're statically linking Network, otherwise if you're importing like regular, `new Network`.
const network = new Net<MyMessages>({
// default address of switchboard
switchAddress: 'http://localhost:5678',
// By passing in secret instead of `address`, we're telling network to cryptographically ensure all messages
// against spoofing. For a less secure network but a little performance gain, pass in `address` instead, with
// a unique address per node.
secret: generateSecret(),
// This needs to be unique enough to avoid collisions between different apps. If your `networkId`
// is the same as some other app that's using the same switchboard, the two apps will start to
// hear each other's messages!
networkId: 'a87wyr-awfhoiaw7yr-3hikauweawef-ryaiw73yriawrh-faweflawe',
// See more below...
config:{
offerBroadcastInterval: 1000 * 5,
switchboardRequestInterval: 1000 * 5,
garbageCollectInterval: 1000 * 5,
maxMessageRateBeforeRude: 1000,
maxConnections: 10
}
})
See the network config type for more info on the config object.
Network is essentially a message event emitter, so listening for messages will be your main interaction with the network.
...
network.on('message', (mes) => {
// You'll usually want to ensure the message is for your app. It's
// just a way to namespace your messages amongst the sea of other
// messages on the network.
if (mes.appId !== myAppId) return
// Now you can specify that this message is one of yours. I'd like this to
// be a little cleaner and not require this specification, but the lack of runtime types
// makes it hard:
const message = mes as MyMessage // MyMessage is declared above
switch (message.type) {
case 'hello-message': {
console.log(message.data.greet)
break
}
case 'goodbye-message': {
console.log(message.data.part)
break
}
}
})
See more about the Message type
Aside from listening to messages, you'll of course also want to send messages:
network.broadcast({
type: 'hello-message',
appId: 'my-app-id',
data: { greet: 'Hello!' }
})
The network will fill in all properties from Message
that were not passed in aside
from what's above, which is required.
Network also exposes a way to see all of the connections currently established:
network.connections() // -> Connection[]
See more about the Connection type
If you're building with this project for the browser, the best way to build your project, (and how this project builds its CDN exports), is with Browserify.
See the package.json for how this project builds for CDN vs ESM library style.
TODO
FAQs
A WebRTC based direct peer to peer network in the browser.
The npm package @browser-network/network receives a total of 0 weekly downloads. As such, @browser-network/network popularity was classified as not popular.
We found that @browser-network/network demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.