"This approach is also error prone. If you later happen to access some other service with the same private IP, on some other local network (for example, 192.168.1.1:80), that service can steal the cookies stored by the first service. The services have to be careful about using caching because you might get the cached page for the first service when you visit the second service."
Prefer: normative, specified, open. Gimme Physical Web, please. Which has a mdns protocol- it's kind of funky tbh, but at least your not enjoindering yourself and your users into a silo.
The lucrative thing about Google Nearby is that it works across iOS and Android and since it has an option to fallback using sound (ultrasound?) it can work on any device which has a speaker and mic[1]. Are there any open solutions which lets me simply pass messages between 2 devices without any sort of configuration? BT LE is ruled out (for now) because I can't rule out pre-Lollipop devices[2]. I wish there was a more universal and open protocol which was fast, reliable and worked on most mobile devices to simply exchange small packets of data.
[1]: Of course it doesn't have support for Windows 10 Mobile, but not due to practical limitations.
[2]: BT LE in 4.3,4.4 has lot of issues and limitations
Edit: added caveat about not supporting Windows 10 Mobile
Hi, the blog post author here. This is an experimental project, with all the caveats that go along with it.
It could definitely have the same fate as Persona. In fact, we face a bigger set of challenges than Persona - we need to not just figure out adoption curves, but standardization, nailing down the security story more firmly, and driving cross-browser and cross-platform support. Each of these on their own is a significant challenge.
But I would hope that some people get their hopes up. Sometimes it's worth it to get your hopes up even though you have no guarantee that it'll work out in the end. You can get your hopes up and still be pragmatic and grounded in reality.
I think the novelty is in putting all these things together with a tractable user experience: one person loads the game in a web page, and then everyone else sees the game listed in their browser and joins it.
WebRTC is not a bad technology for this project. The answer to this question is: little bits of different reasons.
1. We don't have a ton of resources (as in people working on it), so we have to be laser focused on making the implementation as simple as possible, to prove out the initial "v0" set of use cases. Straightforward client/server HTTP is the simplest possible thing. A couple dozen lines of node.js or python code are all that is necessary to throw up a FlyWeb server on a smart device. WebRTC support is way more complex, and less accessible to developers due to that complexity.
2. WebRTC is peer to peer, but it's also implicitly "cloud". One of our goals is to focus on approaches that are purely local. This is my personal opinion, but the minute that smart devices are somehow addressable from 'the internet', they become way more creepy - the surface area they expose to billions of people makes them troubling. Limited local-network (and eventually network-less local-area) HTTP is implicitly not "visible" to the entire world, which is a nice property.
3. Fundamentally, the "core strength" we're trying to leverage here is that the web platform lets you easily and securely "stream" applications between computers. That's what you do when you go to gmail or facebook or whatever - servers on the internet incrementally stream an application to you that's encoded in terms of HTML/JS/CSS/etc. WebRTC is a message-passing technology, which is not quite the core fit we're going for. Web and HTTP are the core of the app-streaming concept, so we're building on that.
Security is definitely something that needs to be thought about, and thought about carefully.
Mozilla's security team is already aware of the project and have done some initial analysis of potential approaches to securing/encrypting FlyWeb. There are multiple issues to work through - and we (the FlyWeb team) will definitely need to satisfy the concerns of the security team at some point soon.
Our collaboration with the security team hasn't begun in earnest yet - mostly because we've been too busy with everything else (basic design, implementation, proof-of-concept demos). For the next couple months, we're just field-testing the basic architecture and trying to get tinkerers and early adopters to play with it. We want to confirm our personal intuition that the architecture and design has legs, and that it lets people build worthwhile solutions that would otherwise have been hard to do.
This is a security nightmare. You now have an application -- a web browser -- that can be turned into a server by any malicious person with even a modicum of skill. It means that any other part of the payload no longer has to worry about setting up services, etc to covertly communicate back to the main site, that's all handled by the browser, which now has all the proxy settings and all of the keys to do so like any other traffic. This is just a terrible idea for very marginal benefit.
Are you familiar with www.peer-server.com? Creating a server in the browser can be done by any browser with WebRTC. FlyWeb merely adds service discovery on a LAN.
If you're worried about security, you should be running NoScript.
WebRTC is also a misfeature in my opinion. Service discovery makes the misfeature even worse by announcing it to the local world, making it easier for malicious software to use an unsuspecting user's browser as a proxy. Yes, noscript would help my personal box, but it wouldn't preclude Joe from Accounting from opening that "neat game" they got an email about.
The server is only visible in the local network, for the duration of the session, and subject to the browser sandbox. For any kind of malware, phoning home is hardly a problem, what advantage do you think this gives them?
Depends. Let's say, for example, you find a hole in a corporate webapp, say a wordpress application. You want to get usernames and passwords, but said app is firewalled off and you don't want to rouse suspicions. So, you send an email to Joe over in accounting, with a link to a game of some sort that asks to start a webserver. Now, FlyWeb makes its presence known via mdns, and the compromised server now has Joe's IP address. The server can now use Joe as the patsy/proxy, and your code can potentially stay on the server just a bit longer.
Yes, it's a bit convoluted, but it's the first sort of attack that came to mind. An open web server, even if local, can cause a good number of problems, especially if it's running untrusted content.
Flyweb would be unnecessary in a situation where you have access to a web app server and a user's machine. You could just modify the code on the server to make Joe's machine post data to the outside when Joe visits the web app.
FlyWeb does present a new attack surface, so it needs thought, but the blog post makes it abundantly clear that Mozilla know that.
