Mozilla's Connected Devices Innovation Process: Four Projects Move Forward

https://blog.mozilla.org/futurereleases/2016/03/01/update-on-connected-devices/

by cpeterso • 10 years ago

83 52 10 years ago

blog.mozilla.org

kibwen3• 10 years ago

I'm excited to see Mozilla's experiments in the IoT space, but I'm a bit unclear on the exact nature of the projects being undertaken here. For example, is the software here intended to act as a proxy between connected devices and your access point, possibly via flashing your router?

I'm also curious if Mozilla is building in automatic updates in all of this software from the ground-up, seeing as how that appears to be the fundamental weakness of everything related to the IoT.

mparlane• 10 years ago

Project Link appears to be designed to run on a raspberry pi and uses rust.

Yoric6• 10 years ago

Note that we are still at a very early stage of exploration, so anything I write might change a dozen times before there is a first official prototype.

The current prototypes of Project Link are developed in Rust and tested on a RPi. However, we have not decided of a specific hardware platform and there are even chances that this will remain cross-platform – I'm currently running prototypes on my laptop.

In the current state of things, yes, the software is designed to act as a proxy between connected devices and connected devices and your access point.

I can't speak for other projects, but we definitely intend to have an update mechanism. This is very much not finalized yet, so any suggestion you have (currently, as a detailed blog post – once we are better organized, as a RFC) would be useful.

davidascher2• 10 years ago

Good questions. At this point, we're trying to identify user value with prototypes. We're a long way away from defining things like the software update model on as-yet-unspecified devices.

Animats3• 10 years ago

Huh? They just dropped Firefox OS and Persona, their authentication system, and now they want to get into the "Internet of Things"? It would have made more sense if they'd used their authentication technology to allow devices to link up in a mutually mistrustful way.

davidascher2• 10 years ago

Sounds interesting. Do you have any references for approaches and possible benefits that we could look at?

garretraziel• 10 years ago

I think that security will be very discussed thing once IoT will be more spread. I also think that Mozilla could be first to solve it and Persona could help with it. I imagine using it for authentication of connected devices in my home.

Animats3• 10 years ago

A basic problem with the "internet of things" is who gets to talk to whom. How do devices get introduced to each other?

Living units need an identity. Devices introduced into the living units need to be introduced to that identity to pair with it. Phone-based programs may also need to be paired with the living unit identity. Each pair needs a set of security restrictions.

You want to set this up so that the homeowner can look at the house webcams, but nobody else, including the webcam manufacturer, can. A unified identity and permission system, perhaps built on Persona, lets you set up such connections without every phone having to be paired with every device. Also, with a unified permission system, you can revoke permissions. You might permit a guest access to the house systems but remove that access when they leave, for example.

kibwen3• 10 years ago

This is mistaken. Firefox OS wasn't dropped, it was pivoted from phones to connected devices: https://blog.mozilla.org/blog/2015/12/09/firefox-os-pivot-to...

I've also seen rumors that Mozilla is working on a successor to Persona, but absolutely no substantive evidence as of yet.

Techonomicon• 10 years ago

No. The team was repurposed, not really Firefox OS though. Have got some insider knowledge on this one.

I mean come on. Firefox OS on embedded devices, the thing could barely run on cheap smartphones.

tangue• 10 years ago

Sounds strange to hear about Mozilla with language generally used for talking about Yahoo...

Yoric6• 10 years ago

I like the sound of that. Do you think you could come up with a blog post detailing what you have in mind? If so, this would clearly be something to discuss in Project Link (I'm one of the devs).

IshKebab• 10 years ago

A smart home powered by Mozilla would be open and accessible to everyone - financially, technically, and creatively. No one else can do all of these.

I think it is a mistake for Mozilla to try this. Firstly, someone else can already do that - IoTivity. AllJoyn have recently abandoned their efforts and joined IoTivity too, so it is really the only open IoT protocol in town. That is a good thing - adding another competitor is just going to make people wait (again) until it is clear who is going to win.

Secondly, consumers don't really care that much about openness, and Google and Apple have a huge advantage in this space due to being able to build support into their mobile OSes. It's not just a matter of bundling a default app either - they can do things like access your wifi passwords for provisining. I don't think Apple will do that will with HomeKit, as long as it is iOS-only, but Weave is cross-platform, sort-of-open, fairly complete and seems pretty well designed.

Finally...

A few small players are beginning to enter this gap, though their proposals are still not complete enough to solve the problems we've identified

Yes that's putting it mildly. AllJoyn never supported out-of-the-home control, and IoTivity is very much a work in progress. But I think Mozilla are hugely underestimating the amount of work involved. And given how much work is involved, why not join forces with IoTivity?

detaro• 10 years ago

I just looked at the IoTivity website, but it looks awfully "enterprise-y"/"design-by-committee". Are you involved with it and can report otherwise? Any "real-world" examples?

coldtea2• 10 years ago

Facepalm. Another doomed attempt from Mozilla, when they should be focused on getting their core competitive advantage, their browser, much better faster...

Edit: (One could argue that those are different teams. But even if so, those failed attempts, and there have been enough already, dilute their brand and send the wrong message. Besides, why spend money on such a project when you can give it to the browser team instead? Now, Rust et co I understand, because it might provide the future of the browser engine with Servo, being secure, parallel, etc. Asm.js and other browser related initiatives are fine too).

bobajeff2• 10 years ago

Competitive advantage? I think you mean core competency.

Being a browser maker isn't really an advantage unless you leverage that in some other business like a website, web development solutions or (with enough market share) locking people into your ecosystem.

The real competitive advantage goes to Google. They control the most popular search engine and mobile platform. They can make or break just about any app or website. Their browser just fortifies their dominance.

coldtea2• 10 years ago

Competitive advantage? I think you mean core competency.

Yeah, the latter.

That said, they should work on their competitive advantage too -- the fact that they are open source and pro-web which matters to a lot of users.

pette• 10 years ago

Project Link: What's that? And what problem does it solve? No one will understand, no one will use.

Project Sensor Web: Yeah, let's add another solution to this problem that has been solved ten times over. w(

Project Smart Home: Also crowdsourced? After Mozillas previous handling of hardware (like ffos dev-phones that were deprecated in record speed) i can only say: Dont.

Project Vasomething: ANOTHER IoT framework that is used and needed by no one?

We are about 2 years past peak Mozilla.

hotcool• 10 years ago

I recently uninstalled Firefox browser on Windows because it loads at least 10x slower than Chrome, even with no plugins. Mozilla should fix that first. It'd give users (like me) more confidence in other projects they do, like connected devices.

nshm• 10 years ago

I participated in Gnome and Linux kernel development in 2002-2008, that was an amazing time. Those days open source systems were successfully competing with commercial software, Firefox was on edge, Linux desktop was really promising, Linux kernel was widely used everywhere. Drivers for various devices were created by hackers. I left once I saw that corporations are taking over. Redhat and Novel decisions started to set the direction, I felt I can not contribute anything.

Mozilla foundation attitude has been changed since then, it is simply a corporation, not an open source community, I really doubt it will come up with something significant.

Just few days ago I spent half of the day cleaning bloatware from an Acer desktop, Sony Tablet and a Samsung phone, this is really crazy how every small company wants to catch you with a push button daemon that will in parallel store all information about you and sell it later. We desperately need some alternative - an open source phone at least where you can control all the components. However, I see that things like voice input or good navigation would be very hard to create for the open source community.

notalaser2• 10 years ago

I left once I saw that corporations are taking over. Redhat and Novel decisions started to set the direction, I felt I can not contribute anything.

I sought refuge in BSD land as a consequence of this. I got sick of the whole drama around Gnome, systemd and everything else precluding me from properly using my computer. Everything is perpetually half-broken, bug reports and user demands are ignored if they don't fit their world domination agenda and so on.

I still develop for Linux because they pay me to do it at $work, but it's increasingly unpleasant. Things are still fairly sane in the kernel (barring the occasional rushed device drivers or the whole ARM clusterfuck, but there are limits to how much that can be helped). Userland, on the other hand, is full of 0pointer-branded narcissism and nearly unworkable for anything that has to run for more than three months without constant attention. Great for devops, brain aneurysm-inducing for anything else.

pdkl952• 10 years ago

0pointer-branded narcissism

It is possible to avoid that crap. Older - and much saner - software still works. Just ignore the "desktops" and run the specific tools you need in a saner windowmanager of your choice.

# e16 - from my cold, dead hands

pjmlp• 10 years ago

The interesting, or sad thing, is that many of us that had already commercial experience saw this coming and always stated that in the eventuality of GNU/Linux becoming successful it would be bend by corporations like any other OS that went big.

But, as usual, youngsters stated we were just naysayers.

And now GNU/Linux distributions are basically a 2nd coming of UNIX wars.

a_imho• 10 years ago

this is really crazy how every small company wants to catch you with a push button daemon that will in parallel store all information about you and sell it later

plug created the service ( https://anonimho.com/privacy.html ) as a statement against this practice exactly

Matthias2474• 10 years ago

I really wonder what should be the difference between those Link and Smart Home projects and something like OpenHAB, besides that is newly started by Mozilla. I think the current adaption of DIY or build-something-through existing frameworks shows that most people don't really care about such solutions, they want something that works out of the box - even if all parts come from a single manufacturer.

From an engineering perspective implementing lots of proprietary protocols in a single gateway device is lots of work and will never work 100% fine. Most people that worked on such solutions will confirm you that, and I can also do that (in a somewhat different domain). You can sink lots of money is these projects, and they still might not work for some customers at all - just like universal remotes - only more complex.

One way forward could be pushing the creation of devices (gateways, sensors, actors) that are based solely on standardized and accessible protocols. I'm not the biggest fan of CoAP (because I think it's hardly possible to implement it correctly), but I would still prefer this to reimplementing Z-Wave or Hue protocols. HTTP/2 could also be a good fit. But even if you have at least the protocol layer standardized, there possibilities for API design are endless. Standardizing IoT APIs throughout the whole stack in a backwards compatible fashion could really be something worthwhile, but the effort will be big, and it's questionable if other parties are actually interested in standardization.

And just a side node: I don't think Rust is the best choice for building a prototype for a mostly event based system. EventLoop semantics are hard to implement because of ownership/borrowing issues, the necessary dependencies (websocket libraries, etc.) are all in their in infancy, and it might also not be something that allows to move as much forward in speed as you want for a prototype (where you as a tradeoff can live with lower performance). Yes - I'm sure the Rust commmunity will disagree with me on the last point ;)

Manishearth2• 10 years ago

I would disagree with you on the first point more; Rust is actually perfect for event loop based semantics (we use this in Servo, it's very clean). Ownership fits perfectly with message passing.

You should avoid sharing state when you're using a message passing-based system. The cross-thread communication is handled by the messaging, sharing the messages itself just muddles things further. So the borrow checker disallowing that isn't a bad thing.

the necessary dependencies (websocket libraries, etc.)

I agree; though the websocket library Servo uses is pretty good (still, not battle-tested, so it's a very valid point).

it might also not be something that allows to move as much forward in speed as you want for a prototype

Again, with the prototyping thing, sure, it's harder to prototype in Rust, but that's not the whole story -- you spend less time writing tests and debugging.

(Also, I'm not sure how much harder it is; I've never had trouble with doing it and before Rust I was mostly programming in Python/JS)

Yes - I'm sure the Rust commmunity will disagree with me on the last point

Which sort of indicates that it's probably inaccurate? :)

A lot of the perceived problems with Rust (e.g. fighting the borrow checker) go away after a month or two of actively using the language.

Matthias2474• 10 years ago

Just for the reference: I'm building similar systems professionally (and have done that with most mainstream programming languages on the market), and I was probably the first one who explored async IO and eventloops in Rust (https://github.com/Matthias247/revbio - but I'm not really proud of it) - so I think I'm at least halfway qualified to talk about this.

And unfortunatly by experimenting with these things I really got the fealing that these problems don't expose the best side of Rust. Wrapping lots of types into stuff like Rc<RefCell<T>> wasn't the greatest experience, and the problem that this didn't work with trait objects back then did not increase that either (might have changed).

Message passing is a low level primitive, and it's probably a decent solution for communication between threads. However there is also a need asynchronous communication inside a thread (the eventloop thing), for which they are not really useful. Futures/Promises/Observables are great for both use cases (and imho even greater in a singlethreaded environment). These are definitly harder to implement in Rust - and if you don't believe me just check out how many good implementations are currently available in Rust vs. other languages.

How does the eventloop design in Servo look like? Wasn't that some integration with Spidermonkey?

I agree that in Rust you will spend less time on writing tests and debugging - but this applies also for a lot of other statically typed languages which bring in a better ecosystem for that task.

azdle• 10 years ago

[...]I'm not the biggest fan of CoAP (because I think it's hardly possible to implement it correctly)[...]

Out of curiosity, do you have any more details on what you think is impossible to implement correctly?

I've been doing a lot with CoAP and I'd agree that the RFC isn't as clear as it could be about some behavior, but I haven't come across anything that I'd say is impossible to implement or implement correctly.

Matthias2474• 10 years ago

I thought the base protocol was quite OK, but the complexity arrives as soon as you try to integrate blockwise access and notifications. From my look on it there are quite a lot of possibilites for race conditions there (e.g. bigger data chunks changing while transfers to clients are in progress) for which you might need to implement additional functionality (e.g. making copies of that data). But then you also need to exactly track how many clients are subscribed to that data und how long you need to keep that it (you want timers, and probably more timers than in any other protocol).

I don't recall the exact thing, but there was also something that I didn't like about the message IDs which you somehow need to keep ordered and check which ID might be used at the current point of time by which peer. A correct implementation may not send something while no ID is available, but to track all of those you needed lots of memory (much more than TCP buffers), and the open source implementations I looked at all elided that detail.

Yoric6• 10 years ago

I really wonder what should be the difference between those Link and Smart Home projects and something like OpenHAB, besides that is newly started by Mozilla. I think the current adaption of DIY or build-something-through existing frameworks shows that most people don't really care about such solutions, they want something that works out of the box - even if all parts come from a single manufacturer.

Very good question. There is definitely a large intersection between OpenHAB and Project Link. Both projects share one of their objectives: letting DIY users rig together and script their devices. However, beyond this point, our objective with Project Link diverge. We aim to explore ways to put the user in control of their data, including anonymity, authentication, storage, cloud access, web access, and certainly many others that we have yet to discover. It is our impression that OpenHAB's current architecture doesn't match our experimentation objectives.

A second difference is, of course, the architecture. We use Rust, betting that it will let us execute Project Link on devices with little memory, with no supervision, and with very long uptime. In particular, in the case of memory usage, while there are no decisions on this, there are projects that could help us run Rust and Project Link on almost bare metal, should we decide to head in this direction. We felt that OpenHAB's architecture was not adapted to such explorations.

I think the current adaption of DIY or build-something-through existing frameworks shows that most people don't really care about such solutions, they want something that works out of the box - even if all parts come from a single manufacturer.

We are also exploring out-of-the-box, with other projects. I'm not involved, though, so there isn't much I could say on that topic.

[...]

One way forward could be pushing the creation of devices (gateways, sensors, actors) that are based solely on standardized and accessible protocols.

Yes, we would very much like to do that. But before we can do that, we first need to be actors on the field, with well-used projects and a large community.

[...]

Yes - I'm sure the Rust commmunity will disagree with me on the last point ;)

Well, it works nicely so far :)

Perceptes• 10 years ago

It's hard not to feel angry about this. Not only do I not personally want the things described in this post, I want them specifically not to make things like this. Until we have more fundamentally secure systems and laws that actually punish negligent companies for gross violations of security and privacy, IoT is not a domain to promote. There are so many other important issues with the web and the Internet right now that Mozilla could help with. This is such a waste of time and resources. Is there really some target audience that wants this stuff?

Yoric6• 10 years ago

For the moment, it looks like IoT is happening, whether you want it or not. I live far, far away from the Silicon Valley and last week, when visiting the supermarket, I realized that they are already selling IoT-enabled devices.

So the question is now: how do you want your IoT? A number of companies have already answered: silos, low quality, little-to-no hackability, little-to-no privacy. Mozilla wants the IoT to go in the right direction: open standards, open source, high quality, and the user in control.

Caveat: I'm part of Mozilla's Project Link. And I'm having fun coding it :)

kefka3• 10 years ago

Why are they working on mostly useless ventures?

How about some really captivating features like:

    Tor integration/awareness
    I2P integration/awareness
    ZeroNet functionality
    IPFS functionality

Start working on hard features that will make the internet better, and also more distributed. It's one thing to have throw-away garbage that nobody will use. It's another thing entirely to support new protocols that make Firefox a go-to tool.

fabrice_d• 10 years ago

There is one MoCo employee helping with getting changes from the Tor browser upstreamed. It's not happening overnight, but progress is being made.

Things like IPFS, while very promising, are not mature enough to justify the effort of adding them in the core of gecko yet.

Also, I dispute the fact that supporting IPFS would "make Firefox a go-to tool" in the grand scheme of internet users, unfortunately.

kefka3• 10 years ago

I sure hope so, regarding Tor and Mozilla. Aside my scripts that make .onion resolution on a Linux machine work, it would be nicer to have a simple and clean interface here.

I certainly understand the hesitancy with IPFS. It is still too new. And they're still ironing out features and implementations. However, what gets me is that it's live right now, and I'm using it for quite a few things.

Right now, I'm getting some VM stuff up and running. My idea is that jor1k linux in JS can be run on IPFS.. Still playing around with it, but it seems very stable and fast.

Also, regarding your 3rd point: I've attributed many network effects to the 85/15 principle. The 15% is your tech userbase. They're the ones that drag everyone else into a platform or technology. The rest (85%) follow because the early adopters knew that it was where to go. Gmail was like this, as was Facebook, as was Firefox, as was Napster, etc. Adding in something like IPFS as a base support adds in "Cloud Storage" where nothing really existed like this before, well, aside 'cloud' meaning other peoples' servers.

Maybe I'm completely wrong. Time will certainly tell, but one thing I know, is that I am indeed impressed with what I'm seeing already.

Yoric6• 10 years ago

Out of curiosity, how would you integrate this in a web browser?

Also, in my experience, Servo is a very good platform for experimental features such as these, so if you feel that they will make the Internet better, you should consider contributing them to Servo.

kefka3• 10 years ago

Some of those are honestly pie in the sky, I'll admit. But still seeing a statement that's where resources would be being spent would be ideal for some of those.

With regards to Tor/I2P, It would go a long way to be able to understand that a .onion or .i2p link was clicked and to use an alternate resolver. That would also call for a mode in the browser that sanitizes all user fields and makes the browsers look all exactly the same (to maintain anonymity).

For IPFS, I'd like to see a client-side javascript that handles the peer processing of a node, as well as being able to understand a /ip[n/f]s/hash is an ipfs link. So far, we have resolution via localhost:8080 or ipfs.io/ipfs/hash resolution depending if you're running the peer program or not.

I know that IPFS is actively working on a websockets/client side js for their system, so that any browser can play along, with no noisome downloads or binaries.

And honestly, I didn't know about Servo. I've already enough on my plate, that I didn't need to know about yet another awesome project :)

shmerl2• 10 years ago

What happened to Shumway by the way? A few bugs I filed for it are now marked as referencing "Mozilla graveyard" product. It doesn't sound encouraging...

ygjb-dupe2• 10 years ago

http://www.ghacks.net/2016/02/23/flash-replacement-shumway-i...

shmerl2• 10 years ago

Thanks, that's what I've suspected.

Yoric6• 10 years ago

Killed by patents.

Mozilla's Connected Devices Innovation Process: Four Projects Move Forward

Related Stories