Hacker News Reader

Comment by Amadou | Hacker News Reader

I don't see mention either way of subscription/cloud requirements. If it isn't fully self-contained, then the risks out-weigh the benefits.

Edit: Drilling down to the ninja blocks pages I see mention of a "ninja cloud account" as being required to install drivers. That sort of unnecessary external dependency is a deal-breaker for me, essentially negating the entire value proposition of open-source.

http://ninjablocks.com/blogs/how-to/9555237-installing-drive...

View on HN

Agreed. I was, for instance, very excited about the new nest smart-smoke-alarms and just stopped reading and went away when I saw the first mention of my "nest cloud account" or "nest login" or whatever it was...

Thank god Sonos came out back in 2005 (or so) and was built without all of this nonsense - no doubt if it was released today there would be a mySonos web login account cloud identity blah blah blah...

Mandatory cloud connectivity is detrimental to the usability and security of an automation system. I, for one, will never add non-optional cloud features to my own automation products.

Some day I want to see more systems with a decentralized architecture, where cloud servers, if used at all, only help facilitate a secure VPN connection between the user's device (e.g. a phone) and the user's home network.

The code on the device will be open source. If you wrote something that made it easier to use when the internet was down (or you weren't connected at all) and sent a pull-request you'd have a good shot of it being accepted. When the backend is released as O/S too there will no doubt be some effort towards getting it running on the device itself.

I'm working with others on a FOSS toolstack that makes it easier to build decentralised systems. Take a look and let me know what you think. http://nymote.org/

All I get is a spinning blue dot. Your site is unfriendly to people who take their security seriously. That's not a good sign.

Thanks for the feedback. I don't understand your second comment though, how is it 'unfriendly to people who take their security seriously'? You can email me instead, if you prefer.

I'm guessing it doesn't work if you have javascript turned off, due to the unnecessary "splash screen".

It does look like you're addressing the right problems with "Signpost" and "Irminsule". Am currently reading your slides.

Pjc50 is correct. Practically every browser exploit over the last decade has had javascript as an essential component. Forcing users to enable javascript to use a site is a bad idea because it makes them more vulnerable. Javascript should be a last resort to provide necessary functionality that is impossible to do in any other way. If you want to use javascript for frills, that's fine as long as the frills don't become obstacles if javascript is disabled.

To put it into perspective, NoScript is the 4th most popular add-on to firefox.

https://addons.mozilla.org/en-US/firefox/extensions/?sort=us...

Software like what you are developing needs to be designed with a strong security mindset from the beginning. It is a truism in the industry that security tacked on after the fact never works very well. I was extrapolating from the security naivete of your website design to the likely naivete of your software design.

Thanks, this is a helpful explanation. The site came from a template and I didn't think too long about the issue you mention (but I agree it's important [1]).

Regarding your final para, please be assured that the folks working on the software are 'best-in-class' and do have a strong security mindset as well as a deep background in internet systems. The software is the output of research work being done in the University of Cambridge and I made the site to try and showcase the work and provide more context around it. The front-end of the site may be lacking but that shouldn't reflect on the software we're making (though I do understand why people extrapolate).

[1] https://github.com/nymote/nymote.github.io/issues/10

WFM

I agree. Why not open-source the other software parts under some fairly protective license like AGPL for the server and Artistic License v2 for the client interface to the AGPL-ed server. These licenses adequately protect you from a commercial entity coming and stealing the mass market business opportunity or the community, while still making it possible to support individual hackers like Amadou that can contribute a lot, but won't unless it is open source end to end.

I don't wish to give the impression that hacking on the hardware is my goal. I could, but I'd rather not. The reason external dependencies are a problem for me is that they take away my ability to control my system. If I have to hack together something to use it without the servers, then that's a marginal improvement over having to reverse engineer the protocol on the wire, but it's still really customer unfriendly.

Anyone who buys this system and makes it central to their home's operation (as intended) becomes exceptionally vulnerable to the decisions of the people who control the servers. Even if the developers' interests always align with my interests, I'm still vulnerable if their system gets hacked, if they go bankrupt (and shut down) or if they are acquired by a company with a different management perspective.

It would be like buying a car that has to check in with Lexus every time I want to start the engine.

It would be like buying a car that has to check in with [ed: GM] every time I want to start the engine.

Isn't that called OnStar?

Risk of what?

You can also just SSH in and 'git pull' a driver if you prefer =)

Reply on news.ycombinator.com