More awful IoT stuff - <AUTHOR> http://mjg59.dreamwidth.org/43486.html <comment><USER2> I just blogged about this yesterday. In short:

> The line in the sand for me is: network vs cloud-based systems. I _want_ > things to be network connected, but I want it for my own network only. I > want to be able to control my coffee pot, but only from home. If I _choose_ > to expose this over the internet, great! It's up to me to make sure it's > secure. I don't want anyone making that decision for me.

I also want it to be upgradeable, and hackable. I'm willing to pay a lot of money for standalone quality devices, but nobody is supplying!

<comment><USER3> Would you feel comfortable with end-to-end encryption via an open, documented, free protocol? This is literally my raison d'être as a company, so I'd be interested to hear your comfort level.

What I've got is a platform that 1.) makes it substantially easier for IoT developers to get their devices to market and 2.} enforces end-to-end encryption and affirmative consensual sharing. It works by running as a background service on both the IoT device and on any connecting computers. In a similar vein to IPFS, the service magically switches between local and nonlocal networks dynamically, so it doesn't matter if your interent connection goes out; as long as you have power (and a local server set up, but I'd like to add P2P capability over LAN in the near future) you're good to go.

I realize this isn't the whole device you want, but is that a starting point you'd be interested in?

<comment><USER4> I've been debating about hooking my garage door opener up using a built-in feature so I could open the door from my iPhone. I don't trust that whatever central site I'll be connected to is safe. If I _knew_ the vendor had implemented your protocol/software well, and I _knew_ your software was safe, yeah, I'd use it. But I don't know those two things, so no way am I hooking my home's door up to the Internet...

<comment><USER3> In my case you actually do know that the vendor is using the protocol. You would have to be running the protocol on (in this example) your iPhone in order to talk to it. Everything is client-side verified and enforced by encryption.

You wouldn't have any guarantee that the garage door opener isn't also running a separate web connection in the background, but arguably unless you're actively monitoring your LAN (or just plain radio) traffic you don't have that anyways.

Put a different way, you can't prevent your manufacturer from, for example, adding a SIM card and wireless connection to your garage door opener. At some point you have to trust them.

<comment><USER4> When you say I'd have to be running the protocol, wouldn't I really be running their garage door opener app? In other words, how do I know your protocol is being used?

<comment><USER3> If they were using the protocol, they have two options:

1\. Roll their own implementation (highly discouraged). Increase their development burden. Introduce higher maintenance burden. Slightly more flexibility for app deployment. And run the risk of my company disallowing interoperable embedded commercial implementations out of security concerns for the users. Basically, at this point the company is better off not using the protocol.

2\. Use our implementation (Hypergolix). Massively decrease development and maintenance burden. They now have an install dependency, though, so distribution is a bit more complicated. Significant reduction in time and money invested in the app.

The critical point is this: with option 1, you're correct in that you don't know the protocol is in use, but it's extremely likely that they wouldn't be using it here, nor advertise that they were. With option two, you know that they are using it, because _you have to manually install the application to run the protocol._

<comment><USER4> With #2 do I know they are using your additional install? Would your app indicate their app was a registered client and was sending commands through it?

<comment><USER3> It certainly could, as it has full knowledge of what's connected. That's quite a ways down the road though; for now we're focusing on Razpi <-> computer. Mobile deployment is much more complicated (also a much larger market though).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> So there is a great amount of lists, blogposts and information about awful/bad IoT things, but if someone like me want to have a list about IoT things that are actually secure and well-working, where would I find that?

<comment><USER6> It's not that easy. I stick with brands/products that are reviewed by people I trust or have seemed to pick up some momentum.

My general rule of thumb is I NEVER buy anything IoT that is WiFi based. Zigbee or Z-Wave based devices will save you a lot of security nightmares (though definitely not all).

<comment><USER7> Why is Z* preferable to Wifi-based?

<comment><USER8> One of the reasons would be that it isn't used that often and won't allow access to your network with commodity hardware.

<comment><USER9> Isn't this idea hiding the problem though? While using uncommon hardware and protocols may thwart certain users, it's really not solving the problem of security. It's somewhat similar to the idea of using a hidden wireless network and calling that security instead of securing your network with WPA2, etc.

As these devices become more popular, we'll start seeing more Zigbees and Z-wave devices become commodity hardware.

<comment><USER10> Not at all, anyone can "join" the network, but nobody can decrypt the traffic without the key.

Zigbee has built-in, easy, encryption. You simply set your router to allow unsecured joins temporarily whenever you get a new device, which then learns the key.

When the network is set to allow only secure joins only devices pre-configured with the key can see anything other than encrypted frames.

</comment></comment></comment></comment></comment></comment><comment><USER11> >It's running Linux and includes Busybox and dnsmasq, so plenty of GPLed code. I emailed the manufacturer asking for a copy and got told that they wouldn't give it to me, which is unsurprising but still disappointing.

Has the GPL really lost it's power that much? I mean not responding to inquiries is one thing, but outright saying no?

<comment><USER12> Lost its power? This is just copyright apathy. Nothing new, especially in China. Look at it from the manufacturer's point of view. They know how expensive this would be to take to China and prosecute and they know they're a tiny fish. It's simply a reasoned gamble that saying no is the fastest, most efficient way to get this dealt with. Much easier than auditing the code, having the developer separate out sensitive data, etc. Well before you consider the long term archiving of this stuff. They're probably already making the next generation of this rubbish.

I dare say if this were a major manufacturer, more effort would be made to make them behave, but we're talking about a short-run switch here.

If there ever becomes a mechanism to DMCA-takedown physical products on an international level, we might see some movement here. But China (et al) would never, ever agree to that. It's hard enough to get them to block things that clearly break international safety standards.

<comment><USER13> This makes me wonder how imports are handled. If I can buy a third party power supply from a US based order system (amazon), and this ps is dangerous (eg. those knock off Apple power supplies). How is this legal, presumably the device hasn't passed safety regulations here. So, there must be some way to stop this product from entering the country. Why isn't that mechanism happening?

Same applies for this device. If a mfg is infringing on copyright then shouldn't we have a mechanism to stop it from being imported?

It strikes me that we have two laws in this country. The laws for those with money/power (e.g. MPAA to protect US corporate media interests), and then those same laws that are not applied to protect consumers. Is the only difference that MPAA has lawyers to ensure copyright infringement stops while consumers don't?

<comment><USER14> I cannot speak to copyright, but there seem to be mechanisms in place for stopping import of trademark infringing goods to the US. See for example the run-in which SparkFun had with importing lookalike Fluke Multimeters a few years ago: [https://www.sparkfun.com/news/1428](https://www.sparkfun.com/news/1428) and previous HN discussion here: [https://news.ycombinator.com/item?id=7428799](https://news.ycombinator.com/item?id=7428799)

This might actually do more to confirm than dispute your comment about "laws for those with money/power", though.

</comment></comment></comment></comment><comment><USER15> > Eventually I plugged my phone into my laptop and ran adb logcat, and the > Android debug logs told me that the app was trying to modify a network that > it hadn't created. Apparently this isn't permitted as of Android 6, but the > app was handling this denial by just trying again. I deleted the network > from the system settings, restarted the app, and this time the app created > the network record and could modify it. It still didn't work, but that's > because it let me give it a 5GHz network and it only has a 2.4GHz radio, so > one reset later and I finally had it online.

Madness. And people wonder why there's so much skepticism about IoT being adopted by non-techies.

<comment><USER16> As a counter example, my brother who never uses a computer setup his chromecast in 5 minutes with zero help from me. I know b/c he called me and asked for help. I told him he wouldn't need it, but he didn't believe me.

Things are getting better. There will always be more crap out there than good stuff. That's why walmart is so popular, but things will generally improve.

<comment><USER17> I don't consider Chromecast as being part of IoT. Chromecast is mostly used as an internet media device, whereas I usually interpret IoT as slapping Internet capabilities on traditional appliances (light bulbs, fridges, whatever). Curious what other people think.

<comment><USER18> Chromecast _is_ slapping Internet capabilities on a traditional appliance (TV).

<comment><USER17> Only in as much as it lets you access content streams on the Internet. It doesn't let you control your TV via the cloud or anything. In terms of functionality I think it's pretty comparable to any other content stream you can hook up to your TV, going back to Ataris and VCRs.

</comment></comment></comment></comment></comment><comment><USER19> @internetofshit is a great follow and pretty quickly illustrates just how absurd the IoT rush has become. Solutions in search of problems.

<comment><USER20> > Solutions in search of problems.

Solutions in search of money before the market wises up to how crap these products are.

<comment><USER21> a bit off topic. Why can't somebody sell a reasonably priced Thunderbolt 3 eGPU enclosure. Oh right intel's certification process takes several months... All in the name of quality assurance yet most thunderbolt 3 products feel subpar considering their price.

</comment></comment></comment><comment><USER22> There's so much potential in the market for proper, well made IoT devices that would bring around the hardcore skeptics like myself. I mean really well made products, properly encrypted with well made API endpoints that come with good apps for the uninitiated -AND- the ability to be scripted and automated by the techies. (You can do both, there's no reason why you can't and I don't understand why everyone refuses to). Oh, and not having them phone home to who-knows-where-istan around Australia, or at the very least, having the ability to TURN THAT OFF.

Seriously why have NO companies come forward with products like this. I'd buy a house worth if someone did.

<comment><USER23> The commercial side of building automation is robust, but the components are pricey, the platforms proprietary* and end-user aavailibility seems to be limited. The beauty of the _other side_ is every switch, sensor & controller's first objective is _not_ to monetize the user but rather to simply do it's intended job. Look into building automation controls and you will find what you yearn for; Siemens, Johnson Controls, Honeywell/Novar, BAS... However, retail/public access, setup & end-user friendliness will still be significant hurdles outside of hiring a pricey, authorized contractor.

*The components are simple & generic, the interface & controls are mostly based on a universal framework w/ their proprietary gui/front-end locked on.

<comment><USER22> That's what I'm getting at though, there is clearly a market for consumer ready devices that don't cost what solutions like that do and don't need a contractor to install them. I mean you can't tell me that in today's world we couldn't manufacture an outlet with electronic control of the flow of current out of it's outlets, and do it in such a way that uses proper SSL and endpoints, without having to price it so high? I don't believe it.

<comment><USER23> I totally agree, the demand & the means exist. However, the intent of retail providers is _anything but_ enabling simple, automated controls. Everything is about grabbing the data cash bag and, as an afterthought, let's _personalize_ your experience. I have been pondering this and the only conclusion I can come up with is the market controllers(more than mere "forces") have much to gain by selling the perception instead of reality and their treasure troves of patents(from commercial side) allow them to maintain this position. IMO, the digital revolution of ours has transformed sharing into one way collecting and the consumers into commodities. Both of which I find quite offensive, and sometimes, outright hostile. Alas, our money is our only true vote. Vote accordingly.

<comment><USER22> I suppose but it still seems like a copout (not on you of course, on them) to play the brand lock-in game. You don't need a centralized server to personalize and operating those servers, even on something like AWS, costs money. Why not put that on the consumer instead? Many consumers I know would prefer the roll-your-own solution and it saves the manufacturer money.

<comment><USER23> Thanks for your manners, but it is probably a copout on my part. I have the wherewithal(-money) to build something like this in my own home but I believe most of these controls are over-engineered progress for progress' sake... for anything less than a few thousand square foot structures. All I really need is a programmable thermostat, a couple timer plugs & my 'routine'. As always, YMMV.

As for the providers, I have to admit, a service economy cannot sustain itself using only transactional relations. In order to ensure future revenues, a contracted service agreement &/or proprietary walled garden approach is the only sustainable model they have come up with. I am a 'break-fix' geezer stuck in my ways and don't subject my clients to lock-in, but my widely varying income from month to month can make affording life difficult at times.

edit: + _& /or proprietary walled garden approach_

<comment><USER22> But this is assuming that I expect something beyond the transaction. I don't. I expressly DON'T want a continuing relationship where Nest decides my perfectly functional thermostat no longer works or that Phillips decides their controller is only going to work with Phillips light bulbs.

I want them to sell me the product and then politely f*ck off so it keeps working. :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> I'd like regulation agencies to mandate, as a condition of market entry, for each and every electronic product:

1) Full firmware source code and required toolchains/sign keys/... be submitted to the national libraries, to be kept for secure archival until the device is officially unsupported by the manufacturer.

2) For networked products, the full source code must be either published, or licensed institutes must perform a security check.

3) There must be provisions in place to ensure timely reactions in case of security issues. If the manufacturer does not respond to security issues, national libraries have the right to release the source code.

4) Required tools, service manuals, datasheets etc. must be submitted to the national libraries.

This should basically kill off GPL-abusing companies, as well as ensure serviceability, even for discarded products.

<comment><USER25> Interestingly, Underwriters Laboratory is starting to get into this game:

[http://www.ul.com/cybersecurity/](http://www.ul.com/cybersecurity/)

How good or useful this will be I don't know. But clearly they see this as an area where people will be looking for some expert help; not everyone has the skill of a Linux kernel hacker to check these things for themselves.

</comment></comment><comment><USER26> The principal reason devices need to be connected is so that business can hold your devices ransom and charge you money to use them.

Turn on lights with a phone? No need for Internet.

Open doors with a fingerprint? No need for Internet.

An auto-adjusting energy-saving thermostat? No need for Internet.

A fridge that knows the milk is low? No need for Internet.

Charge people money to use their toaster? You need the Internet for that.

<comment><USER27> Completely agree except the light argument -- having my lights cloud connected allows me to control them remotely. The main use for this is for time or sunrise/sunset scheduling. However you could quite easily architecture this without cloud connectivity, it seems easiest to keep the bulb dumb and keep the 'smarts' elsewhere (whether that's on a phone locally or a server in the cloud).

<comment><USER28> Scheduling isn't stock market, you don't need a live feed for that. All such a bulb needs is an accurate date and time source - the rest, including (if you also add one-time geographical area input) the sunrise/sunset times can be determined with a little bit of trivial math on the uC that said "smart" bulb already has.

All that IoT stuff doesn't need Internet access. Hell, most of it doesn't need much of a network at all, but just having them default to _intranet_ would deliver all the value without the problems (and the rent-seeking).

</comment></comment></comment><comment><USER29> IoT devices can be fine, but there are lots of companies involved in it that don't know what they're doing and would be better off staying out of the market. I always advice friends / family to look for upgrading capabilities, ability to do useful work when not connected to the Internet proper, user control (do you _own_ this device or effectively borrow it per licensing etc.?), and other similar things before purchasing any IoT device. Some IoT devices are great, but some are abysmal.

<comment><USER11> And it sounds like this one was like 80% of the way there. I mean they used encryption (badly, but they still used it), had a way to update the software on the device (even if only over http), and uses passwords (although doesn't enforce them).

<comment><USER30> So everything it does, it does badly? To me, that's not 80% of the way there, that's more like -80%.

<comment><USER11> Come on, the last thing he reviewed sent everything in plaintext, had no root password, called out to multiple chinese servers, ran ssh via a hardcoded password that was something like a simple word, and didn't have any way of actually updating the code on the device. Oh, and it barely even functioned as a lightbulb...

This is lightyears better than that, and yeah they fucked up a bunch of stuff, but it at least shows they tried. Even shitty AES is going to increase security over plaintext...

<comment><USER31> Agreed. It may not be technically good, but it's as good as the door locks that hundreds of millions of people rely on to protect their homes every day. Most home doors/deadbolts are easily pickable with a few weeks' practice.

It keeps honest people honest.

<comment><USER11> I somewhat agree. Since it's only a plug, if the worst that a hacker can do is turn your plug on and off, it's not the end of the world.

But if there is a vulnerability that lets someone use this plug to pivot an attack on the rest of your machines in your network, now it's a big fuckin deal.

</comment></comment></comment></comment></comment></comment><comment><USER32> I also mentioned this in a recent blog post: [https://www.jsondata.io/blog/2016/iot-needs-a- cloud/](https://www.jsondata.io/blog/2016/iot-needs-a-cloud/)

> Right now, the cloud - especially for IoT - isn't a healthy ecosystem. Your > shiny new smart thermostat might as well be dialing into AOL on a dedicated > landline. And unlike public services, these proprietary service providers > lack long-term guarantees of service availability.

> What we need is a push for openness and interoperability in the cloud, and > that will only happen if consumers demand it. The service providers are > incentivized to do just the opposite.

<comment><USER33> >What we need is a push for openness and interoperability in the cloud

Personally I think that is the opposite of what we need. Most IoT devices should be local-network-only. So if by cloud you mean a personal cloud (local network or VPN), then yes, I agree. Otherwise keep the interwebs away from my thermostat.

<comment><USER32> That's a fair point, and I agree. However, the reality is that a major selling point for these things is along the lines of "control it from anywhere", and whether people actually need remote access or not, it seems that a lot of consumers still see it as a major upside.

Maybe what we really need are more consumer-friendly, self-hosted (and secure) home VPN options. That way you _can_ just run your services on the local network, and still have remote access without opening your devices to the world (or to other companies' servers). Until the average grandma can do that, the "personal cloud" idea will probably be overshadowed by manufacturers' desire to provide proprietary remote access options, because those go hand-in- hand with things like subscription pricing models, data mining, etc.

<comment><USER34> Or change the marketing from cloud connected to owning the cloud. I mean, for someone who would depend on stable Internet connection to be able to control all this shit, he'd be off hosting a personal cloud on the same connection as well. Even better, because if there are operations happening in a local network and WAN goes out, the devices will still operate inside the LAN.

</comment></comment></comment></comment><comment><USER35> _The short version: they introduced terrible vulnerabilities on your network, they violated the GPL and they were also just bad at being..._

 _Overall: the hardware seems fine, the software is shoddy and the security is terrible_

This article begins and ends with two great tl;dr for IoT. There is value in this. Just look at the prevailing cluelessness, and be much better than that to stand out from the pack. In fact, how about applying that formula to the next nascent big thing that comes along?

<comment><USER36> Perhaps because the large mass of consumers only care about the first point (how the hardware looks in their home)?

Point two comes in play only if the user experience is horrible, otherwise it's acceptable.

Regular consumers rarely think about point three.

<comment><USER35> I wasn't suggesting consumers think about these issues. I was suggesting that founders think about them!

<comment><USER28> There's that Upton Sinclair quote about understanding and salary...

The point being, the business model of IoT is literally lending you a device that due to purposefully shitty engineering is not useful if you're not paying the rent. I wish there'd be a founder that cares about making stuff that's primarily _delivering_ value to the customer, but in IoT space, I'm yet to hear about one.

</comment></comment></comment></comment><comment><USER37> Shameless plug to a 100% OSS IoT / home automation system I contribute to that agrees. Everything IoT should be fully open source and not rely on cloud connections:

[https://home-assistant.io/blog/2016/04/05/your-hub-should- be...](https://home-assistant.io/blog/2016/04/05/your-hub-should-be-local-and- open/)

</comment><comment><USER38> Sounds like there is a strong need for a standard OS build for IoT devices.

I'm not expert in the area, but I would imagine a standard API could be implemented to handle the vast majority of use cases. Connecting to an app securely, turning things on and off, basic scheduling.

<comment><USER39> I think openwrt on the main unit (a good router) + nodemcu based sensor units would work well.

Openwrt is powerful enough to take care of logging, connecting to the internet etc, and the sensor units can form a pseudo mesh using their wifi capabilities.

<comment><USER40> Ideally the base should be from a project that handles base system upgrades, so that consumers don't have to trust that the vendor is building security updates in a timely manner.

Last I checked, OpenWRT did not do security updates, and it's up to the user to recompile everything if they want newer versions.

</comment></comment></comment><comment><USER41> I feel that the people who are now talking about IoT are the same people who were totally into 'semantic web' back in the day. And it's pretty much the same kind of story: "Wouldn't it be neat if all these systems could interoperate?" and again the answer is "Yes, but not neat enough justify the cost and hassle of actually making it happen".

<comment><USER42> I think we're due for a proper realization of the semantic web in the next couple years. Things seem about at the point where the cost and hassle can be overcome without a significant financial motivation to do so.

Maybe in another decade or so IoT will make sense other than as something fun to experiment with.

</comment></comment><comment><USER43> The stuff from wirelesstags.net are generally very good. I have a bunch of sensors and their Reed sensors for detecting opening and closing of doors are very good. I hook it up with ifttt and turn on my Hue lights when I open and close my doors. Clearly not ground breaking stuff but useful.

The Hue lights are great but expensive. The Hue switch made things a lot more useful as well. I'm waiting for them to come out with a compatible light switch so I can control my recessed lights the same way as my light bulbs.

What they need to work on is a better outdoor camera with motion detection that doesn't get triggered by shadows or wind moving a tree branch. I've tried almost every solution and none is acceptable.

<comment><USER44> The wirelesstags.net stuff looks good, but it also is tied to their cloud services. I couldn't find a local API to talk to their bridge device.

The nice thing about Hue is that their bridge can run completely disconnected from the internet and still respond to RESTful API requests, which means that when Phillips end-of-lifes Hue my bridge will keep working with Home Assistant.

<comment><USER43> Yes that was a concern of mine as well. They stated that if they do go out of business they would open source everything so that we could build our own solution. That's basically what convinced me to go all in with their product.

</comment></comment></comment><comment><USER45> Does anyone still need convincing? Don't buy anything that connects to the Internet that isn't built and maintained by a major software company. Even then, be careful. Duh.

<comment><USER46> Not sure if software company helps. Nest has some issues.

</comment></comment><comment><USER47> IoT is all about unsecured devices generally?

<comment><USER48> That's been my understanding as well. The cpu's used typically aren't powerful enough to do anything other than simple encryption in a reasonable amount of time. Ssl is generally out of the question. Someone please educate me if that's incorrect.

<comment><USER49> As usual, "it depends".

If this thing is capable of running OpenWRT, it can run some sort of SSL for what it needs. Might be tight and might have to not be OpenSSL, but it can be done.

Lesser-capable devices may have issues. But note that one way or another, the devices _must_ speak some decent encryption to get on to WPA2 networks. Of course that's probably done in the Wifi hardware, but it still shows that it's not like we're living in the 1980s where we literally wouldn't have been able to afford the silicon in a consumer device. Hardware acceleration of SSL shouldn't be that hard to get a hold of, for instance: [https://en.wikipedia.org/wiki/SSL_acceleration#Central_proce...](https://en.wikipedia.org/wiki/SSL_acceleration#Central_processor_support)

<comment><USER50> But more to the point: there is no purpose to SSL/TLS on an appliance because it will not have a valid certificate, hence it won't protect anything. You might as well just use WPA2-PSK.

<comment><USER49> If you're using a custom client-side app to access the device, which many of these things seem to do, you can create a CA for the devices, put the public cert for the CA into the app, and issue each device an individual cert at the factory signed by that CA. Then the app can be reasonably secure and assured.

I say only "reasonably" because defending against the "I cracked into the device and stole its cert" is pretty hard, but I'd submit, also not all that realistic a threat in this case. I'm really looking to defend more against "I bashed together some encryption so crappy I can hack this by making you visit a hostile web page" than "I want to use this lightbulb without the NSA knowing". (On that note, an SSL cert only valid to a custom app that your browser won't accept isn't _all_ bad, it prevents that sort of thing.)

I mean, this it total pie-in-the-sky in terms of the ask I'm making here for security knowledge and willingness to do something correctly instead of bashing out some terrible, incorrect crypto with direct and incorrect use of the primitives. But it's _possible_.

Actually... I won't call myself an SSL expert per se, but one of the things that I find personally frustrating in dealing with some people is that once you do know what's going on, using SSL is often _much much_ simpler than bashing together your own crap crypto. Any sensible SSL library has places to stick the CA certs. Generating them isn't _that_ hard, more just tedious. Generating a big pile of certs at the factory and siging them isn't _that_ hard. Even if you're very sloppy with your SSL usage, where you don't do a great job of protecting your core cert, where you use the root of the CA instead of an intermediate so the private key of the root is "live" in the factory, you don't set up a good revocation solution and you just set the expiration as far into the future as you can, because you probably haven't got a mechanism for updating them... even if you make all those errors, it's _still_ better than just bashing crap crypto together, because it'll still resist more attacks than your crap crypto and it's not really all that hard.

But I have abundant experience that shows people would way rather futz around directly with RSA keys and HMAC and spend days and weeks scraping something together rather than even entertain the suggestion of doing it even _half_ correctly. I don't fully understand it. Do other people find futzing with crypto that fun? I play defense a lot in security, but I honestly find correct crypto a royal pain in the ass and do everything I can to outsource it via SSL (which may not be perfect but isn't necessarily _bad_ and has the advantage of being very defensible when people ask "what do you do to secure things") or NaCL or something. Is it just the psychological difficulty of admitting that you don't _really_ know what you're doing with this crypto stuff? I dunno.

<comment><USER50> Nobody's going to invest money into flashing each device with an individual cert just to protect against an attacker MITMing a home user's home wifi network to turn off a lamp. And you'd have to bundle your own whole TLS stack and browser with the app just to get the CA validated; that's a lot of extra software engineering.

If the user _really_ cares about security enough, they can buy their own real TLS cert and install the cert on the brick.

<comment><USER49> Ah, I meant to add to my list of bad practices sticking the same cert on every device. Sorry. To be clear, I'm saying you got me on that one. I missed that.

Of course, one person steals that cert and they've cracked the system wide open. But that's the default case for crap crypto anyhow, so what's the difference, except you spent about 10 minutes in the shell and passed some parameters to your library instead of spending.... well... _anything_ more than 10 minutes futzing around with AES and RSA and so on?

Also, while I understand your use of "nobody" in the slangy English sense rather than the strict mathematical sense, I would point out that as these devices get more sophisticated, eventually they tend towards a manufacturing process that _will_ do something to each one in the factory anyhow. For instance, if you're doing any sort of burn-in testing you've already done the vast bulk of the hard work it would take to also use that time to stick a cert on there. Yeah, your cheap knock-off Wifi light won't do that, but as the industry matures I think you'll see practices that would permit certs without much additional work.

</comment></comment></comment></comment></comment></comment></comment><comment><USER51> Alright so this is mostly OT, but I figured people who are into IoT might be able to help; does anyone know of a setup that would easily let me control a remote AC outlet by plugging a sensor into an existing hard-switched AC outlet? I'd rather not deal with installing a hub and programming scenes etc. Thanks!

</comment><comment><USER52> I enjoy reading this kind of article about lousy security, because I say to myself "Wow, that was lousy!" and laugh. BUT I still don't know how I could avoid this. I genuinely ask: could anyone share with me the "2016 Guide of the best pratices for securing an API/ a web app"?

<comment><USER53> TLS + Client Certs + EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH

<comment><USER54> You forgot to mention +[Vault|CFSSL|XYZ] for cert management.

<comment><USER53> I can find what CFSSL[1] and Vault[2] are, but not XYZ in this context.

Also, all of this can be done with plain openssl, there is no need for additional tools.

[1] [https://blog.cloudflare.com/introducing- cfssl/](https://blog.cloudflare.com/introducing-cfssl/) [2] [https://www.vaultproject.io/intro/](https://www.vaultproject.io/intro/)

</comment></comment></comment></comment><comment><USER55> Hold on - it sounds like this thing is running Android. Has reference to connecting with ADB, apks, and Android versions. But it's also running a SSH server and OpenWRT? What's going on there, is it running 2 different OSes for some reason, or did they somehow merge Android and OpenWRT?

<comment><USER56> The app is running Android, the device is OpenWRT as far as I understand.

</comment></comment><comment><USER57> I'm enthusiastically waiting for this: [https://espressif.com/en/products/hardware/esp32/overview](https://espressif.com/en/products/hardware/esp32/overview)

oh baby!

</comment><comment><USER6> Funny timing... I just bought an LG LFXS30776S refrigerator and the first thing I noticed was that all of a sudden I had a new WiFi broadcast. Turns out that according to tech support there's no way to shut this off.

<comment><USER58> Transceiver, meet grounded aluminum foil?

<comment><USER59> Has it come to the point where your refrigerator has to wear a tinfoil hat?

<comment><USER58> Yes.

</comment></comment></comment></comment><comment><USER60> There is definitely a lot of IoT stuff coming out that isn't great. However MFT companies like Aspera, Innorix, and Attachmate must be loving it~

</comment><comment><USER61> Sorry, but what does he mean by "infringing on my copyright"?

Is he the author of one of the libraries it uses?

<comment><USER62> Yes. He is a major contributor to the Linux kernel, and unless I remember incorrectly, he was almost single handedly responsible for getting UEFI support in Linux.

</comment></comment><comment><USER63> Just offload your entire IoT project to a big firm / provider instead of cherrypicking devices?

</comment><comment><USER50> Has anyone ever bought a consumer network appliance that didn't have shitty security?

<comment><USER64> Has a security engineer ever reviewed anything that had good security?

<comment><USER50> Yes, but mainly commercial stuff. It costs 3-10x what the consumer appliances cost but it's usually actually secure and stable. Aruba, Ruckus, Cisco, Meru, etc.</comment></comment></comment>


Ask HN: Why are Cryptoexchanges so easily hacked? - <AUTHOR> 2 exchanges in S. Korea in June alone. There are always exchanges getting hacked and coins stolen.
Is it a social networking thing?
Poor IT security?
Lack on knowledge on IT security?
An inside job? <comment><USER2> Some inside jobs but mostly they are the only ones worth hacking compared to some boring old architecture firm or something</comment>


Brain Aneurysm Treatment by Coil Embolization - <AUTHOR> http://www.brainaneurysm.com/aneurysm-treatment.html

<comment><AUTHOR> A friend of mine recently had this procedure. It's amazing to me that anyone would come up with the idea of a procedure like this and it's even more amazing that it routinely works.</comment>


What time does your company get to work? - <AUTHOR> Years ago, when I started at BigCorp, I reported to my new building at 8:00 sharp.  My boss didn't come in until 10:00, and it turns out that's the status quo there.  What is it for your company? <comment><USER2> Our company policy is quite standard for BigCorps in Sweden:

8-17, with 45 minutes of lunch. Flextime +-1 hour (i.e 7-16, 9-18).

We trade 15 min of lunch (60->45) during the year for only working 7 hrs during the summer, so 8-16 between June and August. Practically everyone is off in July so it is a good deal for the company strictly speaking but that one hour does make a bigger difference than I thought it would.

In my current project most get in between 7 and 8 but in other parts of the IT organization most get in closer to 9. Varies a bit and many have kids so they tend to arrive late or leave early.

</comment><comment><USER3> Our hours for developers are 10am to 4pm, which is because many of our customers are in China so people often have to work and attend calls later at night. So of course if you leave at 4 then it's expected that you're making up the extra time at home. Though a lot of people (particularly those with kids) make it in significantly earlier than 10.

</comment><comment><USER4> Our company policy is "in before standup at 11am", I usually roll in anytime between 9 and 10:30 depending on traffic

<comment><USER5> Similar here but 10am standup. 38hr week.

</comment></comment><comment><USER6> Some people get in early (7am), some people get in late (11-noon). People generally put in roughly the correct amount of hours, and it evens out - sometimes you do a short day, sometimes a long day. If you get done what you need to and it doesn't disrupt your clients, it's pretty flexible.

(big-4 consulting company)

<comment><USER7> Consulting folks also tend to work with customer's schedules (and the offshore team's hours). There can never be fixed hours for those guys.

</comment></comment><comment><USER8> Mid-size corp office in Sydney: the bulk come in around 9am. We're flexible as many people are working cross timezones and generally a progressive worker mentality.

My experience is big corps require you to be in earlier, but there are much less burning the midnight oil days.

</comment><comment><USER9> Whenever I wake up (usually before noon).

</comment><comment><USER10> 09:30 (standup) - 18:00, startup, berlin

</comment><comment><USER11> 10:00 to 18:00 startup london</comment>


The non-iPads - <AUTHOR> http://utestme.com/the-non-ipads/

<comment><USER2> This is really hard to follow. The overall structure of the post is just clunky. The grammar is also lacking (missing articles, non-sentences, incorrect comma usage, etc.) which really makes it difficult to follow.

<comment><AUTHOR> Good point; please let me know which are the grammar issues blocking the understanding of the post and I'd be happy to correct them</comment></comment>


A practical guide to securing macOS - <AUTHOR> https://github.com/drduh/macOS-Security-and-Privacy-Guide <comment><USER2> Previous discussion (111 days ago): [https://news.ycombinator.com/item?id=13023823](https://news.ycombinator.com/item?id=13023823)

</comment><comment><USER3> Hardly practical. Sad state of affairs when only those who can spend hours and hours protecting themselves can have any semblance of security.</comment>


AI for playing (and winning) in Dark Souls PvP - <AUTHOR> https://github.com/metal-crow/Dark-Souls-PvP-AI <comment><AUTHOR> A pastebinned version of WRITEUP.txt (for word-wrap): [http://pastebin.com/FnwmPYUD](http://pastebin.com/FnwmPYUD)</comment>


Time Line for Diaspora - <AUTHOR> http://chegra.posterous.com/time-line-for-diaspora

<comment><USER2> I bootstrapped my start-up using a three step process:

1) Spent less than I made at my "job" so I could save up a few months of a cash-buffer

2) Start my own simple business with a bulletproof business plan (ultra-low overhead, high-margin, self-reliant)

3) Save up enough money to throw in the hat with a strong group of like-minded self-starters who can afford not to get paid for a year and can build their own disco while covering hard costs

</comment><comment><USER3> Is there any _code_ in the commit history? Scaffolding, prototypes, anything?

<comment><USER4> So instead of build first, monetize later, they're going with monetize first, build later.

I'm still kind of curious what role this will play in the web. Will it be a real force, or simply a catalyst? What issues are they solving as the anti- facebook?

<comment><USER5> It's been done before. In the dotcom boom of the 90's.</comment></comment></comment>


Why the HTML5 'Video' Element Is Effectively Unusable - <AUTHOR> http://daringfireball.net/2009/12/html5_video_unusable

<comment><USER3> Another flaw in the spec is that it provides no means to specify client buffering behavior: you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems and basically only works properly at all if the users' connection is far higher than the bitrate of the video.

Until HTML5 has basic feature parity with Flash's video capabilities, it will probably not be used very widely. This is of course ignoring the fact that Firefox doesn't support a video format that anyone actually uses, and the fact that IE (still unfortunately the most popular browser) doesn't support anything at all.

The sad reality is that a single system often has the advantage over a group of conflicting, incompatible systems; even if the single system is bad, one at least only has to compensate for its weaknesses, and not for everything else's.

<comment><USER4> _you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems_

My understanding is that HTML5 browsers will attempt to buffer as much as possible; is there any reason you'd want _less_ buffering?

<comment><USER5> When you don't want the video to start, when you only want to buffer the minimum required for smooth playback, to avoid wasted bandwidth when the user inevitablly closes the window (see youtube, they do this now), a myriad of reasons. Flexability allows inovation.

<comment><USER6> Why does the browser itself not implement its own buffering algorithm? I do not quite understand why this onus should be placed on the developer responsible for the video imbedding functionality of the hosted datum. Certainly allow the external developer the flexibility to override this functionality (easily enough done via language features of JavaScript). But why force all developers to implement competing but similar algorithms? (by example and anecdotal personal observations: netflix > hulu > CBS/tv.com, in terms of how buffering algos deal with potentially high but intermittent bandwidth [1]).

If this were abstracted to the browser level (discounting the fact that these long-format providers will likely never move away from their current flash/silverlight implementations), my choice of online tv watching would no longer be dependant on the competence of the content-providers buffering algorithm: currently, despite the fact that I enjoy several shows provided by CBS.com, I will not watch them online due to their shoddy buffering algos. I will not watch them via antenna, either (I watch on my own schedule, thanks).

Of course, as stated, these providers are hopelessly locked to their delivery platform due to DRM and contractual obligations. Ergo, most of this point is moot when it comes to long-format TV-oriented content distribution.

[1] in my experience, CBS does not buffer enough before playing, and does not buffer during the pause state. It also does not indicate how 'full' the buffer is during pause state, like hulu does. Netflix is, in my opinion, the best on this as it indicates on the seekbar the buffer level, and adjusts bitrate based on perceived bandwidth. When your bandwidth drops below the perceived bandwidth, it gives you an accurate status indication as to buffering activity. CBS, contrarily, simply buffers to the original perceived value and resumes play. This is problematic if you begin with high bandwidth but midway through stream something happens to negatively effect your bandwidth. If this situation occurs, you're likely to encounter a slideshow: video resumes for 5< seconds, whereupon it buffers once more. This results in >2s stutters every 3-10 seconds. Because CBS does not buffer during pause states, this renders the video unwatchable except during time periods when my bandwidth is constant: living on a highly variable cable node makes this time period nigh impossible to predict. Therefore I do not watch CBS shows - antenna or streaming - at all.

</comment></comment></comment></comment><comment><USER7> This is a problem that I find to be systemic in the HTML specs. Even in a world where every browser was somehow 100% compliant with the spec (never going to happen), we web developers would _still_ be hitting our heads against the wall with browser inconsistencies because the spec chooses to make important behavior optional or subject to the browser-vendor's unique implementation.

Another example of this is HTML5 drag and drop, where things like what exactly _starts_ a drag is left completely up to the browser, resulting in major differences in behavior between browsers, to the point of almost being unusable.

</comment><comment><USER8> Its unusable because of auto-buffering? A simple onclick DOM replace will fix this (as the article mentions). I get that we want better tuning parameters, but really, the video tag is such an improvement over a flash player or embed tag that we're looking the gift horse in the mouth.

</comment><comment><USER9> That is a problem, but it seems like it would be very easy to move the image - click for video behavior into a pretty small JS library. Writing something like this probably wouldn't be all that terrible:

<script type="text/javascript"> $(function() { $('#video_1').to_video('myvideo.mp4', 'myvideo.ogg'); }); </script>

<img class="really_a_video" id="video_1" src="mythumb.jpg" />

I'd still rather do that than deal with Flash.

<comment><USER10> But see that's kinda stinky cos it's not semantic. You're not embedding the video element in the document so it can describe the content. It would be really cool if the js somehow could remove the video element or something and add it back in... but I dunno how possible that is.

<comment><USER11> The semantic part isn't even what really bothers me. I'm more concerned about requiring javascript for something that shouldn't need it.

<comment><USER12> Is it possible to start playback on the HTML5 video element without Javascript? I thought it was a requirement.

<comment><USER11> I just assumed... why would they do that?

</comment></comment></comment></comment></comment><comment><USER13> Slightly related: the HTML5 'Audio' element is also effectively unusable.

I was building choreographi.es (<http://choreographi.es>) a while back and was using the JPlayer plugin for JQuery, which attempts to use HTML5 audio and then falls back on Flash for platforms which don't support it.

The gist of my app was that I needed to match movements _exactly_ to specific offsets in the music. Between Safari and Firefox, Firefox was dead on, while Safari randomly appeared to skew as it started playing from different points in the music, just enough to be significant. I'd imagine it was some bug in counting sampling rate. In the end I had to crack open the JPlayer code and force Flash all the time.

TL;DR Moral of the story? It's hard to expect implementation to be perfect for a not-yet-finished standard, but until then, someone (you/me/us?) needs to make the equivalent of a community quirksmode combined with automatic bug submission to the relevant engine so we can get on with our lives.

</comment><comment><USER14> Unfortunately John is entirely wrong, about Firefox at least. Firefox does not buffer the entire media when autobuffer is not present. I don't know how he came to that conclusion, but just check out this page as an example:

<http://pearce.org.nz/video/bunny-poster.html>

Note that the progress bar on the controls does not turn to a lighter shade of gray until you press play - this means Firefox isn't buffering data unless you press play.

John's blog post is wrong.

<comment><USER15> You may be correct for Firefox but on the latest Chrome beta, my progress bar looks blue both before and after I press the play button - there is no indication to me as to whether it is buffering or waiting for input.

<comment><USER16> I'm on yesterday's Chromium build on a Mac, and here was my test. Go to the page, don't click, wait, wait some more, keep waiting, wait, some more wait. Then, try to drag the video to the half-way point and start play from there.

Result? The video jumps back to the beginning of the play cycle. Thus, I deduce, it ain't loading. Firefox 3.5 here, no autobuffer. Safari does as Gruber says and starts loading immediately.

</comment></comment></comment><comment><USER17> How does the title call out the video element as "effectively unusable" when in the end Gruber actually crafts a page that works with the video element?

Sure, no client respects the autobuffer attribute, and there's no way to use a poster image without resorting to javascript, _and_ you have to encode the video two different ways. But it still _works._ It works even if you stick to one format (you're just excluding clients) or don't play the javascript-dom- switchout game (the video autobuffers, you don't get a poster image at all).

Better title: HTML5 Video Element Has Glaring Issues, but Usable.

<comment><USER18> If you look up "effectively" in the dictionary, it means "in such a manner as to achieve a desired result". The author highlights the desired result of requiring the user to click on the poster before buffering is allowed to begin. He currently cannot achieve the result he desires. The title makes sense to me.

<comment><USER15> As a result of his rather drawn out explanation, however, it appears as though he _can_ achieve the result he desires, just not as simply as he would like and in a manner he'd rather make fun of than use. I understand complaining that about the lack of a feature that everyone seems to agree is decent and desirable, not to mention spelled out in the specification but it is not relevant to that specific discussion to complain that "you can't do X" when you can in fact do X.

<comment><USER18> I don't see anywhere in the article or in the title where he says that you can't do X. One needs to, again, sweep the author's qualifier "effectively" under the rug in order to construct that straw-man.

The title says that you can't _effectively_ do X using Y. I don't see how the fact that one can do X by instead using A and B in combination with Y invalidates that statement, especially with all the hype built up around Y as the savior of all from the evils of F.

It doesn't feel right to drop carefully-chosen words in order to wage a critique.

<comment><USER19> Sorry, I am not a native English speaker, but to me it seems the author claims that using Y, you _effectively_ can't do X. This, in contrast to your formulation, means that the effect of certain properties of Y is that X is impossible to achieve.

My interpretation agrees with the Webster's dictionary's (<http://www.merriam- webster.com/dictionary/EFFECTIVELY>) first definition of "effectively": "in effect : virtually <by withholding further funds they effectively killed the project>". (There are other ways of killing the project more effectively)

I agree with you in the sense that the author goes on rambling about how he is unable to achieve X as effectively ("in an effective manner <dealt with the problem effectively>") as he would like, but this is not the claim he has made in the title.

<comment><USER18> _This, in contrast to your formulation, means that the effect of certain properties of Y is that X is impossible to achieve._

I can see how it might appear that way, but take note of the word "virtually" in the Webster's definition. It's an unfortunate word, because it undermines the absolute strength of the word it modifies...which, in your case, would be the word "impossible" (had you not dropped the word "virtually" from your paraphrasing, that is).

Here's another example that shows someone else using the word in the same way that this author does. His system is copying files very slowly, and while technically his system is able to copy files, he feels it can't effectively be used for that purpose, even though a more patient person might disagree:

[http://www.vistax64.com/vista-performance- maintenance/120356...](http://www.vistax64.com/vista-performance- maintenance/120356-slow-file-transfer-effectively-cant-copy-move-files.html)

</comment></comment></comment></comment></comment></comment><comment><USER20> "As for why I refuse to embed Flash, let me put it this way. I use and highly recommend ClickToFlash, which blocks all Flash content by default. Why would I publish content using a technology that I personally block by default?"

Soon you will be blocking <audio> and <video> by default too, for the same reasons.

<comment><USER21> It's not the video and audio aspects of flash he is concerned about, it's the automatic loading and playing of content with flash that is annoying. Audio and video that doesn't load until you ask for it is perfectly acceptable.

<comment><USER22> The auto play isn't a requirement for using flash. What makes you think that the people doing auto loading and playing with flash won't do it with HTML5 tags? People can write annoying crap on any platform.

</comment></comment></comment><comment><USER23> The argument seems kind of silly. In 1993 when people started using images in their content, I'm sure people were making similar points. "My browser shouldn't download an image until I tell it to, it uses my bandwidth!" or "Don't download the image until I click it." And the web would be a different place if things were kept that way.

Now I'm not saying that the HTML5 video spec is perfect, but let me just provide a src and call it a day. Everything else should be out of my control.

<comment><USER24> You would change your mind in a hurry when your bandwidth bill comes in, or you run over your caps. That's basically what Gruber is saying: it's just not economically possible for people to embed video this way.

<comment><USER23> Right, but I'm sure that will change with time. The economic issue is a temporary problem that will go away, just as it did with images.

<comment><USER24> You're absolutely right. Temporary, but real pain right now. Unusable in today's economy.

</comment></comment></comment></comment><comment><USER25> The author demonstrated why Firefox, et al, made the correct choice on his example page. I visited his page using Firefox and the video would not play. My guess is that you need javascript turned on to play the videos on his site. I almost never enable javascript, and certainly would not do so just to watch a little video. It sounds like Firefox and others are trying to make the web pages more universally work.

<comment><USER26> I am sorry but that is insane. Today's web relies heavily on JavaScript. I recommend you get yourself a clean browser (maybe on a virtual machine), if you are paranoid about security (SecurityMatters huh?), and try using Google Maps, Google Calendar, et al.

<comment><USER27> Turning off Javascript is not insane. JS opens you up to a wide range of possible security problems. Also, you can think of it ideologically - <USER2> _should still work with JS turned off._ Building an accessible, semantic, well-formed website means building a website that works without Javascript.

The only exceptions are Google Maps or anything equally as rich. And I _do_ mean equally as rich.

<comment><USER28> You know, times has changed recently. Now we have not only web sites, but the web apps too. And there different rules apply.

<comment><USER27> Yes, and the vast majority of web apps boil down to forms with some flashy bits added. I'm not saying the flashy bits aren't nice, but you should build your forms in such a way that they still work without Javascript.

Like I said, Google Maps is my yardstick - anything less complicated than that should be built to work without Javascript. It might work slightly different and be a little less pretty, but there's no reason it can't work.

<comment><USER29> Google Maps is of course less interactive and shiny but still works fine without js. I'm dismayed that we don't routinely expect all web developers to be similarly talented and thorough.

[http://maps.google.com/maps?f=q&source=s_q&output=ht...](http://maps.google.com/maps?f=q&source=s_q&output=html&q=1+Infinite+Loop,+Cupertino,+Santa+Clara,+California+95014&ie=UTF8&hl=en&cd=1&geocode=Ff6gOQIde_W5-A&split=0&zoom=3)

<comment><USER26> Interestingly, a while ago I had an application where JavaScript was added later on in the game. The result was that we could split into two apps: a rich fast glitzy one and a basic one suitable for mobile devices.

<comment><USER27> That's one of the best arguments for accessibility (and the associated host of issues like semantic HTML and Javascript). Sometimes things you do in the name of accessibility will bring other benefits.

I read an interesting analogy in an article (which I have since lost and so cannot give credit) about accessibility: Oxo, the kitchen tools company, started by designing tools for people with arthritis. Having designed tools with nice soft rubber grips and large handles, they discovered that non- arthritic people really liked the tools as well, and now Oxo is sold at your local Target (and they are probably raking in cash).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> Just post a normal ass link to a regular video file. Let the user's file type preferences and video player take over. Do the same for PDFs and audio.

Why are people going through conniptions trying to get a markup reader to be a video player?

<comment><USER10> They're not going through conniptions. A markup reader already can display images with the <img> tag, and video is to the web what images were in 1995. However, the spec has an easy fallback - anything inside the video tag will be displayed on the older browsers. SO, as you said, that's where a link to download the video could be.

However, that's not what content producers want. They don't want you to be able to directly store the video on your machine, that's why they obscure it behind ridiculously obfuscated Flash players, making you go through all of these conniptions. That way you can't (easily) get it on your portable player or your home theater computer.</comment></comment>


Why I Walked Away from a $12M Acquisition Offer 18 Months After Our Launch - <AUTHOR> https://www.groovehq.com/blog/startup-acquisition-offer

<comment><USER2> [https://news.ycombinator.com/item?id=8601975](https://news.ycombinator.com/item?id=8601975)

</comment><comment><USER3> Feel free to correct my math here:

50% share of business after tax take: 6,000,000x0.7 = 4,200,000 Being extremely conservative and investing in LQD: 4,200,000x3.13%/12 ~ $11,000

Would you walk away from a check for $11,000/month forever?

<comment><USER4> > Would you walk away from a check for $11,000/month forever?

Nope, I wouldn't. Like he said in the article:

      First-time founders care most about their exit. Every time after that, you focus on legacy.

With cash problems forever off the table, it'd be much easier for me to start more businesses... :)

(Tellingly, author Alex Turnbull's _first_ business was also acquired, by Constant Contact.)

</comment></comment><comment><USER5> A bird in hand is worth two in the bush.</comment>


Redditor explains why Ayn Rand's ideas are wrong. - <AUTHOR> http://www.reddit.com/r/philosophy/comments/cvb8l/can_anyone_here_say_why_rands_ideas_are_wrong/c0vjnyt <comment><USER2> This is the standard critique. We all pick premises; we don't all admit it.</comment>


Transferwise $ billion fintech unicorn headline 2 months after teaser headline - <AUTHOR> http://bernardlunn.com/2015/01/27/transferwise-has-their-billion-fintech-unicorn-headline-two-months-after-the-teaser-headline/

<comment><USER2> The thing is i'm not sure that TransferWise are a 'Unicorn' yet. 'Close to $1B' is not '$1B'.

I know 'Close to $1B' is not as sexy as a mythical creature but if we're going to set these arbitrary classifications then let's at least stick to them.

<comment><USER2> I liked your analysis though.</comment></comment>


Whisk creates shopping lists based on recipes, lets you buy ingredients - <AUTHOR> http://thenextweb.com/apps/2013/01/09/whisk-creates-shopping-lists-based-on-recipes-and-lets-you-but-ingredients-directly-from-the-app/

<comment><USER2> The app is interesting, but this article misses the most unique and exiting feature of Whisk - they can add their widget to existing recipe websites [1] so you can order the ingredients straight from the page. It seems like an amazing idea, particularly once they get a few more recipe websites involved. [1] [http://www.foodnetwork.co.uk/recipes/milk-chocolate- tart.htm...](http://www.foodnetwork.co.uk/recipes/milk-chocolate-tart.html)

<comment><USER3> Thanks very much for the feedback Joshua!

</comment></comment><comment><USER4> Loving the application of Machine Learning to everyday aspects of life.

The last thing I found was Prismatic - finding interesting articles to read.

I'm a bit of a cheapo, and would love if the app could put together recipes based upon currents offers at supermarkets.

E.g. Tesco are doing half price mince, lets recommend bolognese.

Essentially a money saving approach to recipes, might allow for greater mass market adoption.

</comment><comment><USER5> Pretty cool, too bad the main feature (ordering ingredients automatically) is locked to the UK. I would love to just be able to export a list to Evernote or Google docs.

<comment><USER6> This. I use Evernote as my grocery shopping list; having recipes automagically populate my shopping list would be very nice indeed. As far as ordering ingredients automatically, I have to say I'm not to keen on that. I usually go to the store for other things as well.

</comment></comment><comment><USER7> Nice ad</comment>


Sex, Lies, And Quantum Computers - <AUTHOR> http://rjlipton.wordpress.com/2013/04/27/sex-lies-and-quantum-computers/ <comment><USER2> I can't comment on the theory side of quantum computation (BQP vs the classical equivalent BPP), but I would like to make an _engineering_ comment about why I think quantum computation will be _very_ difficult to scale, maybe even impossible.

To have good quantum registers (long memory time), you want each qubit to interact as little as possible with its environment. This means isolation (qubits far apart) or encoding the information in systems that interact weakly with each other.

However, to have good quantum computation (quick), you want strongly interacting qubits.

The two goals are diametrically opposite, so it's not clear how we can achieve both of them in a single system.

IMHO, the first interesting things that will come from quantum information science will be about quantum simulations of physical systems and quantum communication. Computation might come later... but I'm sure, by then, we'll have moved away from RSA and ElGamal.

<comment><USER3> It's a fair argument that the problem is unlikely to be solved because the solution wants to go in opposite directions (both weakly and strongly interacting). However, let me point out that there are many technologies that face strong tradeoffs and yet have been successful. Consider hard drive memory, for example. You want it to be easily switchable so that you can access bits quickly with little power. But you also want it to be hard to switch, so that it remembers your data for a long time. The engineering challenge is achieving both seemingly opposite goals at once. The success of memory technologies (among others) makes me optimistic that this is a solvable problem.

</comment></comment><comment><USER4> > _The obvious solution is to write down the initial vector of size N=2^50 and > start applying the quantum gates to the vector. […] The size is "just" a > petabyte—or actually 1 /8 of a petabyte._

Um, NO. A quantum system is described by the _complex probability_ of being in any of those states. You need more like 2^57 bits to represent that. 16 petabytes.

Source: I've written a 24-qubit quantum simulator.

<comment><USER5> IIRC the models of computation with pure states and mixed states are equivalent in power and efficiency (perhaps up to a polynomial blowup). In fact, you don't even need complex numbers. This is probably Lipton's mindset, seeing as he's a theorist.

<comment><USER4> No, I'm referring to pure states (vector of complex probabilities), not mixed states (matrix of complex probabilities). The latter would need 2^107 bits.

Every useful quantum algorithm manipulates the complex probabilities of the system. You cannot observe these in a true quantum system but you must still track them in a classical simulation.

<comment><USER5> So you're saying it's because each probability is a 7-bit number? I guess that's a valid issue, but it's still very "well, actually." So to counter with my own "well actually," you don't need _complex_ probabilities, and the computation only matters with probability bounded away from 1/2\. Surely you could do enough engineering tricks to make that happen and keep it at about a petabyte.

<comment><USER4> No, it's because each probability is a _128-bit_ number (2^7 = 128; really two 64-bit numbers).

Yes, you very much DO need complex probabilities. The ability to phase-shift qubits is key to most basic quantum algorithms.

I'm not sure what you mean by "the computation only matters with probability bounded away from 1/2".

Almost by definition, the most "interesting" quantum algorithms are those which are most difficult to simulate classically. e.g. you can use "tricks" to greatly speed up simulation if your states are separable, but then you're not really harnessing the full power of the quantum model. The most powerful quantum algorithms entail maximum entanglement and worst-case simulation performance.

<comment><USER5> Now I think you don't understand quantum computing as well as you claim. The standard model of quantum computing uses complex numbers, but it is well known that you can do everything with just real numbers instead. See exercise 10.4-10.5 of Arora-Barak [1]. The key insight in quantum computing is not that complex numbers are required, but that the invariant across computation is the 2-norm of a vector (as opposed to the 1-norm, as in the classic stochastic model of randomized computation).

Further, the standard quantum model of computation is probabilistic in the sense that you "compute" something if your program outputs the right answer with probability at least 2/3\. But 2/3 is not special, you just need it to be some probability bounded away from 1/2, in the sense that it can't get closer and closer to 1/2 as the input size grows.

So it's certainly plausible that you could take advantage of this to reduce the precision enough to get to the size bound Lipton mentioned, especially if, as implied, you had the might of a hundred Google engineers working on it. And the guy is so freaking smart and experienced in theoretical computer science that chances are he thought of all this and considered it not interesting enough to spell out for the people who will say "well actually."

[1]: [http://www.cs.princeton.edu/theory/complexity/](http://www.cs.princeton.edu/theory/complexity/)

</comment></comment></comment></comment></comment></comment><comment><USER6> >Quantum Computers have been proved to be more powerful than classical. _wrong_.

I take issue with that claim.

Take for example, the Deutsch-Jozsa problem. Given some function f, on n bits to one bit, such that f is either {zero on all the possible inputs, or one on all inputs}, or f is zero on half the inputs and one on the other half. To tell which of those cases it is, it requires 2^(n-1) + 1 tests of f. You have to test it on half the inputs, plus one.

With the added power of a quantum computer, we can solve it with only one call to f.

Boom, there is exponential speedup with quantum computing. This is similar to what lies behind Shor's algorithm for factoring.

Check it out, wikipedia has diagrams that I can't put in here.

[http://en.wikipedia.org/wiki/Deutsch%E2%80%93Jozsa_algorithm](http://en.wikipedia.org/wiki/Deutsch%E2%80%93Jozsa_algorithm)

EDIT: It seems he addresses this exact problem here [http://rjlipton.wordpress.com/2011/10/26/quantum- chocolate-b...](http://rjlipton.wordpress.com/2011/10/26/quantum-chocolate- boxes/)

I apologize, I was a bit hasty to call him out, he does know what he is talking about.

<comment><USER7> Isn't "quantum computers are proven to be more powerful than classical" proof that BQP != P, which would imply P != PSPACE, which hasn't yet been proven?

<comment><USER8> Not quite. Suppose there is some problem, whose best classical algorithm C, and whose best quantum algorithm is Q, with Q in o(c) [0]. Given that this relationship cannot exist in reverse (that is, quantum computers are at least as powerful as classical ones), this would mean that quantum computers are more powerful.

The statement BQP!=P means that there exists a problem that a quantum computer can solve in polynomial time, but a classical computer cannot. This is a stronger requirement.

For example, consider Shoore's algorithm, which can search an unsorted list in O(sqrt(n)) time, strictly better than the O(n) time it takes a classical algorithm.

[0] Note that the little-o means strictly less, whereas big-O means less than or equal to.

<comment><USER5> > Note that the little-o means strictly less, whereas big-O means less than or > equal to.

Aaahhh! Please don't say that when you're clarifying a technical point about theory!

Besides, it's explicitly stated in that article that "more powerful" is to be interpreted as P != BQP.

</comment></comment></comment></comment><comment><USER9> Interesting title. It is wordplay on the old movie title "Sex, Lies, and Videotape", where 'videotape' gets changed to the topic under discussion.

Of those three, " videotape " is the only one that is obsolete, while the others are timeless. While the original phrase goes increasingly obscure, the wordplay remains fresh because the obsolete part is invisible.

</comment><comment><USER10> > "With all due apologies to Soderbergh his title seems perfect for our > discussion. There may be no sex, but there is plenty of sizzle surrounding > quantum computation."

Right, the title "sex, lies and videotape" is perfect for the discussion. There's no sex, and there are no videotapes, but there are quantum computers, and the author's desperate attempt to cram some whimsy into his post.

I'll sum up the problem as I see it. The problem is that we're comparing real (and thus limited by the reality of manufacturing etc.) classical computers, with theoretically perfect quantum computers.

Well the idea of something is always better, faster and sexier (see, I worked back sex into this) than reality, because as we get closer and closer to building computers with a larger qubit number we'll start hitting all sorts of engineering issues that would distance us from that perfect theoretical ideal of a 100% efficient quantum computer.

And it may turn out that idealism is all the advantage quantum computers had in the first place. It was all for naught. Not that we'll stop trying of course.</comment>


Ask HN: What's The Best Alternative To Google Apps? - <AUTHOR>

What's the best alternative to Google Apps for small businesses? I love gmail, but I'm not keen on creating another G+ account & I'd rather have something that weans me off the Google ecosystem as I'm relatively annoyed at having to opt into all of their services if I just want to use one.
I get that they want us to use everything, but sometimes I just want email. What's the best alternative out there? I figure you guys have some solid opinions. <comment><USER2> Outlook.com allows you to use your own domain (free) and supports IMAP [https://news.ycombinator.com/item?id=6375844](https://news.ycombinator.com/item?id=6375844)

</comment><comment><USER3> You can try Zoho's suite of products ([https://www.zoho.com/business- apps.html](https://www.zoho.com/business-apps.html))

<comment><USER4> I like Zoho's email, and to be completely honest, I just have it setup so that it forwards to my own gmail account (their UI is way better IMHO), so that I still don't have to use the Zoho email unless I need to reply.

</comment></comment><comment><USER5> Outlook.com if you're small, otherwise Office 365. Depending on your needs, some subscriptions even come with Office licenses for Mac and Windows.</comment>


The Definitive Ionic Starter Guide - <AUTHOR> https://www.airpair.com/ionic-framework/posts/the-definitive-ionic-starter-guide

<comment><USER2> I've been looking at Ionic for a while but needed to get rolling with it. This book helped me get up and running quickly and is a great way to get into Ionic.

</comment><comment><USER3> Nice intro to Ionic! Coming from an Angular background but with virtually no mobile experience, this is a great help!

</comment><comment><USER4> great way to get rolling with ionic. soup to nuts.

<comment><AUTHOR> thanks!</comment></comment>


Ask HN: Information to differentiate real/bot traffic? - <AUTHOR> What are some information I can get from request or browser through JavaScript to help me determine if the user is real or a bot? <comment><USER2> There is a global function that just came out this year...

voightKampff();</comment>


Product Strategy Means Saying No - <AUTHOR> http://insideintercom.io/product-strategy-means-saying-no/ <comment><USER2> Reminds me of something I learned from doing art. I've often said, "People think I'm a great photographer. Really, I'm a great editor." I only allow the world to see 2-3% of my output. Working with less experienced subjects, they'd often want several versions of the same basic shot, because I took several good ones. Me, I only want the _best_ version to see the light of day.

<comment><USER3> It seems that people are afraid to "throw away" work, which means they hold on to things they've built (even when they shouldn't) just because they've invested time in them.

But the throwing-away of work is crucial to building something lasting, similar to editing the photos you show to the world. At the very minimum you gain a better understanding of the problem. The thing you keep probably wouldn't be as good without having done the throw-away work.

This also kinda reminds me of the Picasso Principle [1]:

        The famous Pablo Picasso was at a party. A woman
        recognized him and approached the Master. She asked,
        "Will you create a sketch for me?"  Picasso agreed,
        and, as he pulled out his sketchpad, asked her for a
        subject.  "A bird in a tree will do," she responded.
        So Picasso spent about a five minutes doing what
        Picasso does on the sketchpad. Finished, he ripped the
        sketch off the pad, handed it to the woman and said,
        "That will be $10,000."  The woman was floored. "Ten
        thousand dollars! Why, it only took you five minutes to
        draw that sketch!"  To which, Picasso replied, "No,
        madam. That sketch took me a lifetime."

1\. [http://www.ideasicle.com/Ideasicle_Site/Blog_%26_Podcast/Ent...](http://www.ideasicle.com/Ideasicle_Site/Blog_%26_Podcast/Entries/2010/10/4_The_Picasso_PrincipleAnd_The_Value_Of_Genius.html)

<comment><USER4> Picasso was famous for bartering sketches:

[http://answers.yahoo.com/question/index?qid=20100916104440AA...](http://answers.yahoo.com/question/index?qid=20100916104440AAByWVJ)

</comment></comment></comment><comment><USER5> You'd better maximize your listening skills before hurrying to sharpen your 'saying No' skills. Half the time I've heard people say "our problem is we can't say No", it was simply a rescue blanket for their pride because they couldn't/wouldn't face the real problem.

</comment><comment><USER6> I like to think about products as stories. Some things fit into a certain story and some don't. Some stories work well for some audiences and don't for others.

You can imagine and tell any story (build any product) you want. The art is rather to build a great story and often leaving things out even if they sound like a good idea makes the story way better.

Here are great insights about how Pixar creates great stories: [http://www.prdaily.com/Main/Articles/Pixars_22_rules_of_stor...](http://www.prdaily.com/Main/Articles/Pixars_22_rules_of_storytelling_14473.aspx)

Obviously not directly applicable to Product Management but I'm pretty certain that being a great story teller is one of the key skills for Product Management.

<comment><USER6> e.g.: I love this hack:

"When you're stuck, make a list of what wouldn't happen next. Lots of times the material to get you unstuck will show up."

<comment><USER7> Sounds similar to the McDonald's theory:

"I use a trick with co-workers when we're trying to decide where to eat for lunch and no one has any ideas. I recommend McDonald's.

An interesting thing happens. Everyone unanimously agrees that we can't possibly go to McDonald's, and better lunch suggestions emerge. Magic!"

from: [https://medium.com/what-i-learned- building/9216e1c9da7d](https://medium.com/what-i-learned- building/9216e1c9da7d)

</comment></comment></comment><comment><USER8> I think this is great but as a person who has never lead product, when is it time to say yes?

<comment><USER9> Great question.

For our team, _we say yes to whatever solves the biggest pain, for most of our users_.

We discover this by reaching out to customers, and doing a lot of listening. We're trying to answer two questions:

1) What is your biggest pain in your daily work?

2) What is your biggest pain in our software?

#1 usually leads to new features.

#2 usually leads to revisions of what we have already.

<comment><USER10> The question here is how many of the potential customers you've already reached? How do you define the target group? How do you limit it, especially in very early stages?

At first, startup has 0 customers. Apple has a bit more. Both define customers differently.

<comment><USER9> For new products, we try to validate the idea with at least 10 people that are wiling to pay. We start with a narrow niche (as narrow as we can make it).

<comment><USER11> Can I interview you for my book?

email@example.com

</comment></comment></comment></comment></comment><comment><USER10> Reading this, as I prepare my list for tomorrow's product management meeting, having to decide our product's next ~6 months development priorities. Around 100 feature requests and our team's ideas we have to order, of which may be up to 5 major ones and/or 20-30 small ones can be actually developed. An easy task? Definitely not.

So it's a good question, when is it time to say yes?

It definitely depends on the product's stage and having reached or not reached a good product/market fit. There's also the question, have you already discovered a local maxima or is it a global one? And there's a mix of product owner's gut feeling and long-term vision vs proved market feedback.

</comment><comment><USER12> Off topic? Not sure.

This post brought into my attention Intercom[1], which seems like a great product, which perhaps was and is still built with that "The Art of Saying No" philosophy, and which can help you communicate with your users and say yes or no to their requests.

[1] [https://www.intercom.io/](https://www.intercom.io/)

</comment><comment><USER13> Simplistically on target. Well written & good visuals. Agreeing with @wasd that it feels like half the discussion.

</comment><comment><USER14> It is important to view your product from a holistic/macro perspective. With all the various metric tracking available it's easy to derail your product's focus by optimizing features rather than the product.

</comment><comment><USER15> So much wisdom. I don't know what the author does for a living, but I hope if it's product management, he get the piles of cash for it he very clearly deserves.

</comment><comment><USER16> Terrific post.

"Yes" to anything not absolutely critical also carries a below-the-sea-part- of-the-glacier opportunity cost to focus on the most compelling part of your offer.

</comment><comment><USER17> Product posts are always fun here. This "no" strategy is awesome, but only works if you've got support from the C suite. If not, you have sales goals and whoever runs sales will always convince people that they can get more sales with "feature X", which is of course almost always just deflecting responsibility (and is sometimes true for large features that open up new markets).

</comment><comment><USER18> Fantastic post! The iceberg analogy is one I have used for myself and with my teams many times - the downstream complexities are unpredictable and often large. A great post on this topic by Kris Gale, VP at Yammer: [http://insideintercom.io/product-strategy-means-saying- no/](http://insideintercom.io/product-strategy-means-saying-no/)

</comment><comment><USER19> This was a fantastic post, and though i havent implemented the service personally i _have_ used it and the discipline shows.

very insightful article.

</comment><comment><USER20> Well presented work.

If the product in question is an application or Web service with well defined purpose/workflow, then I agree.

If the product is something like an _operating system_ then I disagree. Visualise different users needs as a series of overlapping circles in a Venn diagram. OPs approach would result in truncating the Venn diagram at the intersection, thus satisfying nobody.

Am I wrong? How?

</comment><comment><USER21> That very much depends. Are you saying no because the requested feature doesn't match _your vision_ , or because it doesn't match _what the user needs_?

If it's the latter, great! You're on track to a first-rate product.

But most designers make the mistake of going with the former. That's why most products are second-rate.

<comment><USER22> If a feature request doesn't align with the product's vision, it's perfectly fine saying no. If the vision itself is flawed, then the product is not likely to succeed.

<comment><USER21> Every vision is flawed, because we are fallible. The question is what we do about that. Do we keep the product nailed to the flawed vision until the last user has gone elsewhere, or do we use feedback from reality, from users telling us what they need, to improve the vision?

</comment></comment></comment><comment><USER23> A related essay recently posted on HN too (not sure how to find the HN comments thread...)

[http://firstround.com/article/The-one-cost-engineers-and- pro...](http://firstround.com/article/The-one-cost-engineers-and-product- managers-dont-consider#)

</comment><comment><USER24> Excellent post! And great example of how to say no at the end.

</comment><comment><USER25> The best part of this post is definitely "email@example.com" from "BUT MY COUSIN'S NEIGHBOUR SAID…"

</comment><comment><USER26> #Accurate #Description of the #Industry

#Great#Job

#Thanks #Team

</comment><comment><USER27> Another repetition of that commonplace. If you're stupid and untalented, it won't help you, if you're smart and talented you do not need those generalisms and their points are not important to you.</comment>


Is anyone else dying to know...... - <AUTHOR>

If YC will fund you? Today is November 5th! Shouldn't we hear today? <comment><USER2> I've heard that in previous rounds they e-mail around 9:30PM CST.

Makes sense, I mean if I were PG I'd take all the time I could (seems like a hard decision).

Also, be sure to check your spam folder as I've also heard the message can end up there.

</comment><comment><USER3> "Answers go out by mail at almost exactly the same time as rejections. I've never heard of YC finishing them up before relatively late at night." Scott Wheeler of DirectedEdge (YC), [http://blog.directededge.com/2009/11/05/the- interview-with-y...](http://blog.directededge.com/2009/11/05/the-interview- with-y-combinator-thats-not/#comments)

</comment><comment><USER4> Same here. My demo has been down a number of times recently though because of memory issues and my analytics didn't show visits from the Bay Area. Still, whatever the decision is, I'm excited to know.

<comment><AUTHOR> me too. I have been working hard at mine for months, the demo is really working good now (although I could not show it for the application deadline) I have a new server I am loading up to host it.

We are all smart people!

</comment></comment><comment><USER5> Bummer.. not this time for me. Time to jump from a bridge.. just kidding.

Congrats to the selected ones, can't wait to see what other cool apps come out of this round!

</comment><comment><AUTHOR> no makin it for me either. But I still have such a good feeling my idea will be a winner!

If anyone wants to see if, I'll add you to the list.

</comment><comment><USER6> Truth be told. Yes.

<comment><AUTHOR> Thank gosh I am not the only one.

What was your proposal for?

<comment><USER7> I look to lease rich-media tools for plastic surgeons' websites. Instead of clinical copy to sell procedures, Moxe's media player will use voice, photography, text, and 3D animation to engage visitors. Practices can shorten the sales cycle with marketing that sells more effectively to women. Been at it two years.

<comment><AUTHOR> wow very interesting! I can imagine the market is good. Especially here in California.

<comment><USER7> Thanks Jason...most docs get 40-60% of their new patients from the Internet. There is a single dominating competitor. They have a 99.9% lifelike android operated on in graphic detail. Certainly not something that sells surgery. They are still killing it.

</comment></comment></comment></comment></comment><comment><USER7> I am holding a vigil around my computer...

<comment><USER7> ...and I didn't make it. Suckville</comment></comment>


Jeff Bezos Wrote a Blog Post - <AUTHOR> https://www.theatlantic.com/technology/archive/2019/02/blog-post-bezos-sanchez-medium/582316/ <comment><USER2> This article is really, really missing the forest for the trees.</comment>


Billionaire LA Times owner calls social media the cancer of our time - <AUTHOR> https://www.cnbc.com/2018/09/26/billionaire-la-times-owner-calls-social-media-the-cancer-of-our-time.html <comment><USER2> and what about the LA times? or Billionaires.. it'd be cool if society was more progressive.</comment>


Youtube is down - <AUTHOR> http://www.youtube.com/

<comment><USER2> Has been for at least 10 minutes: [https://news.ycombinator.com/item?id=7086711](https://news.ycombinator.com/item?id=7086711)

EDIT: Actually almost 30 minutes ago by this reddit post: [http://www.reddit.com/r/youtube/comments/1vmnfq/is_youtube_d...](http://www.reddit.com/r/youtube/comments/1vmnfq/is_youtube_down/)

</comment><comment><USER3> Seems back up now.

<comment><USER2> It does, any changes?</comment></comment>