Hacker News new | past | comments | ask | show | jobs | submit login
FlyWeb – An API for web pages to host local web servers (flyweb.github.io)
312 points by collinmanderson on Nov 5, 2016 | hide | past | web | favorite | 69 comments

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.

"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.

Of course there are AirDrop clones. 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

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

>It's crazy to me that there AFIAK aren't AirDrop clones. Little know, but there is! Snapdrop[1] does this via WebRTC. Pretty nifty, but I've rarely ever seen it mentioned or used. Solves the XKCD problem, at least for intranet stuff.

[1] https://snapdrop.net + https://github.com/RobinLinus/snapdrop

I'm curious how you would use this. What files would you share and with who?

I'm so used to sharing via cloud services and chat apps that I really don't know who or what I'd use this with. Just curious what situations this would come in handy for you.

How about a video of my kids with my Mum who has come to visit?

Uploading and downloading the file to a cloud service will take a while. Many will reencode the video and loose quality. I then have to communicate a URL, rather than have my mum just look in a flyweb (or airdrop or whatever) place on her machine.

The issue with file transfer in particular is that it is often asynchronous: you send a file from your phone, and then, you might go for lunch - outside of the LAN - or they might be off that day. You end up needing a human protocol: ask the receiver if they're ready, send it, wait for the upload. It is almost simpler to use a USB key, and certainly simpler to rely on a Dropbox-like.

I read flyweb as being part of Mozilla's IoT effort, to make it easy to convert your phone into a remote control. See for instance this video they made: https://www.youtube.com/watch?v=FJ5DEGvqDb4

Well, with some laptop lacking USB-A ports I can see FlyWeb to be more practical for simple, quick and occasional file transfers. Also, most people have cheap, very-slow USB flash drives, so transfering via the network (even wireless) could be faster for larger files.

Another thing to consider if you compare it with cloud solutions is that you don't have to find a second channel to send the shared link (which may require both person to e.g. login on their webmail, spell their email address to one another, etc).

Also, Dropbox can sync over LAN https://www.dropbox.com/en/help/137

That doesn't mean much to me:

> Dropbox needs to maintain a connection to the Internet in order to determine when to sync. To take advantage of LAN sync, all computers need to be connected to a LAN and the Internet at the same time.

Stuff like syncthing/btsync is much more radical in that you don't have to assume that the internet as we know it even exists.

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.

> 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.

I agree when it comes to Apple, disagree when it comes to Google. The Chromium project has been heavily pushing industry standards for web apps, service workers, home screen installation, etc etc. IMO they're doing just about everything they can to promote the open web as a viable app platform.

As far as I know, the Chromium project has been pretty good about pushing open standards. I reckon that's because the company divisions operate as silos.

And this doesn't need to contradict pushing their proprietary app platforms. An addition to Google Drive that allows people to send files over the office intranet without going through the internet (i.e. faster and more securely) would give Google a small competitive advantage over the Microsoft suite of tools.

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.

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).

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.

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.

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

It mentions that it relies on mDNS (Multicast DNS) which is link-local (for the most part).

It might be nice if it could be configured to also leverage a DHT like the Bittorrent DHT such as Webtorrent uses, but that may be out of scope. (From what I guess, restricting it to link-local may possibly be an intended restriction for now.)

Hosting HTTP from JS is nice (and potentially quite useful in p2p/mesh/offline-first worlds), but the real proposed benefit here would be adding a first class mDNS UX to the web browser. Right now anybody can host a web server and mDNS advertise on a local network, but there's no cross-platform, cross-browser way for me to tell you how to pull up that mDNS advertised web server. On some systems, some of the time, in some of the browsers you can use mdns-name.local and access that server. But a lot of system/browser combo don't support that (or worse, don't support that reliably). (Not to mention the questions of how to access mDNS advertised names that don't meet URL standards such as are full of : and space and Unicode characters.) If FlyWeb could help get something of a standardized web browser interface into mDNS, that alone would be a whole lot of good for the intranet/link-local/IoT web.

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.

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.

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.

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.

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://) 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.

I'm obviously reminded of http://www.operasoftware.com/press/releases/general/opera-un.... 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

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.


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 :)

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


Thanks for this! How do I install it?

Instructions would be useful... https://github.com/johnhenry/flyweb-browser-chrome/tree/patc.... Hopefully the developer accepts the pull request.

Merged :)

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.

“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

Would like to see this fleshed out some more. ]

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

Meshnetwork torrent trackers with DHT anyone?

I was thinking IPFS

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.

The only drawback to Bluetooth is range. In my house it's effectively limited to one partial intervening wall - anything more and the signal fades fast.

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?").

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.

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/

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

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

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

"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.

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...

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.

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?

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.

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

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,


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

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?

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?

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.

Examples of useful reasons to use?

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

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?

Ehh... web pages in browsers always had the ability to make requests. Now they also can accept requests like a server. There are security concerns here, sure, but I really don't think DDoS is one of them.

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.

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

> 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.

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

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

Yeah this reminded me of Opera Unite as well. It's not that similar really though. As I understand it:

Opera Unite was an isolated platform with prebuilt apps by Opera and custom apps you could download from an app store. FlyWeb is an API exposed to any web page.

Opera Unite gave you a public URL that was an Opera server reverse proxying to your local machine so you could share files, chat, etc. with your friends online. FlyWeb just publishes multicast DNS (Bonjour/Avahi/Zeroconf/etc.) service discovery records to your local network.

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://chrome.google.com/webstore/detail/web-server-for-chr...)

Chrome Apps are being killed on everywhere but Chrome OS though, so you won't be able to do this in a few years.

I had not heard Opera has httpd built-in, so it depends: what does Opera's httpd do?

Opera 12 had, which doesn't really exist anymore. It's Blink based now and I don't recall the feature being restored (yet).


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

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

"Hello Flyweb"? smh blasphemous hubris

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact