
FlyWeb – Pure Web Cross-Device Interaction - siavosh
https://hacks.mozilla.org/2016/09/flyweb-pure-web-cross-device-interaction/
======
digi_owl
Could make IoT make sense after all, if each device come with their own
switches across an open protocol rather than rely on proprietary apps.

~~~
BHSPitMonkey
Isn't that basically what X10 and ZigBee have been for years?

~~~
fabrice_d
The ability to interact with the device directly from your web browser (no app
install needed!) is a big step ahead.

~~~
chatmasta
Isn't that already possible? If a device has a local IP that exposes an API,
then your web browser can talk to it via JavaScript.

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

~~~
7952
Surely TLS solves that?

------
luney
This is a cool idea. I'd love to see it easy to create apps that can
communicate using something like this and/or Bluetooth mesh networks

~~~
Natanael_L
It could be advertised via Google's Nearby Bluetooth API

~~~
rektide
Nasty, ugly, closed.

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.

~~~
srikz
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

------
williamle8300
This is nice, but let's not get our hopes up. It could have the same fate as
Mozilla's Persona that was released couple years ago.

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

------
BHSPitMonkey
How is this different than just an ordinary old http service advertised on
mDNS? Is it just the idea of listing nearby ones in a browser's UI?

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

------
jsprogrammer
I wonder why this doesn't use WebRTC (at least it wasn't mentioned)?

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

------
giosch
This is the next step after cordova-like development tools to create
networking crossplatform web app. I like it. My only concern is about security

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

------
egfx
This is a repackaged idea that has many incarnations including one I built.
People have been thinking about this sort of thing for years.

~~~
egfx
It's true

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

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

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

