
FlyWeb – An API for web pages to host local web servers - collinmanderson
https://flyweb.github.io/posts/2016/11/01/introducing-flyweb.html
======
macawfish
I'm very excited about this! I've been waiting for something like this for a
long time!

To me, the power here is in using the technology to foster local, human-scale
interaction.

Intranets are totally underutilized. How many people do you know who can
reliably transfer personal files over a local area network? Not nearly as many
as those who know how to use google or send an email... that's absurd to me,
given how ancient of an application file sharing is.

It's my opinion that the survival of the internet may very well rest on p2p
webs like this.

~~~
sjellis
"Intranets are totally underutilized. How many people do you know who can
reliably transfer personal files over a local area network? Not nearly as many
as those who know how to use google or send an email... that's absurd to me,
given how ancient of an application file sharing is."

It's crazy to me that there AFIAK aren't AirDrop clones. That application
alone would make this awesome, and it will probably just one of the big use
cases for this.

I'm also really pleased to see Mozilla producing this kind of innovation. I'm
a Firefox user at home, and am starting to get really excited about Rust, but
it has felt to me like the organization has been flailing for a while.

~~~
floatboth
Of course there are AirDrop clones.
[http://instashareapp.com](http://instashareapp.com) — oh wow their current
slogan is "better AirDrop for mobile & desktop"! There are also open source
WebRTC based ones like
[https://github.com/RobinLinus/snapdrop](https://github.com/RobinLinus/snapdrop)

~~~
sjellis
I wasn't aware of SnapDrop, so thank you for that. I'm aggressively
uninterested in proprietary desktop software these days, outside of work.

------
nstart
This is potentially huge. If other browsers can also jump into this, we could
potentially see a rise in a new generation of apps that are local first and
enable much richer real time collab features. I might be reading into this
wrong but this could also usher in a better and open implementation for iot
devices to provide interfaces for the user. Excited to adopt this and try some
experiments out.

One interesting thing to figure out is the combination of local and global.
When I have an iot device and I'm away from home, or someone collaborating
with me from a different location, the same app needs to fall back to using
standard internet based interfaces. Not sure if that disqualifies it from
being a potential use case of this.

~~~
benevol
> If other browsers can also jump into this

The other major players being Google and Apple, they'll almost certainly want
to push their proprietary app platforms to increase their market power,
instead of open technologies which are in the interest of and benefit the
consumer.

~~~
jayajay
That's just wrong. Imagine a (definitely plausible) future where a snapchat-
level social app is created which relies on this local communication. People
would obviously jump ship from Chrome to FF if it meant being on the new local
social network where all of their friends are. Google isn't going to keep a
stick up it's ass when this happens. They will conform, because they follow
the money.

~~~
benevol
I sure hope your scenario will happen. I'm just saying Google or Apple will
probably not actively push this technology. And most app developers are either
Apple or Google platform addicts (A and G being the duopoly in the mobile
application space).

------
shakna
This is actually kind of cool. The discoverable features for pre-existing non-
FlyWeb servers stands out to me.

Secondly, the FlyWeb server gives you access to a really flexible API for
serving just about any content.

It feels like federated content, we just need to question whether it should be
locked to the local network.

------
formula1
Im not reading anything about opening ports on your routers firewall. Does
this somehow circumvent this? Reading it further it seems to explicitly say
"local" which probably implies you.ip.address.[0-255] is targeted.

I think this technology is intriguing and with some real use cases (more peer
to peer) but the api seems disorganized. I cant tell if it wants to be another
webstandard or be something different.

A part of me wants to dislike this and consider it as a distasteful competitor
to pre-existing technologies that have learned to survive without "the web".
Another part realizes that sandboxing these technologies protects and enables
the average user in regards to awesome tech. This certainly wont replace
torrent, webrtc or other existing p2p technology. But I certainly think its a
cute way of opening up the field.

~~~
djsumdog
From what I can tell, it's for localized apps within say, your home network.
Imagine being able to start a game and other people not need to download
anything to join. Your phone announces it, they open their browser, see a list
of Flyweb apps and connect to your game (like in the car racing demo video up
further in the comments).

The thing that I worry about though, is that you're starting a local web
server from within your browser. I feel like they're some big security
concerns that should be addressed in like the opening paragraph.

Also that red background for their website is terrible. :-P

------
SchizoDuckie
Oh great. yet another way for ad services and botnets to talk to eachother...

Because yeah, that's where this is going to be used first and foremost.

Most people are not intelligent enough to understand how to secure their
internet banking, and now we're going to bake-in hosting tcp connectable
servers?

These security prompts better have some real clear language and require giving
permissions every time.

Now I can see some good things for this too, start a flyweb from your desktop
and easily transfer some stuff from your phone for instance (something that
_still_ sucks in 2016)

I just think that most of it's use will be malicious.

~~~
userbinator
_Now I can see some good things for this too, start a flyweb from your desktop
and easily transfer some stuff from your phone for instance (something that
still sucks in 2016)_

I would just plug in a USB cable for that...

But this is definitely feeling like a reimplementation of more things that
should be served by the OS into the browser, a concept that I am rather
opposed to. I'm probably getting old, but I'd rather the browser stay a simple
hyperdocument viewer than turn into a crude approximation of an OS.

------
Animats
There seem to be two parts to this. One is a way to inventory your LAN using
multicast DNS and find all the web servers on it. (There may be one in every
lightbulb.) The other is to run a web server in the browser. These are
independent functions.

The first seems useful. The second seems to need a more compelling use case.
Also, opening the browser to incoming connections creates a new attack surface
in a very complex program.

~~~
xnyhps
FYI, the first part isn't new. Safari already uses mDNS to find webservers on
your LAN. For me, this is also supported by my printer, so I can just go to
the Bonjour bookmarks to find the admin interface without having to remember
its IP address.

What _is_ new (and what appears to make Mozilla's implementation incompatible)
is that they are adding a layer of UUIDs to ensure each service gets a
separate origin. This ensures that, if you switch between LANs, an open tab
for one device can't interact with a device on the other LAN with the same
name or IP address. Makes a lot of sense for the security of IoT devices.

~~~
kannanvijayan
The UUID approach was a stopgap to solve the same-origin issue in the short
term and stand up a simple prototype proof of concept.

Longer term, I think we'll need to use a separate URI scheme (e.g. fly://). It
turns out upon further investigation that the ([http://](http://)) scheme
relies heavily on TCP semantics. For example, port numbers are an
implementation detail in flyweb, not something explicitly exposed via URI, but
http demands that port numbers be interpreted (and without a port number, an
origin assumes port 80).

We also want to restrict the underlying wire protocol to be a subset of HTTP,
eliminating a number of the purely internet-related functionality, such as
redirects and proxies.

We also need to specify different security semantics for interpretation of TLS
certificates in the FlyWeb context. Devices are not websites, and they're not
identified by internet-DNS names, and the current certificate model is
oriented to work with that design.

We're slowly working through resolving all of these issues. The idea is
simple, but the execution requires care and attention to detail.

------
realworldview
I'm obviously reminded of
[http://www.operasoftware.com/press/releases/general/opera-
un...](http://www.operasoftware.com/press/releases/general/opera-unite-
reinvents-the-web). Is Mozilla reinventing the web again, too? Will this
following the footsteps of Persona, and all those other Mozilla experiments. I
would prefer less focus on such a public lab space where money is thrown, and
greater focus on reality. Sorry for the negative view but Mozilla appears to
have the same lack of focus problems as many other companies.

Edits: speling correctoins

~~~
kannanvijayan
Hi there, I work on the FlyWeb team, and initiated the project within Mozilla.

Most of Mozilla's dev resources right now are being targeted towards core
development: the e10s process isolation work, the quantum graphics and
rendering speedup work, general stability and crash rate work, asm.js and
webasm work, etc. etc. The vast, vast majority of resources are being
allocated to those core concenrs, and that's a direction I personally agree
with.

FlyWeb is a very low-overhead experimental project with an eye to the long
term. There are two people on the team, me and Justin D'Arcangelo.

I've said this before on HN, but there are no guarantees. I personally want
this project to succeed, but that success depends on a lot of factors.
Implementation work, security work, adoption, interest, market viability and
other factors. We're working hard to make a viable path to success for the
project.

Cheers.

~~~
hackerfromthefu
Hi, the first things I thought of here is pages you are browsing snooping on
or hacking other browser pages, e.g. ad payloads across multiple open pages
communicating in realtime in their tracking of you.

Could that be a major change in the abstraction of independence/encapsulation
of web pages, or in other words a break against user protections in the
contract of using a web browser instead of applications.

So, please keep security and privacy as first order design considerations with
this :)

------
BHSPitMonkey
Here's a little Chrome addon I just whipped up which lets you browse and
launch local FlyWeb services:

[https://github.com/BHSPitMonkey/flyweb-browser-
chrome](https://github.com/BHSPitMonkey/flyweb-browser-chrome)

~~~
chaz6
Thanks for this! How do I install it?

~~~
johnhenry
Instructions would be useful... [https://github.com/johnhenry/flyweb-browser-
chrome/tree/patc...](https://github.com/johnhenry/flyweb-browser-
chrome/tree/patch-1). Hopefully the developer accepts the pull request.

~~~
BHSPitMonkey
Merged :)

------
deno
It seems the feature here is server-less discovery (mdns). Because otherwise
intranet communication between apps is already possible via WebRTC.

Along that track, it would be nice to see native DHT support in the browser,
for _global_ server-less discovery.

Unfortunately, just using WebRTC is not a great fit for a DHT, because of
connection costs. Also it makes more sense to have DHT persist between app
sessions.

------
coldnebo
“Curiously enough, the only thing that went through the mind of the bowl of
petunias as it fell was: 'Oh no, not again.'"

[edit: ok, so it is cool, but I'm not sure it's secure, and I'm not crazy
about web pages from other domains being able to setup local discovery on my
network. Seems like a massive security problem. Uuids sounds like obfuscation,
not security. ]

[edit: ok, well at least they've started thinking about it:
[https://wiki.mozilla.org/FlyWeb#Security](https://wiki.mozilla.org/FlyWeb#Security)

Would like to see this fleshed out some more. ]

------
Senji
It would be interesting to see how this plays out with websockets based
torrent clients.

Meshnetwork torrent trackers with DHT anyone?

~~~
omribahumi
I was thinking IPFS

------
gpsx
I think it is a great idea for devices to be web servers to allow remote
devices to serve as their user interface.

I lean towards using bluetooth as a discovery mechanism rather than wifi.
Google's "Physical Web" I think does something along these lines, though I am
not sure whether or not they are thinking about web servers on these local
devices. I think that is a key part of the idea.

~~~
djsumdog
I feel like with Bluetooth, you have that entire extra step of pairing.
Connecting to Wi-Fi is something most people are familiar with and do
regularly ("Hey man, what's your Wi-Fi password?").

~~~
gpsx
With new bluetooth, as in with beacons, you don't have the pairing nightmares
you did before.

Of course here devices that host their own server would not be simple beacons,
but they could be found the same way.

------
jlgaddis
This looks really neat and I can immediately think of several use cases for
it.

I'm pretty cynical and jaded, though, so I went looking for and finally found
the "Security and privacy considerations" section of the FlyWeb (draft)
Specification [0]. I'm quite disappointed by what I see there -- or, rather,
what I _don 't_ see.

If Mozilla is to pursue this seriously then, in my opinion, they need to
follow a process similar to Internet Drafts [1]. Development of the spec
should be opened up to the public, other stakeholders (browser vendors and, of
course, users) should be involved, and so on.

There was a time when we could remain somewhat confident that a device behind
the firewall would not be accessible from the "Internet at large". That was
before UPNP [2] and rebinding attacks [3]. As I said, I can quickly think of
several use cases that would be perfect for something like this... but history
has clearly proven that the privacy and security implications MUST be
considered at every step of the way. This beast should be tamed before it has
a chance to get away.

Myself, I'm going to go ahead and add a new _lockPref_ entry for
"dom.flyweb.enabled" to my mozilla.cfg in anticipation of the day that this
comes to my browser. (Of course, with Mozilla's track record, they'll probably
push FlyWeb heavily for the next year or so, then just abruptly announce one
day that they're killing it off.)

[0]: [https://flyweb.github.io/spec/](https://flyweb.github.io/spec/)

[1]:
[https://en.wikipedia.org/wiki/Internet_Draft](https://en.wikipedia.org/wiki/Internet_Draft)

[2]:
[https://en.wikipedia.org/wiki/Universal_Plug_and_Play](https://en.wikipedia.org/wiki/Universal_Plug_and_Play)

[3]:
[https://en.wikipedia.org/wiki/DNS_rebinding](https://en.wikipedia.org/wiki/DNS_rebinding)

~~~
justindarc
"I'm pretty cynical and jaded, though, so I went looking for and finally found
the "Security and privacy considerations" section of the FlyWeb (draft)
Specification [0]. I'm quite disappointed by what I see there -- or, rather,
what I don't see."

Rest assured, there has been a lot more thought put towards security and
privacy than the draft spec document currently shows. That's not to say that
we have a complete security story at this very moment (we are still working on
it), but there are many more considerations than what is currently in the
document. I hope to try and provide an update in this regard in the coming
weeks.

------
pmontra
Some tips for whoever wants to try it out.

In the desktop FF Nightly the Flyweb menu must be picked from the
customization menu (Menu, Preferences, drag the Flyweb icon to the toolbar). I
think Mozilla forgot about this in their page.

Another important bit of information is how to install Nightly alongside with
the current FF [http://superuser.com/questions/679797/how-to-run-firefox-
nig...](http://superuser.com/questions/679797/how-to-run-firefox-nightly-
alongside-firefox-at-the-same-time/680160)

My take on this: interesting, especially the server side part. Instead the
server inside the browser could be at best a way to drain batteries and at
worst a security risk because of the increased attack surface. I wonder how
locality applies to phones on the network of a mobile operator vs on a smaller
WiFi network.

Anyway, if we have to rely on browsers to implement the discovery mechanism
I'm afraid that it won't fly (pun intended). I'd be very surprised if Apple,
Google and even MS will include this into their browsers. I got a feeling that
they might want to push their own solutions to sell their own hardware. I hope
to get surprised.

Maybe there will be apps autodiscovering those services or other servers
acting as bridges to a "normal" DNS based discovery service.

Btw: Mozilla should test their pages a little harder. I had to remove the
Roboto font from the CSS to be able to read it. The font was way too thin in
all my desktop browsers and FF mobile. Opera mobile was OK, it probably
defaulted to Arial.

------
Matthias247
I certainly like the discovery feature through mdns. Could be helpful for a
lot of scenarios. Windows allows out of the box already something similar by
showing UPnP devices in the network browser and double-clicking on them
navigates to their advertised webpage. That makes it windows and UPnP (instead
of mdns) only, but works with all browsers. Having it directly in the browser
would allow to have it on all OSes, which is certainly also good.

I understand why they hide the real IP addresses behind UUIDs, but I think
there should be an option to also convert it to the real IP/host address.
Because often you want to share the address of the embedded device with your
coworker, use the address in another tool, and so on.

However I'm not sold on the idea and state of the webserver in the browser
API. It just leaves a lot of questions open: E.g. pages are often reloaded,
how will this impact the experience. Or HTTP request and response bodys are
possibly unlimited streams, the simplified API however does not expose this.
What attack vectors are enabled through that and how will it limit use-cases?

------
rjmunro
Is this compatible with Safari's Bonjour functionality?

Apple have hidden it behind flags in Preferences -> Advanced in recent
versions, but when enabled, you get a "Bonjour" item in the favourites menu,
which will show the internal settings websites of compatible printers etc.
that are on the LAN.

~~~
floatboth
I don't think so. It publishes custom _flyweb._tcp.local records, not
_http._tcp.local...

------
greggman
Hey I know, I want to be able to connect to a device's flyweb server and give
it voice commands. Oh, can't do that, accessing the mic requires HTTPS.

Sorry, I didn't mean to be snarky, I worked on a project that has some surface
similarities to this (local only server) but last year when Chrome (and
Firefox?) banned a bunch of features unless youre HTTPS that pretty much
killed the project.

Thats not to say there aren't uses without those features. Its just
interesting to see Mozilla make this feature that serves pagesp that can.t use
the full range of features,

Examples:

You want to make media server but you can't go full screen

You want to use phones as wiimotes but you can't get device orientation

You want to speak into the webpage but you can't access the mic

You want to scan barcodes into the webpage but you can't access the camera

------
xg15
A very fascinating idea. I agree, an autodiscovery mechanism like the
described is badly needed for local applications. This could also be used to
implement captive portals or "special-purpose" wifi networks in a less harmful
way than currently done.

I don't quite understand the reason behind the random-UUID-as-hostnane design,
however. Yes, it protects against a service stealing another service's
cookies.

But wouldn't this also result in the same service having a different hostname
and origin each time it is discovered? Woudn't this render cookies, storage
and HTTPS(!) unusable for flyweb services?

------
adrianN
I don't really understand how this is better than just running a small
webserver. The discoverability feature is nice, but I think you could do the
same with a port scan in the local network. Can someone explain?

~~~
shakna
Discoverability is big, because port numbers can often mean anything, but the
server side is basically web workers.

Most easy to spin up servers fall into these categories:

* Static files only

* Tough to fine tune configuration

* Synchronous connections unless you want to ramp the complexity up

* Require a separately installed interpreter

Web workers within the browser solve this.

You probably don't want to use this to run a Gmail clone, but a simple media
server, maybe.

I see it as great for LANs, and potentially a simpler replacement for
SharePoint in SMBs.

------
forgottenacc57
Examples of useful reasons to use?

------
logronoide
Flyweb botnets DDoSing services in 3,2,1...

~~~
djsumdog
I'm also curious why no one else in the comments are talking about the
potential security concerns.

Or does no one remember that browsers have a built in protocol for video
conferences (WebRTC) that can be use to exploit systems behind a firewall?

------
TazeTSchnitzel
I imagine this will be the next generation of jackbox.tv-style experiences,
except with no need for the external site. That'll make these more accessible
and practical.

The stuff they've done with using phone apps to play group guessing games is a
lot of fun.

------
esafwan
Really cool. If embraced by other browsers this can have good impact in iot
space.

------
alphapapa
> Enabling web pages to host local servers and providing the ability for the
> web browser to discover nearby servers opens up a whole new range of use
> cases for web apps.

That's not all it opens up. "Enabling web pages to host servers"\--who thought
this was a good idea?

To top it off, later in the page, they tell users how to upgrade Node by
running `curl ... | sudo bash -`. Good grief, the anti-patterns!

This FlyWeb site has me seeing red.

------
cm3
Sounds like extensions that delegate text fields to native editors should be
easier to write with better ability to expose a localhost http endpoint.

------
cm3
How similar is this to Opera 12's built-in httpd?

~~~
onion2k
Or Chrome's built-in webserver - [https://github.com/GoogleChrome/chrome-app-
samples/tree/mast...](https://github.com/GoogleChrome/chrome-app-
samples/tree/master/samples/webserver)

~~~
kzahel
That app can't serve a local directory. It has to make a copy to a sandbox
filesystem first. Try this app instead: [https://github.com/kzahel/web-server-
chrome](https://github.com/kzahel/web-server-chrome)
([https://chrome.google.com/webstore/detail/web-server-for-
chr...](https://chrome.google.com/webstore/detail/web-server-for-
chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb))

------
ilaksh
This is awesome but if Chrome and Firefox both supported UDP then we could
build things like this in userland. Is that happening?

------
chris_wot
Ok, this is cool and I think finally Mozilla have hit on something innovative.
I'm going to check this out soon.

------
anysz
"Hello Flyweb"? smh blasphemous hubris

