OpenSUSE 13.1 Released - <AUTHOR> http://news.opensuse.org/2013/11/19/opensuse-13-1-ready-for-action/ <comment><USER2> I used to be a die-hard OpenSUSE user.

When 11.4 came out, I complained to my co-worker. "Man, another upgrade. Things always seem to go a little wonky after updating."

He said "wait, what do you mean?"

Turns out he was an Arch Linux user, and Arch uses a rolling release system. The idea of upgrading to a new version doesn't make sense; every system update gives you the newest tested version of everything.

(So now instead of things going wonky every few months, they go wonky constantly :)

OpenSUSE is a fine distro, especially if you're a KDE user. But if you're tired of a big bomb upgrade once every so often, consider a rolling release distro as well.

On the other hand, if you want to run the same code and not worry about upgrading for years, 13.1 is a good choice because it's a longterm support release and will continue to receive bugfixes until 2016.

<comment><USER3> If you want rolling-release, use openSUSE-factory[1], i.e. the development branch (though this might sometimes break on you). If you want an inbetween thing between rolling release and standard, use Tumbleweed[2], which is curated by Greg K-H and brings you new versions of important software, i.e. KDE/Gnome, kernel, git, vim/emacs etc. Tumbleweed uses a set of repositories called *-current, which are always symlinked to the current version. As of today, my next update will bring me onto 13.1 standard for all packages, while Tumbleweed will be emptied soon. In a little while, Tumbleweed will be populated again with updates newer than the 13.1 version, as they appear. This cycle continues until 13.2 is released, and then starts anew.

[1]: [http://en.opensuse.org/Portal:Factory](http://en.opensuse.org/Portal:Factory)

[2]: [http://en.opensuse.org/Portal:Tumbleweed](http://en.opensuse.org/Portal:Tumbleweed)

</comment></comment><comment><USER4> I have been running this for a few months and it was worked well. For the curious I did use BTRFS as my default file system, and KDE4 desktop. A few things I do after installing: * Install proprietary nvidia driver * Install steam (this is a 1 click install from the Suse Wiki) * Install namtrac:subpixel for good looking fonts (zipper ar [http://download.opensuse.org/repositories/home:/namtrac:/sub...](http://download.opensuse.org/repositories/home:/namtrac:/subpixel/openSUSE_13.1/home:namtrac:subpixel.repo)) * Install ksuperkey to use the windows key to open the menu

Great release and nice to see the progress Linux is making!

<comment><USER5> Quick KDE question from a KDE noob: When you open the KDE Menu, is there any way to make it focus the search textbox by default? Or is there a faster way of searching an application or file other than opening the KDE menu?

<comment><USER6> alt-f2 ?

<comment><USER3> You can either hit ALT-F2 or you can just press ALT, hit the first letter of what you are looking for, release ALT, then continue typing.

After hitting ALT-F2, you will see a little spanner on the left of the dialogue that opens. Click on that and you get additional options where to search for your term, including devices, bookmarks, applications, the calculator etc.

</comment></comment></comment></comment><comment><USER7> Yay! When my laptop gets back from being fixed it's going on (now is a good time to get the ISO over bittorrent - there will be many, many seeders). Download link (wrong in article?!) - [http://software.opensuse.org/131](http://software.opensuse.org/131)

(Incidentally, do X series thinkpads still have the plug at the _back_? It switched from the side somewhere between X60 and X220, and if it's at the back it gets bent every time you pick the laptop up from the front - mine failed last week...)

<comment><USER8> Not sure why it's been 7 years since the Magsafe debuted on the MacBook Pro and every laptop doesn't use a similar power cord by now. So many laptops are broken (but fixable) by DC jacks breaking.

<comment><USER9> Yes, typical Apple really, one of those ideas that seem bloody obvious in hindsight, yet they are the only ones doing it.

Prob got a patent of some sort on it.

Looking forward to trying to get this running on my mid 2011 MBA, its currently running Ubuntu and works very well.

<comment><USER10> They did patent it, yeah.

</comment></comment></comment></comment><comment><USER11> I moved from Kubuntu to openSuse. On big plus is easier administration and almost generic packages (except branding). openSuse's Yast is basically a neat GUI wrapper and it works fine even if when you change some config manually.

You need to add Pacman repo to install the goodies.

You can choose to remain with FLOSS software or install proprietary packages if you want.

Besides, a distro doesn't matter much, what matters is what you do on that.

</comment><comment><USER6> OpenSUSE seems like best KDE distro just after Kubuntu.

<comment><USER12> What do you like about Kubuntu more compared to openSUSE?

<comment><USER6> Better font rendering, larger software selection, home folder encryption, WIFI firmware included on CD. I also think apt is better package manager. On other side SUSE has better installer.

I am not sure Kubuntu will survive 14.04. Perhaps there will be replacement based on Debian. Perhaps it will be time to move to OpenSUSE.

<comment><USER7> font rendering is just config. first thing i do with opensuse is install the mstttfonts and enable anti-aliasing (weak hints). [edit] the patent issues have long since died away - [http://www.freetype.org/patents.html](http://www.freetype.org/patents.html)

i'm pretty sure (no numbers) package selection isn't less on opensuse, it's just distributed over more repos. use [http://software.opensuse.org/search](http://software.opensuse.org/search)

you have more encryption options with opensuse - the yast installer (partition manager) is more flexible than the ubuntu one (i couldn't duplicate my opensuse install with ubuntu and had to go with something simpler). and home directory encryption is an option in yast under "details" for add new user.

i have used both. ubuntu is the nicer "out of the box" (it feels more apple- ish). but opensuse allows you to fiddle more - as a developer i prefer opensuse because it's easier to poke around and change things. yast is a huge help when you want it and stays out of the way when you don't - for me it makes opensuse the sweet spot between ubuntu and distros like debian.

<comment><USER6> > font rendering is just config.

Not just config, but patents! There are patents which covers font rendering (thanks a lot apple), so freetype in most distributions is crippled. Ubuntu ships with those patches.

I think on OpenSuse I could install patched freetype (or Infinality which think uses different algorithm).

> but opensuse allows you to fiddle more

I mostly do Debian, so creating a few symlinks is simple. I used Suse a lot 10 years ago.

<comment><USER5> Are you saying that one doesn't need to use these patches on Ubuntu: [http://www.infinality.net/blog/infinality-freetype- patches/](http://www.infinality.net/blog/infinality-freetype-patches/) ?

<comment><USER6> I have to retract my previous statement about fonts.

My config is bit unusual, VRGB with inverse colors. I just installed Suse 13.1 alongside my Kubuntu 13.10 and rendering looks good on both.

I also tried Infinality on 13.1, but fonts did not improved. It also does not seems to have VRGB settings.

Also Firefox in Suse is using KDE file dialogs. Kubuntu gave-up on this long time ago.

So I think I found new home, after my current installation expires.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> > YaST has been ported to Ruby

!!!

<comment><USER14> Why not? Ruby's a great scripting language. Apparently alot of SUSE devs are also Rubyists...

<comment><USER13> It's just that it surprises me when applications are written in Ruby instead of Python, especially on Linux where Python seems to be the king of the high level languages</comment></comment></comment>


Who is still hiring intern? - <AUTHOR>

A CMU student who is good at machine learning, web/mobile development is looking for internship. Please contact her: Jueqiong, email@example.com Thank you. <comment><USER2> urx.com</comment>


Google patents ad-powered taxi service that would offer free rides to shoppers - <AUTHOR> http://arstechnica.com/gadgets/2014/01/google-patents-ad-powered-taxi-service-that-would-offer-free-rides-to-shoppers/ <comment><USER2> Prior Art: Bangkok Tuk Tuk Taxis

You walk up to a driver and tell him where you want to go. He quotes you a ludicrously low price. You hop in. He drives you several miles out of your way and stops you in front of a Priceless Gem Broker's shop, and refuses to budge until you go up and at least take a look around.

This is common enough that you need to actually specify "No Shopping" when you hail a tuk tuk so that you can get a price that involves driving directly from here to your destination.

<comment><USER3> Hah, the first time this happened to me I freaked out. Thought we were being kidnapped, considering the place we were taken to was some seedy bar hidden at the back of a carpark.

</comment></comment><comment><USER4> Clearly this is Google making fun of the patent system.

The value of an ad is, say, ten cents per thousand. You can upgrade the price because you have (a) a captive audience for ten minutes which has (b) already decided to visit your location, but you need to counter that with (c) has already decided to visit your location, so you aren't getting an additional expected profit from that. So, let's say a dollar per 1000. In ten minutes you can show no more than a hundred ads (and showing so many will overwhelm the viewer and desensitize them), so the expected ad value is 10 cents.

Even if the expected ad value is a dollar, that just about pays for a bus ride, not a taxi ride.

OK, so it's a self-driving taxi, no labor costs, electric is cheaper than gas, and you own it so you don't need to make an additional profit, just cover the costs. You still can't do it. Maybe a self-driving bus with a route from a public transport hub to your inexplicably inaccessible location...

<comment><USER5> Alternatively. Take everything you pointed out plus additionally you could generate revenue by showing ads on the body of the taxi cabs (which also generates decent revenue). Google could pursue this idea to show the viability of self-driving cars even at a bit of a loss in one or two cities at small scale.

Not everything is about making profit and money directly. Google have repeatedly showed that they don't go after projects thinking about generating profit first. And honestly if I had to bet on any single company trying to push the envelope in making self-driving cars in our daily life (not merely as a concept that is possible), Google is it. If Google doesn't go for it, no one else will do it anytime soon, or even in our lifetime IMO.

<comment><USER6> A self-driving Taxi + Ads. The mind boggles.

Imagine. The taxi would probably take a sponsored route through commercial hubs. Show you a good view of a hotel perhaps so that you take a room there. The radio would play ads and the windows would be transparent panels with overlaid ads.

This whole focus of Google on ads is sickening.

</comment></comment></comment><comment><USER7> They day I can give up my driving commute and order a ride uber style and for a reasonable subscription. I'll be all over it.

<comment><USER8> Perhaps the cab companies could work together to raise funds for a isolated road network (call it something web 2.0 like "rails") and then offer to drive on the "rails", subsidising your journey by making you share with others in the cab. In fact why not have the driver sit in the "cab" and you can ride in a trailer behind, with the othr passengers.

I think we are onto something.

:-)

(could not resist)

Edit: in all seriousness I looked quite hard for ride-shares to help me with a killer commute. I even looked at the price of a daily taxi doing 100 miles pday (ha ha ha) and one a different contract was amazed to find a large 16 wheeler coach that passed by my house (in commuter-land) and dropped off in Central London on the same street as the clients office. (Notably with the coffee shop between the drop off point and the office, saving everyone some time.)

</comment></comment><comment><USER9> I could see this working for a company if the passenger was offered a voucher to the value of the taxi ride off goods/services that the company sells.

I'm not sure offering a free ride to a centrally located business would make financial sense.

Is it important to offer a free return journey?

Of note, in the UK, some out of town supermarkets offer a free bus service to them. However the key bit is that there is usually nothing else near them to make it worth taking the bus unless you actually want to go to that supermarket.

<comment><USER10> I am assuming the ad offer would take many things into consideration. the main one being distance, I doubt you could really use such a feature to actually get to somewhere you need to go.

I would also like to point out that every ride they give, and every offer a customer uses, they are getting that much more data to create better behavior guesses which will help show the ads that would be used instead of abused. I also could see this being offered only after you have put in a destination (and thus also your credit card which means you actually need transportation) and if you are going to an area with a ton of restaurants at 5pm, it might instead suggest a restaurant (not near the destination). this couldn't be abused as easy.

I honestly don't see a way this couldn't be profitable in the long run knowing how Google uses all of their behavior data. (this all really depends on the car being self-driven)

</comment></comment><comment><USER11> I've seen something like this done in Europe, but with bike rickshaws.

The service seemed to very popular and heavily used, but it would be hard to say if those people weren't already going to the store and were just taking advantage of the free transport.

</comment><comment><USER12> Why has an exclamation mark vomited all over their patent.</comment>


Firefox Lockwise – Take your passwords everywhere - <AUTHOR> https://lockwise.firefox.com/ <comment><USER2> I'm surprised there isn't more information on the landing page.

This looks like a mobile password manager, but I honestly can't tell due to the lack of information.

<comment><USER3> Yup. I googled and found this page which gives some more insights. [https://www.ghacks.net/2019/05/29/mozilla-releases- firefox-l...](https://www.ghacks.net/2019/05/29/mozilla-releases-firefox- lockwise-formerly-lockbox-add-on/)

</comment></comment><comment> _o-O-o_ It used to be called Lockbox, but they rebranded it as Lockwise[0] which (recently) now works in the Firefox Desktop version. Previously it only advertised for two app stores (Google Play and iTunes), but now offers the desktop version.

[0] [https://www.ghacks.net/2019/05/29/mozilla-releases- firefox-l...](https://www.ghacks.net/2019/05/29/mozilla-releases-firefox- lockwise-formerly-lockbox-add-on/)

</comment><comment><USER4> I'm sad that there isn't a system I can control without handing administration over to a third party. I haven't been able to convert my personal life over to full random password in a manager with full 2FA because I agonize over the fact that if my phone gets wet (Or has any sort of problem at all) I am locked out of my life with no real recourse, and if I screw something up in the third party password manager I lose my online life I've built up over 15 years

</comment><comment><USER5> It looks like for some reason they've just renamed Firefox Lockbox, which was released almost a year ago. Previous discussion here: [https://news.ycombinator.com/item?id=17498631](https://news.ycombinator.com/item?id=17498631)

<comment><USER6> From the FAQ:

> _What is Firefox Lockwise?_

> _Firefox Lockwise is an experimental product from Mozilla_

Sounds like the rename is an indicator of approaching release stability, leaving "Lockbox" as essentially the internal codename.</comment></comment>


What The Rails Security Issue Means For Your Startup - <AUTHOR> http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/ <comment><USER2> The "everybody has bugs" response is intellectually dishonest. Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea.

\- Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't.

\- Thousands of ostensible developers used this parser, saw the fact that it could deserialize more than just data, and never said "Oh dear, that's a _massive_ red flag".

\- The bug in the YAML parser _was reported_ and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad.

\- The issue was reported to RubyGems multiple times and they _did nothing_.

This isn't the same thing as a complex and accidental bug that even careful engineers have difficulty avoiding, after they've already taken steps to reduce the failure surface of their code through privilege separation, high- level languages/libraries, etc.

 _This is systemic engineering incompetence that apparently pervades an entire language community, and this is the tipping point where other people start looking for these issues._

<comment><USER3> Any sufficiently advanced serialization standard will let you serialize/deserialize a wide variety of objects. When J2EE SOAP libraries are passing large amounts of XML back and forth over the wire, it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. As J2EE has learned to its sorrow, there are some good choices for objects to allow people to deserialize and some not so good ones.

<http://wouter.coekaerts.be/2011/spring-vulnerabilities>

If J2EE is a boring platform to you, pick your favorite and Google for a few variants. You'll find a serialization vulnerability. It's hard stuff, by nature.

* The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad.*

Do you have a citation for this? What particular bug _in the parser_ are you referring to? The behavior which is being exploited is a fairly complicated interaction between the parser and client Rails code -- I banged my head against the wall trying to get code execution with Ruby 1.8.7's parser for over 12 hours, for example, without any luck unless I coded a too-stupid-to- be-real victim class. (It's my understanding that at least one security researcher has a way to make that happen, but that knowledge was hard won.)

<comment><USER2> > _Any sufficiently advanced serialization standard ... it is often going to > get instantiated via calling a zero-argument constructor and then firing a > bunch of setter methods._

Yes, this is always a bad idea. It's actually in a similar problem space as the constant stream of vulnerabilities in the Java security sandbox (eg, applets); all it takes is one mistake and you lose.

And thus, people have been saying to turn off Java in the browser for 4+ years, and this is also why Spring shouldn't have implemented such code.

> _It's hard stuff, by nature._

Which is why deserializing into executable code is a bad idea, by nature. I'd thought this was well established by now, but apparently it is not.

> _Do you have a citation for this? What particular bug in the parser are you > referring to?_

<http://github.com/tenderlove/psych/issues/119>

<comment><USER4> > Which is why deserializing into executable code is a bad idea, by nature. > I'd thought this was well established by now, but apparently it is not

I'm not sure that means anything. In an OO language, you are always de- serializing into objects, and objects are always 'executable code'. Hashes and Arrays are executable code too, right?

The problem is actually when you allow de-serializing into _arbitrary_ objects of arbitrary classes, and some of those objects have dangerous side effects _just by being instantiated_, and/or have functionality that can turn into arbitrary code execution vector. (Hopefully Hash's and Array's don't).

It is a problem, and it's probably fair to say that you should never have a de-serialization format that takes untrusted input and de-serializes to anyting but a small whitelisted set of classes/types. And that many have violated this, and not just in ruby.

But if you can't even describe the problem/guidance clearly yourself, I think that rather belies your insistence that it's an obvious thing known by the standard competent programmer.

(I am not ashamed to admit it was not obvious to me before these exploits. I think it was not obvious to a bunch of people who are in retrospect _claiming_ it was obvious to.).

<comment><USER5> What you are looking for is not "OO language", but "dynamic interpreted language".

In a traditionally compiled OO language like C++, classes cease to exist after compilation; there is no fully generic way to instantiate an object of a class by data determined at runtime. So this whole concept of deserializing to whatever the protocol specifies goes completely out of the door.

<comment><USER6> "Interpreted" is too restrictive. For example, Objective C provides NSClassFromString().

<comment><USER5> One could argue that since every call goes through a runtime messaging framework, Objective C is really just an interpreted language with pre-JITed function bodies.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> This quote caught my attention:

        There are many developers who are not presently active on a Ruby on Rails
        project who nonetheless have a vulnerable Rails application running on
        localhost:3000.  If they do, eventually, their local machine will be
        compromised. (Any page on the Internet which serves Javascript can, currently,
        root your Macbook if it is running an out-of-date Rails on it. No, it
        does not matter that the Internet can't connect to your
        localhost:3000, because your browser can, and your browser will follow
        the attacker's instructions to do so. It will probably be possible to
        eventually do this with an IMG tag, which means any webpage that can
        contain a user-supplied cat photo could ALSO contain a user-supplied
        remote code execution.)

That reminded me of an _incredible_ presentation WhiteHat did back in 2007 on cracking intranets. Slides[1] are still around, though I couldn't readily find the video.

[1]: [https://www.whitehatsec.com/assets/presentations/blackhatusa...](https://www.whitehatsec.com/assets/presentations/blackhatusa07/0807blackhat_hacking.pdf)

<comment><USER8> Other than ease of setup, I've never understood why you wouldn't develop in the same environment as what you're running in production. Setting up a vm is trivial and allows you to easily open/close access to your application as needed.

There is also a lot less headaches once you've decided to move it into production.

<comment> brown9-2 I don't think this would be any more secure if you were to enable networking on the VM to allow requests from the host machine, which seems like common behavior so that the developer can access the webapp running on the VM from a browser on the host. Or are people developing inside a VM and then testing with a browser on the VM?

<comment><USER9> You can set up a cloud VM (on Rackspace for example), and then set up your VM's firewall (iptables) to only allowing connections from your test machines (could be your local IP, or the IP address of the test machines from Browserstack or Sauce.) This allows you to keep your dev/staging/prod environments in sync (and allows you to do things like blueprint/image your dev setup to build it elsewhere), decouple your dev from your staging/prod, and allow you to develop from anywhere without needing to carry around the same laptop or rebuild your dev environment on another box - particularly if you use an intermediate system with a static IP so you can reconfigure your firewall whenever needed.

</comment></comment></comment></comment><comment><USER10> When I look at the Ruby/Rails community, the word that comes to my mind more than any other is _hubris_.

You see this in things such as security issues being marked as wontfix until they are actively exploited (e.g. the Homakov/GitHub incident), in the attitude that developer cycles are more expensive than CPU cycles, and on a more puerile level in the tendency towards swearing in presentations.

I've always had the impression that the Rails ecosystem favours convenience over security, in an Agile Manifesto kind of way (yes, we value the stuff on the right, but we value the stuff on the left even more). One of the attractions of Rails is that it is very easy to get stuff up and running with it, but some of the security exploits that I've seen cropping up recently with it make me pretty worried about it. I get especially concerned when I see SQL injection vulnerabilities in a framework based on an O/R mapper, for instance.

<comment><USER11> I have the same impression.

Many start-ups are built by well-meaning people who have no formal CS or even engineering background and thus are somewhat out of touch with what it means to build a robust system. It's natural for people to focus on "what's important" and ignore boundary/edge conditions, while in reality 90% of sound engineering is getting boundary/edge cases right.

And as most of such start-ups use Ruby/Rails due to the easiness of "getting it up and running", and thus they inject the Ruby/Rails ecosystem with this "focus on what's important" mindset, important boundary issues, including security, are neglected.

</comment></comment><comment><USER12> I think the recent Rails, Java, RubyGems and other vulnerability issues have been an absolute boon to the industry. And not just for the increased business I think most security consultants are going to be seeing.

The exploits have happened in ways that have exposed and hammered home the myriad places many applications expose unexpected side channels and larger attack surfaces than you'd think. These issues have opened a broader range of people to vulnerability, and I think opened a lot of people's eyes to the need for a sense of security and what that really means.

Top that with the level of explanation we've seen in at least the Rails and Ruby exploits, it's been a tremendous educational opportunity for a lot of people who will benefit greatly from it, and by proxy their users.

When the idea of a "SQL Injection" first became really prevalent, we saw an uptick in concern for security amongst framework developers, as far as I could tell. I think this will help get some momentum going again.

Speaking as a non-expert on the subject, security is all about a healthy sense of paranoia, across the board :)

<comment><USER13> +1

I was going to post something similar. Also we often see people insulting others when they post exploits too early or describe exploits in depth too early. Posting stuff like: _"You're an .ssh.le, wait a few days before posting that"_.

I don't think so. I think exploits should be publicly posted as soon as possible and affecting as many people as people. Maybe even damaging exploits, actively deleting users data or servers data.

The bigger the havoc, the sooner the entire industry is going to realize security is a very real concern.

People are still considering buffer overflow, SQL injection, query parameters objects instantiation through deserialization exploits, etc. to be "normal" because "everybody creates bugs" and "a lot of bugs can be exploited".

I think it's the wrong mindset. Security if of uttermost importance and should be thought of from the start.

For example I'm amazed by the recent seL4 microkernel which makes buffer overflow provably impossible (inside the microkernel) or even the Java VM (the JVM) which makes buffer overflow in Java code impossible. It's not perfect (we've seen _lots_ of major Java exploits, but zero were buffer overrun/overflow in Java code... Some in 3rd party C libs, but zero in Java code. Some other Java exploits too of course, but zero buffer overrun/overflow).

So security exploits are _not_ a fatality.

All we need is people, from the very start, to conceive systems more resilients to attacks.

The more attacks, the more exploits, the more bad reputation and shame on clueless developers, the better.

I actually start to love these exploits, because they fuel healthy research by the white-hat community.

And one day we'll have more secure microkernels, more secure OSes, more secure VMs, more secure protocols, etc.

Let them security exploits come.

</comment></comment><comment><USER14> It would be interesting if someone wrote a worm that just took all the vulnerable rails apps offline. That way we would have less worry about a million compromised databases. It could be launched from a bookmarklet run from tor browser, and would probably exhaust every ip address in a few days. It would also land whoever did it in jail for a really long time.

<comment><USER15> Maybe, though with today's legal climate such a thing would be extremely, extremely risky. Gaining unauthorized access to a computer system and exploiting it in a way that potentially causes loss of revenue is not something you want to do lightly even if it might be the right thing to do.

</comment></comment><comment><USER16> This is a pretty good example of why I hate big frameworks. They are simply too big to prevent stupid issues like YAML extraction in JSON and XML.

If you are like me, you would expect that YAML was used in the configuration files and _nowhere_ else. A small framework like Sinatra wouldn't have been big enough to hide an issue like this.

<comment><USER17> Really? Has a giant framework like Django had bugs this severe, that allowed data-file parsers to execute arbitrary attacker code?

<comment><USER18> Nearly. Both piston and tastypie (the two leading frameworks for writing APIs for django) were affected by a very similar code execution vulnerability a while ago. see [https://www.djangoproject.com/weblog/2011/nov/01/piston- and-...](https://www.djangoproject.com/weblog/2011/nov/01/piston-and-tastypie- security-releases/)

<comment><USER19> Those were both third-party modules for Django (albeit popular ones). But at best, this means that Rails devs have known since Nov 2011 or so that YAML code should be carefully audited, _especially_ since there was _no_ equivalent in Ruby for Python's .safe_load ([http://stackoverflow.com/questions/14348538/is-there-an- equi...](http://stackoverflow.com/questions/14348538/is-there-an-equivalent- to-yaml-safe-load-in-ruby)).

I don't mean to beat on the Rails guys too hard though, they're off shipping stuff and I'm not and I'm not very fond of those who criticize while a safe distance from the action. But I think it's fair to say that this could have been foreseen earlier (or much earlier, depending on who you ask).

</comment></comment></comment></comment><comment><USER20> > The recent bugs were, contrary to some reporting, not particularly trivial > to spot. They're being found at breakneck pace right now precisely because > they required substantial new security technology to actually exploit, and > that new technology has unlocked an exciting new frontier in vulnerability > research.

What technology is he talking about here?

<comment><USER3> Basically, a new way to combine things we already know about. Like, you might have already unlocked "stone axe", "vines", and "dry wood", but given those three primitives I can show you a novel way of combining them that repeatable produces fire. We know have a fun and exciting new way to use commonly- accepted-general-purpose-programming-tools to blow stuff up, and are iterating -- rapidly -- on bringing other previously-assumed-safe constructs into the "blows stuff up" zone of knowledge.

<comment><USER20> I'm not sure I get what you're the analogy to.

When I first read your blog post I got the impression that you were saying that the YAML vulnerability were found with some new code scanning technology that lets us find bugs in Rails faster. Or are you just saying discovering the existence of the YAML.load() class of vulnerability is "new security technology?"

Or are you talking about the ronin support module people are using in some of the PoCs?

<comment><USER3> So if I had told you at Christmas three salient facts:

\+ Some objects are unsafe to instantiate if you don't pick all values you initialize them with very carefully.

\+ YAML can instantiate objects from any class.

\+ Rails uses YAML, in a lot of ways.

You might have said "Yes, I am aware of all these three things. Do you have anything important to tell me?" Now, if I demonstrate to you working PoC code which combines those three into remote code execution, the _substantial_ work involved in producing that PoC code -- finding the vulnerable classes which ship with Rails, demonstrating how to get data from where the user controls it into the far-inside-the-framework bits where Rails might actually evaluate YAML, etc etc -- immediately starts suggesting lots of other fun ways to use variants of that trick.

<comment><USER21> Anyone competent would, when knowing those three things, immediately think of the possible exploits.

<comment><USER22> And yet they didn't, and here we are.

Yes, it's _super_ easy to call everyone involved with the YAML library incompetent, but let's be honest - they're not, in general. They fucked up here, and hindsight is 20/20, but I think it's only face-stabbingly obvious now because of what's actually happened.

<comment><USER19> I wouldn't necessarily blame the YAML _library_ devs, assuming they documented that it could instantiate arbitrary classes.

I do more Perl but I can tell you that "this deserializer can create new arbitrary objects" would give _screaming_ alarm bells. And that is because there is a long history of trying (and failing) to safely do stuff like this (e.g. note the lack of warrant for the Safe CPAN module: <http://search.cpan.org/~jhi/perl-5.8.0/ext/Opcode/Safe.pm> )

Python has the same well-known and well-documented issue with their pickle module.

In general using /any/ deserializer that can create arbitrary objects of arbitrary classes has been known to be a bad idea for some time, and as far as I can tell Ruby YAML documents that it supports doing exactly this: <http://www.yaml.org/YAML_for_ruby.html#objects>

So if we were talking about a security vuln from something like JSON where we expect benign data to be the only possible output I think I'd agree completely.

Using a deserializer even more powerful than that is at the very least a bad smell from the POV of security, especially post-Spring (fixed in 2011, even if it was re-iterated 2013), so I wouldn't be so quick to claim this could only have been predicted in hindsight.

I get that it's still hard work to move from "I made an object of my choosing" to "framework pwned" but you pretty much _have_ to assume that the former implies the latter nowadays. It was more than 5 years ago now that tptacek was gushing over Dowd's "Inhuman Flash Exploit" and I somehow don't think that pen testers and security experts have gotten any dumber since then. ;)

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> This was a hugely helpful big-picture overview of the recent vulnerabilities. Everyone, please go read it.

I had been meaning to get some context for the recent spate of security problems and this provided that in spades. Thanks for taking the time to write it up and post it.

</comment><comment><USER24> > The first reported compromise of a production system was in an industry > which hit the trifecta of amateurs-at-the-helm, seedy-industry-by-nature, > and under-constant-attack. It is imperative that you understand that all > Rails applications will eventually be targeted by this and similar attacks, > and any vulnerable applications will be owned, regardless of absence of > these risk factors.

Who was the first reported compromise of a production system?

<comment><USER25> I believe Patrick is referring to this Bitcoin exchange being hacked: <http://news.ycombinator.com/item?id=5043122> .

</comment></comment><comment><USER26> All the RubyGems stuff is happening at a high rate and I understand that over 90% of the Gems are now verified and it looks like nothing was backdoored but I couldn't find a good summary of the current situation so I have a couple of questions.

1) Is it currently safe to "bundle update" and be confident that only verified Gems will be provided? I don't mind errors on any unverified ones but don't want to download them.

2) Is there a drop in replacement for RubyGems? The problems that have occurred this month would have been multiplied if RubyGems was unavailable at the time Rails had an apocalyptic bug.

<comment><USER8> Pretty good breakdown going on here [1]. To be honest, while the chosen tool to provide the update is odd, it is one of the best post-mordems that I've seen and applaud the volunteers for taking it so seriously.

1\. I wouldn't say so. Not until they're all the way through.

2\. Not at the moment, but general guidance is that we should all have local gem repos that we maintain ourselves and only rely on external sources when needed. It is something I'm going to look into ASAP.

[1] [https://docs.google.com/document/d/10tuM51VKRcSHJtUZotraMlrM...](https://docs.google.com/document/d/10tuM51VKRcSHJtUZotraMlrMHWK1uXs8qQ6Hmguyf1g/edit?pli=1#)

<comment><USER26> It is extensive and up to date but it is lacking a brief status of the current situation and whether the site is safe to download from. The answer is currently "no", 90% safe is unsafe.

It's a shame that they seem to have put the service back up in an unsafe mode, I would have hoped that they could have quarantined the unverified Gems.

Edit: Looking at the status page the API is down so it can't be accessed from Bundler so they are doing it the good/safe way.

</comment></comment></comment><comment><USER27> This blindness to how bad YAML was is causing "convention over configuration" to devolve into "security by convention".

<comment><USER28> you mean "insecurity by convention"?

</comment></comment><comment><USER21> To me it seems that all of this is due to the obsession with implicit behaviour in Rails, and to some extent Ruby.

I hope they learn from this and stop chanting "convention over configuration" when told that explicit is better than implicit.

</comment><comment><USER29> Is this YAML vulnerability something that can be patched in relatively short order without Rails itself having to be completely rewritten?

Or should I basically just not run Rails on any machine ever anymore, get a different web server, and start implementing my own request routing and ORM without any sort of YAML-parsing magic?

>One of my friends who is an actual security researcher has deleted all of his accounts on Internet services which he knows to use Ruby on Rails. That's not an insane measure.

So anyone who uses Twitter, for example, could have their passwords and other data stolen through this exploit?

<comment><USER3> _Is this YAML vulnerability something that can be patched in relatively short order without Rails itself having to be completely rewritten?_

Long story short: There's a variety of things that can be done to mitigate this vulnerability and an active conversation on which is the best option. My go-to suggestion would be having Rails ship with either a non-stdlib YAML serialization/deserialization parser or have it modify the stdlib one, with the major point of departure being "Raise an exception immediately if the YAML encodes any object not on a configurable whitelist, and default that whitelist to ~5 core classes generally considered to be safe."

 _Or should I basically just not run Rails on any machine ever anymore, get a different web server, and start implementing my own request routing and ORM without any sort of YAML-parsing magic?_

That is astonishingly unlikely to be a net-win for your security.

 _So anyone who uses Twitter, for example, could have their passwords and other data stolen through this exploit?_

I'd expect that Twitter (in particular) has a better handle on it than your average startup, but successful exploitation of this means the attacker owns the server, if the attacker owns the server they probably get all the servers, and they will tend to gain control of any information on all of the servers. That can include, but is certainly not upper-bounded by, passwords/hashes stored in the database. It is _absolutely_ possible, and indeed likely, that many people will be adversely affected by this vulnerability without themselves running Rails or even, for that matter, knowing what Rails is.

<comment><USER29> >>Or should I basically just not run Rails on any machine ever anymore, get a different web server, and start implementing my own request routing and ORM without any sort of YAML-parsing magic?

>That is astonishingly unlikely to be a net-win for your security.

In the long run, you are probably right. Once this gets fixed, which will probably be soon considering how much attention is on it.

But in the short run, is there anything worse than a vulnerability that allows a remote attacker to automatically detect, penetrate, and execute arbitrary code on your machine? To the point where it's not even safe to run the framework on localhost on your dev box?

</comment></comment></comment><comment><USER30> So I went through my heroku closet and cleaned everything up (pulling the plug on unneeded apps and making sure needed apps were up to date).

My question: do these security issues affect Sinatra apps?

<comment><USER31> These issues affect all apps which deserialize arbitrary user-specified YAML. I suspect Sinatra doesn't provide any attack surface by default here, but Sinatra apps tend to have a lot of bolted-on functionality, so it's worth doing an audit of any Sinatra apps you run to make sure you haven't introduced any exploitable surfaces.

</comment></comment><comment><USER32> "Any page on the Internet which serves Javascript can, currently, root your Macbook if it is running an out-of-date Rails on it."

Why are you running Rails as the root user? This is a bad idea.

EDIT: I'm not really into client-side JavaScript these days, but when did browsers start allowing JavaScript to connect to anything except the server from which it came? That would be yet another Bad Idea.

<comment><USER33> You have bad assumptions. It is all about leveraging access to higher and higher levels.

1\. You load the evil JavaScript.

2\. That JavaScript adds an image with a URL pointing at localhost:3000.

3\. When you load that URL, it causes code execution, causing your computer to open a connection somewhere and start taking instructions.

4\. The instructions that arrive includes downloading and installing software that takes advantage of known local root vulnerabilities in OS X.

5\. Congratulations! Someone rooted your machine!

Nothing in this path required Rails to be run as root, or JavaScript to directly connect anywhere.

<comment><USER32> You're right. I wasn't seeing all the angles here. But to say this is limited to Macs seems disingenuous.

<comment><USER33> He didn't say it was limited to Macs. He gave it as a random example of what could happen.

<comment><USER32> I'm pretty sure OP specifically said "Macbook" in the article. But see patio11's comment beside yours.

</comment></comment></comment></comment></comment><comment><USER34> Is Rails moving to a YAML (or almost-YAML) parser that does _not_ execute code for future major releases? I find it hard to believe that such functionality is used often. Until then, as the article says, people will just keep finding zero-days. This seems like the only logical choice for the Rails core team.

</comment><comment><USER35> I'm losing my Ruby and Rails faith here; what gives? This is just as bad as leaving SQL injection attacks open.

<comment><USER36> _This is just as bad as leaving SQL injection attacks open._

No, it is much worse.

</comment></comment><comment><USER37> Given the severity, it'd almost be a public service to hit every public Rails server and exploit it to patch it with the security fix(es)...

</comment><comment><USER38> New internet law: any sufficiently sized platform or framework will attract increasingly more compromising/malware attacks. Anyone running Wordpress still knows this all day.

</comment><comment><USER39> Some time ago I asked certain Ruby people how to dynamically load Ruby code (for configs). They told me it's Wrong. Seems that in practice the idea wasn't much worse than Yaml after all.

I am still convinced that configs and templates should be treated as executable code and are best implemented in the same language they're used from. At least it makes certain things blatantly obvious. (It also makes a lot of other things possible without any extra coding/learning.)

</comment><comment><USER40> You do all deploy from your own cache of all the gems you depend on, right? No? Why not?

<comment><USER8> I'd love to. Any helpful guides on how to proceed?

<comment><USER41> I just wrote a blog post: [http://words.steveklabnik.com/how-to-not-rely-on- rubygemsorg...](http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg- for-deployment)

<comment><USER42> Wasn't aware of bundle --deployment, that's very helpful thank you steve.

<comment><USER41> Any time! Not enough people are.

</comment></comment></comment></comment></comment><comment><USER43> Is there no hardened version of Psych which lets you either disable object deserialization, or whitelist classes? That would seem like the safest option right now to guard against coming vulnerabilities in Rails in this regard.

<comment><USER44> This is currently being discussed on <https://github.com/tenderlove/psych/issues/119>

There is also <https://github.com/dtao/safe_yaml> (hat tip @patio11, who also points out that this has not been audited for completeness/correctness)

</comment></comment><comment><USER45> Why do people write things like "We Should Avoid #'#(ing Their #()#% Up" instead of "We Should Avoid Fucking Their Shit Up"?

<http://www.youtube.com/watch?v=dF1NUposXVQ>

</comment><comment><USER46> [http://homakov.blogspot.com/2013/01/rails-is-fragile- vulnera...](http://homakov.blogspot.com/2013/01/rails-is-fragile- vulnerabilities-will.html) This.

</comment><comment><USER47> It seems like the Ruby guys should spend a little more time learning the basics of CS in between two self promotion ("rockstar developers", anyone?).

</comment><comment><USER48> How feasible would it to have a gem that sits in middleware that would check for possible attacks before the string gets any further and block/share IPs of people fishing for exploits?

I could see it as a service company that shares blacklist info between sites and can even find new exploits from the "bad" requests.

</comment><comment><USER49> I'm not a Rails developer, is JRuby on Rails affected by this?

</comment><comment><USER50> Why don't we have "building codes" for software?

There was a time when anyone who claimed to have the ability could design and build things like bridges and buildings. After enough of them collapsed due to repeated, avoidable mistakes, we said no, you can't do that anymore, you need to be licensed to design and build buildings, and furthermore you have to follow some basic minimum conventions that are proven to work. And you and your firm has to take on personal liability when you certify that your design and construction follows those basic best practices.

</comment><comment><USER51> So what are the good versions of recent minor versions of rails? And where can I find them in the future?

</comment><comment><USER52> Nothing. Neither recent Java flaws.

</comment><comment><USER53> As much as I was a fan of developing Ruby apps, I was constantly shocked by the lack of engineering, security concern, stability of API, basically serious software engineering within the community.

It would be good if all this was a clarion call to the Ruby community to improve things holistically, rather than the current trend of band-aid fixes they seem to apply.

<comment><USER54> ಠ_ಠ

Because other frameworks are rock-solid. Yup. None of this happens anywhere else on the internet.

<comment><USER21> Nothing quite this catastrophic tends to happen to things that aren't PHP.

<comment><USER41> That is simply not true. Here's an example linked upthread for Struts, for example: [http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork- remote...](http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote.html)

</comment></comment></comment></comment><comment><USER13> Code execution while deserializating / parsing data is my first and uttermost concern. Nowadays I'm in Clojure land and it's still not entirely clear as to what I can and cannot do and what the language as to offer me so that data doesn't contain rogue code that is going to be executed.

In Common Lisp, for example, as far as I know you can set a flag so that the reader is set to "no evaluation ever" (if I understand things correctly) and, hence, if you're not using eval yourself specifically, nothing is ever going to be evaluated.

But how would that work in Clojure? And what about other languages? Ruby? Haskell? Java? C#?

I think the ability to execute code became _the_ most important security issue (more than buffer overflow/overrun which can now be prevented --even sometimes provably impossible to happen thanks to theorem provers).

More thoughts should be put into explaining how/when a language / API can execute code and how it should/can be used to prevent such a thing from happening.

</comment><comment><USER54> FUD much

<comment><USER3> Hiya, welcome to Hacker News. I'm Patrick and I wrote this article. I run four businesses, three of which are intimately tied to Ruby on Rails, I am a contributor in the community, and I want to see it win. If you believe I am trying to spread fear, uncertainty, or doubt, you are greatly mistaken about my motives.

As someone who loves Rails, to someone who presumably likes Rails, _it is imperative that you understand_ how serious this issue is. If you use Rails, you need to have addressed this already. If you have not, drop what you're doing and go fix it _right now_.

<comment><USER55> Patrick, Thank you for writing this article. It opened my eyes to how serious this issue is and how easy it is to compromise a server. Upgrading all my rails apps now. Thanks again.</comment></comment></comment>


The next thing Silicon Valley needs to disrupt big time: its own culture - <AUTHOR> http://qz.com/225782/the-next-thing-silicon-valley-needs-to-disrupt-big-time-its-own-culture/#/h/80667,1,2,3,4,5,6/

<comment><USER2> This is a great read. Especially the story about how the founder of Lotus, Mitch Kapor, gave a talk about "dangers of what he called the 'mirror- tocracy': confirmation bias, insularity, and cliquish modes of thinking." which was followed by a talk by Mark Zuckerberg. Mark came late, hadn't heard Mitch's talk, and led with: "I want to stress the importance of being young and technical. Young people are just smarter." Facepalm LOL!

</comment><comment><USER2> Why not link to the original directly:

[http://carlos.bueno.org/2014/06/mirrortocracy.html](http://carlos.bueno.org/2014/06/mirrortocracy.html)

The original has follow-up articles on the same theme.

<comment><USER3> Posted a few days ago, with extensive discussion:

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


Company was hosting cardiac patient monitoring on EC2 - <AUTHOR> https://forums.aws.amazon.com/thread.jspa?threadID=65649&tstart=0 <comment><USER2> This is a combination of posters not understanding what the technology is used for and the tech guy exaggerating the urgency of the situation.

Remote cardiac monitoring isn't for people who are imminently going to die of catastrophic heart attacks or who risk dropping into a fatal arrhythmia (wonky heart rhythm). In fact, there isn't even solid evidence that it saves lives. What it _is_ used for is investigating patients who have vague symptoms which might be related to transient changes in their heart beat.

These are people who come to their doctor at the age of 54 and say "I felt my heart beating really quickly and felt kind of faint" or "I felt kind of dizzy and then passed out. It's happened twice in the last month." The more traditional way to investigate these patients are with what's called a Holter monitor, as alluded to by a previous poster. These are little belt packs you carry around while wired-up and that record your ECG for 24-48 hours at a time. The main weakness? You said it: the device only has a 24-48 hour windows to capture the weird, often rare, rhythm.

There are different ways remote cardiac monitoring systems report their results and I'm not sure which this particular company was using, but it doesn't really matter. Some of them only report weird stretches, others only report events when the patient says they're feeling symptom X, others are reporting continuously.

Take-home message: this is not life-or-death data. When doctors (at least those who are allowed to keep practicing) think a patient needs critical cardiac monitoring, they admit them to hospital.

This was a tech guy, looking to jump the queue by trying to raise a red flag because his servers were being used for--OMFG!--cardiac monitoring. A lot of my doctor buddies use similar strategies when they're caught speeding by the police. "I just got called in to the hospital!"

…to see a patient with a really nasty rash.

<comment><USER3> From the website I think this analysis is correct. Holters store the 24 hour data on the machine as well. The 12 leads are not continuous but set pieces which also store locally. If they were providing real-time monitoring with alerts then this would be more serious. This seems to be a backup system, ironically itself without backups.

</comment></comment><comment><USER4> This reminds me of doing tech support back during the dot bomb. Everyday we'd have day traders phone in complaining that their internet was down and they were losing thousands of dollars. Then I'd advise them to switch to their backup connection, then they'd say they didn't have one.

Finally, I'd ask why if they were running a business that could generate / lose thousands of dollars in a few minutes why they had chosen a residential internet service instead of opting for the business package and why they did not have a backup connection as neither the business packages or residential packages came with a SLA that was suitable for the type of risk inherent in their business.

If their data is so important why are they hosting it on the absolute cheapest and shittiest servers they can find without a backup solution in place? If they read the TOS for EC2 it probably says not to run critical infrastructure on it.

Perhaps for sensitive data upon which people's lives depend they might want to look into something like:[http://h20223.www2.hp.com/nonstopcomputing/cache/76385-0-0-0...](http://h20223.www2.hp.com/nonstopcomputing/cache/76385-0-0-0-121.html?jumpid=go/integritynonstop)

Yes, it costs more than EC2, but there's a reason for that. Wait until this company finds out that if their values exceed what MySQL expects it will silently truncate it.

</comment><comment><USER5> _We are a monitoring company and are monitoring hundreds of cardiac patients at home._

If this is a serious post and there really is a service that monitors cardiac patients from home, first you would have to deal with the unreliability of in- home broadband connections. What if a router needs to be reset, or the DSL goes out? Even if you ignore that, you would expect that any server setup will go down at some time. It has happened to Google, Facebook, Twitter, and now AWS and PlayStation Network. I remember when Rackspace went down a few years back (a truck crashed into the transformer that powered the datacenter - [http://www.datacenterknowledge.com/archives/2007/11/13/truck...](http://www.datacenterknowledge.com/archives/2007/11/13/truck- crash-knocks-rackspace-offline/)). All of Armenia was knocked offline when a woman cut a fiber optic line while digging for scrap metal. I'm not sure I'd trust the internet with any kind of life or death monitoring.

<comment><USER6> I could be way off base here since I only know what I saw on the site, but it doesn't look like this is life-or-death monitoring. It looks like its long term monitoring for later review by a doctor. It doesn't seem at all likely that they have someone monitoring the incoming data in realtime for heart attacks, that would be far better suited by hooking up the system to dial 911.

I think some IT person was freaking out that they had downtime and slightly exaggerated the life endangering part, they likely just lost information that may have been used in a future diagnostic manner.

<comment><USER7> Seems like it was real time monitoring. Otherwise why not just use the traditional Holter monitor, which is later reviewed by a doctor?

<comment><USER8> Apparently it only has a 24-48 hour limit which lowers the likelihood of finding the super rare event that they are looking for. Still they should have a local cache of a few days that they can sync when amazon gets back up at the very least. Typically though you would want to have a separate datacenter to handle the emergency situations like this though and a smaller local cache for local Internet outages.

</comment></comment></comment></comment><comment><USER9> Interesting quote from a company providing such services:

"The Remote Health Monitoring System is the IT backbone that supports HealthFrontier's entire portfolio of solutions, including the ecg@home™ and the microtel™/ecgAnywhere™. It captures data transmitted by the patient through USB, Bluetooth, or trans-telephonically. The RHMS™ then stores the information in a database, which can be accessed by the patient's doctor through a web-based interface. Benefits include:

Cloud computing: The RHMS is hosted on a network of servers across the US, which increases reliability and eliminates the need for a large capital investment in on-site hardware and maintenance."

<http://www.healthfrontier.com/rhms.php>

How many other companies provide home ECG monitoring which report over the web? I'm looking but having a hard time finding more. I will update this post as I do.

[UPDATE] Other Home-based ECG monitoring services:

Medtronic CareLink: [http://www.medtronic.com/your-health/heart- failure/device/ca...](http://www.medtronic.com/your-health/heart- failure/device/cardiac-resynchronization-therapy- defibrillators/carelink/index.htm)

[UPDATE] A more complete listing: [http://www.medcompare.com/matrix/1475/Outpatient-Cardiac- Mon...](http://www.medcompare.com/matrix/1475/Outpatient-Cardiac- Monitoring-\(Telemetry\)-Services.html)

<comment><USER10> My uncle owns a few elder care franchises and had me look into monitoring services as a funemployment project. So I've spent a bit more time with this than I'd like to admit...

The company I was most impressed with was <http://www.halomonitoring.com> . The device seems to be designed well and the monitoring services (online portal for caregivers or family members) are impressive, comparatively.

There's kind of a sea change happening with home health monitoring -- from the "I've fallen and can't get up" devices to more robust and interactive solutions. GE recently bought a company that provides institutional monitoring equipment and services.

Lemme know if you want the full report :)

</comment></comment><comment><USER11> Hmm... That would rather seem to be the monitoring company's own fault. Admittedly I haven't used ec2 for about 3 years, but I seem to recall there being an explicit disclaimer about how it wasn't supposed to be used for this kind of uptime-critical application. I want to say it even specifically mentioned medical stuff.

<comment><USER12> Agree. I'd avoid cloud for half as critical apps where I cannot CLEARLY picture where my servers are in a physical sense and how I can physically get a hold of them if shit hits the fan.

<comment><USER13> How do you physically get a hold of your servers if the gas main under them blows up or a tornado sucks them up and drops them a hundred miles away?

Servers are not physical things that you can just go get when there are problems. They are imaginary devices that can suddenly vaporize, leaving no trace. Plan your deployment accordingly, and you won't need to be writing emails saying that people are dying because your data center blew up. Your systems will silently switch over to some other data center and you'll file a claim with your insurance company to have the servers replaced on Monday morning.

In other words, "the cloud" had nothing to do with this problem. It could happen if the server was physically attached to you or in a abandoned missle silo with an army of armed guards.

</comment></comment></comment><comment><USER14> Elastic Load Balancer, anyone? I have no sympathy for this company. They deserve to get sued for this.

Yes, for something life threatening like this, EC2 is a bad idea, but they didn't even bother to take advantage of the geographic redundancy, much less something so basic as having backup AMIs ready in another AZ in your current region.

Of course, a whole lot of companies are learning this now.

<comment><USER15> ELB doesn't work across regions, the failure at EC2 affected multiple Availability zones in the Virginia Region. ELB might have helped, but it's likely that some people had all their "availabiliy" zones knocked out.

In fact, it's looking like all the automatic-failovers from people hosting on those data centers compounded the problem when everyone's scripts tried to recover at the same time – what was referred to in a previous article as a "bank run".

But yeah, if you're doing heart monitoring, you need to have your servers replicated across a wide geographic area.

</comment></comment><comment><USER12> This is where you wish you had a data center address and a cabinet number where you could pop in, grab your servers and move the heck out to another DC.

I wonder if this will get more companies to maintain a non-cloud, vanilla setup on some dedicated or collocated boxes.

May be we should have an annual day to bring down our primary servers and see how the backups do. The idea shouldn't be to confirm if everything works or not. It should be to determine what did work and did not work.

<comment><USER11> You know, that gets me thinking- wouldn't it be pretty damn slick if Amazon offered a way to plug your own hardware into the greater EC2 cluster remotely, so that if Big EC2 goes down, you still have copies of your machines running locally?

Maybe you could even timeshare your machines out for some other instances for a discount on your service, similar to how you can send solar power back up the power grid for an electricity credit. Then ec2 really WOULD be a cloud!

<comment><USER16> That sounds horrid. It'd mean my instances might be running on your ancient crap computer in a closet hooked up to dialup.

<comment><USER11> You could always add min spec requirements for machines to join, increase redundancy of instances ec2-wide, add quality tiers that control what machines your instances go on, etc.

Amazon could even simply benchmark your server and network connection, and compensate you as a function of that, which would drastically reduce the incentive to hook up old crappy hardware to the cloud.

It's really the idea of being able to run copies of your OWN instances locally that intrigues me though.

<comment><USER16> > It's really the idea of being able to run copies of your OWN instances > locally that intrigues me though.

No reason you can't already do this.

</comment></comment></comment></comment></comment><comment><USER17> I'd like to see more back story first. Medicine is about risk management. There are places where you need 1/100,000 reliability, and there are places where you need 1/1000, and there are even places where 1/10 is good enough. There are primary systems, and there are auxiliary systems.

Without any background, it is really tough to tell where this fits. You can't blame the people for making the wrong decision until you know what the risk profile for the failure is.

</comment><comment><USER18> Actual quote in the Amazon support forums from this company:

" _This not just some social network website issue, but a serious threat to peoples lives!_ "

<comment><USER19> I have a feeling (and I really really hope) this is a joke because of that sentence.

<comment><USER20> An event monitor isn't a life-critical system. Perhaps it messes up a study, and ticks off some cardiologists, but it's not as if somebody's implantable defibrillator is depending on EC2 being online.

</comment></comment></comment><comment><USER16> Later in the thread they say two instances are up but the third has most of the patients. If any of their patients die, they should be convicted of negligent manslaughter, not Amazon. Amazon explicitly warns that single instances can be lost. Any EC2 system needs redundancy, let alone a patient critical one!

</comment><comment><USER21> I recently had the "good" fortune of being at the receiving end of a sales pitch from one cloud hosting service (not Amazon). The pitch centered more around flexibility (ability to add CPUs, RAM, storage, network nodes) rather than reliability issues as the one EC2 is facing right now. All questions about reliability were brushed aside with blanket statements like "it's in the cloud" as if that was an end-all-be-all. After much prodding the sales rep admitted that the hosting was all in one location (low lying hurricane prone area) and if we desired redundancy we would have to mirror our apps at a different geographical location. As with any other product, don't believe the sales pitch. If it sounds too good to be true, it probably is. Always use redundancy specially for critical apps.

</comment><comment><USER22> I really hope this is someone's idea of a joke, but the nature of this person's other questions tends to make me believe no.

Sometime during the last couple of days, a lawyer was getting a lecture from IT on how the system works and is going to have a very, very bad year.

</comment><comment><USER23> I wish they offered some more detail on how important/life-threatening this is. Are we talking monitoring as in "detect signs of impending/occurring cardiac event and notify emergency services"? Or is this monitoring in a longitudinal sense, assisting physicians to look at trends in their patients? If it is the later case, is data stored on the device until it's uploaded, or is it simply lost if the connection fails?

Still, not really forgivable to be 100% AWS, but it's a very different story if this is primarily a recording device vs. a monitoring device.

</comment><comment><USER24> That's not even stupid, that is moronic.

<comment><USER25> Why? Who else would you suggest for providing this type of service?

Given the information we had a week ago, I can see how Amazon may have looked like the best solution for HA. _Their_ site never goes down, after all.

<comment><USER24> Well, first of all if they had used more geographical regions (I don't know what the official amazon buzzword), they shouldn't have real bad problems. I don't know about you, but I believe mission critical systems should be hosted in at least 2 physically different data centers. When it's life critical, this should be a no brainer.

Second of all, according to Amazon PR speak this failure should not be possible. Every person in IT worth their salt should know PR speak is _not_ to be trusted. Being reliant on AWS for your average business app is completely okay though. However, hosting apps which might endanger peoples lives on black box technology over which you have little influence is _moronic_ imo.

Last but not least I seriously question the privacy implications of this. Hosting parts of your medical app in the cloud is fine and I don't know the details of this app, but I wouldn't be happy to know that my medical history is stored by some third party I don't entirely trust with such sensitive data.

<comment><USER25> 1) Amazon's outages took down multiple "availability zones"

2) Amazon is HIPAA certified, which means they adhere to the industry standard for storing private medical data. In this sense, they are as good as any other company that such data is being passed around.

<comment><USER24> Yeah, but availability zones are _not_ geographical zones. Amazons outages were only in one datacenter.

Didn't know what HIPAA meant, but apparently they are certified for storing medical stuff.

</comment></comment></comment></comment></comment><comment><USER26> This is too incredible to be true. But if it is true then I would expect the company in question to be out of business quite soon. A company that put's a life critical system on AWS shows a total disregard for their patients well being.

<comment><USER27> I've seen things much worse than this with medical records and data.

Up to a few months ago we had a ASP.NET shared hosting customer that was doing some kind of data relay web service for medical imaging. No encryption. Patient data in full view on the server. No redundancy. Apparently it was used for outsourcing imagery review or something. If it didn't work doctors would have to drive in from home which slowed down the diagnostic process.

"Mission critical" on a $30 a month shared hosting plan. Very much not HIPPA compliant.

</comment></comment><comment><USER28> Isn't this a good start-up idea? A start-up that backup your website and deploy it to another hosting in case the one you are using is down.

<comment><USER29> How about a host-abstraction layer, so that you can deal with different providers through a uniform interface?

<comment><USER28> I'm actually thinking of that. You deploy to the service that take care of deployment, backups and transfer in down times. It would make up of it another kind of hosting company, though.

<comment><USER29> Yes, it would essentially be a hosting company with multiple providers. That in it self is a single point of failure, but at least it would give some insurance against outage of the more physical kind.

</comment></comment></comment></comment><comment><USER30> Just wow! How difficult can it be to have a backup dedi server with the DB mirrored running at some other provider to quickly switch to, just in case? Even many simple web sites have a config like that. Clouds have been around for decades, they are still new and may fail.

</comment><comment><USER31> Surely this must be criminal? This is one area where atleast 99.9999% uptime should be mandatory.

</comment><comment><USER32> Troll?

</comment><comment><USER33> This is just supplementary monitoring, not a true life-or-death situation. Everyone (the company involved included) is welcome to stop blowing it out of proportion any time.

</comment><comment><USER34> I see EC2 as a good piece of infrastructre to have as _part_ of a failover plan. But should it be even 1/3 the providers for servers? No.

<comment><USER35> Triply redundant hosting providers is really setting the bar high. Lot of 20/20 hindsight being put into play the last few days!

In my experience, small companies typically have _one_ hosting provider, off- site backups, and the probable but untested ability to bring up a fresh installation in a few hours. That's both common in the real world and good enough for most situations. It would get you through an outage like this.

<comment><USER34> It's a medical device. It's not a imposition in that case.

</comment></comment></comment><comment><USER36> Bullshit, linkbait post. After reading the whole thing, I would gladly spend karma to downvote this.

<comment><USER37> Are you referring to the link in the title? It is true that the company was hosting cardiac patient monitoring on EC2. This was not life threatening infrastructure, but that is not implied by the HN title. How is it linkbait?

The poster on Amazon's forum misrepresented the severity of the infrastructure and tries to backpedal later on in the thread. This is an example of someone using EC2 and fucking up, firstly for hosting production level infrastructure without backups, and secondly for misrepresenting the importance of the infrastructure in an attempt to get more technical support, making them look liable for some sort of medical malpractice.

The poster probably panicked when they realised their first mistake, and thought they were showing that they were trying to get back in control. I don't think the poster was totally stupid, maybe she/he didn't understand the risks of EC2, or maybe it wasn't even their decision to have no backups --- in which case they should have pressed harder at meetings or refused to continue to work on the project. And then they panicked. We can all learn something from this.

</comment></comment><comment><USER38> So, they experienced a Schrödinger situation...

</comment><comment><USER39> Those people should be prosecuted for utter incompetence.

</comment><comment><USER40> Epic fail for the company which is hosting on their kit. Whoever threw it on there is a total dick. There is nothing wrong with EC2 here. It's just not the right tool for the job.

If they are monitoring cardiac patients, they should, at least for non- critical people, have the instrumentation cache the data and send when available over leased lines.

If it is critical, it should be PROPER HARDWARE attached to the POTS network (like we have in the UK!) with multiple redundant networks over several distinct carriers and multiple monitoring stations.

It sounds like their product is a) crap and b) dangerous if used for critical care.

<comment><USER41> Ec2 is fine here. All systems have downtime. Its not having a backup system in place that's the problem.

<comment><USER40> Cardiac monitoring systems DO NOT have downtime believe it or not.

<comment><USER16> Bullshit. Leads come off, equipment malfunctions, patients fidget, and they definitely don't have redundant stuff on each patient.

<comment><USER42> I'm going to guess grandparent means that they don't include "downtime" in the contract. Which would be outrageous, BTW.

</comment></comment></comment></comment></comment><comment><USER43> If this story is true (and I have some doubts), you'd think this would have been a no-brainer to not try to keep critical data like this in the cloud.

But even for non-critical medical data, non-tech savvy medical folks (and this includes some physicians, although in general physicians are more tech-savvy than most managed care decision makers) are going to get into increasingly serious trouble if they don't think through these kinds of things very carefully.

Driven by electronic health care mandates and incentives, companies are pushing portable devices for medical data gathering (portable as in tablet, ie without local data store), and some groups are going to be knee-jerk tempted into buying into this without thinking through the ramifications of not owning your own data -- and by that, I don't mean vague marketing-speak hand-waving that "you own your data" through the simple mechanism of password-protected access to your patient's data living on someone's server farm.

By actually owning your patient's data, I mean strongly considering restricting your local practice to use of on-site media.

If you don't, you'd better have complete confidence that putting your patient's data on the web reflects a reasonable standard of care/privacy, that retention policies don't bite you in six months when your cloud provider goes out of business (or changes hands or farms out data storage or backup to some "economical" third-party), that you're going to have access to your data when you need it, that your cloud provider is going to audit access and changes to your patient's data and report the results of that audit to you accurately and regularly, that legal requests for data are not acted upon without you or your patient's consent, that backups are subjected to the same levels of security, etc. etc.

Electronic medical records are a good idea. It can be done right, as systems such as the Veteran's Administration's VISTA system have demonstrated. However, there is a fine line to walk here. Implementing EHR for the sake of government incentive, or for the convenience of insurance companies, or even the convenience of walking into an exam room carrying a light-weight tablet (which have their own disadvantages for data gathering) rather than a laptop with a hard-drive isn't going to cut it when you put your patients and your practice at risk of harm.

</comment><comment><USER44> who was the IT professional that decided to rely soley on the AWS cloud without any kind of "just in case" solution....with people's lives at stake? lol. I think I'm gonna subscribe to the hoax theory

</comment><comment><USER45> "We'll gladly agree to take care of grandma as long as you understand we only guarantee a 99% uptime. Good? Good. Sign here."

</comment><comment><USER46> This is the sort of service which should have a back up, its not reddit.

If it can go wrong it will go wrong.

</comment><comment><USER41> I hope no one dies because of this. Yet, the sad part is, it'll take someones death to get serious attention and help prevent this stupidity in the future.

Of course, then things will swing wildly in the other direction with massive legislation and regulation thats designed to get a lawmaker reelected more than it is to save lives.

</comment><comment><USER47> Wow, this is the worse idea I've ever seen since a freaking while. Poor him (or them) though.</comment>


Sadly, this is not The Onion - <AUTHOR> http://theon1on.com/ <comment><USER2> Science\Tech tab takes you to ICR "The Institute for Creation Research is a Creationist apologetics institute in Dallas, Texas that specializes in media promotion of pseudoscientific creation science and interpretation of the Genesis creation narrative as a historical event."

Sports takes you to a League of Legends page...

I'd say it's a joke of a website but not exactly a usable joke website with replay value like The Onion or Riveting News.

</comment><comment><USER3> Reminds me of fark.com, outrageous news stories that are sadly real.</comment>


Ask HN: What security mechanisms have been compromised? - <AUTHOR>

In the wave of recent disclosures of the NSA's intrusions, I'd like to know more about security/cryptography practices.  Most articles are geared towards one of two audiences: the consumer (make it simple), or the expert (discuss extreme details).  The technical details are hard to come by in a way that I can understand.
Many articles say, "If you are not an expert in cryptography, don't try."  Well, I'm not an expert, and I don't want to fake it.  I want to understand to the best of my ability, and make informed decisions.
I am a general developer, and I'm one of many who needs help understanding how to apply recent news to my development practices and production environments.
Can someone summarize what general developers should be thinking about moving forward, that we haven't been considering before (i.e. not password management). <comment><USER2> The first thing to understand is that the NSA hasn't (or hasn't proved to have) undermined fundamental security technology. There is no indication of a magic attack that breaks AES, just like no magic attack existed for DES before it. What has been disclosed is the massive scale upon which 2 things have happened:

1) The NSA's comprehensive subversion of information technology vendors into making it easy for the NSA to gain access to data. 2) The scale to which the NSA has been allowed to siphon that data from the most optimal places for an attacker.

One of the first things I point my developers at when they ask about crypto is [http://www.daemonology.net/blog/2009-06-11-cryptographic- rig...](http://www.daemonology.net/blog/2009-06-11-cryptographic-right- answers.html). Nothing in there has changed. However, you probably want to assume that if you're using, say, the Microsoft CrypoAPI or Java JCE that you cannot be assured that a mechanism to access your data isn't present.

<comment><AUTHOR> So all the attack vectors the NSA has used to date are based upon backdoors (voluntary or otherwise) to existing vendors?

Something I've been confused and/or mislead about is that if root/CA ssl certificates are compromised, then all derivative ssl certificates are also compromised. Is this true? Are these some of the companies the NSA has 'backdoors' with?

Sorry, I'm not even sure about the terminology here -.-

<comment><USER2> Yes, what we _know_ is that the NSA has compromised many vendors, including it seems some of the CA vendors. So it's possible that a CA could issue the NSA a certificate that could fool you into thinking an NSA surveillance node was a valid site, or that a bit of software was written by a legitimate vendor and is safe to run. The devil is in the details, of course...if the goal is to have a valid, signed Microsoft key, you really need the Microsoft CA to sign it, but 1) the vast majority of people don't check so close is often good enough, and 2) I personally think Microsoft would cave faster than Verisign, so...

And you are correct: if a CA has disclosed their root signing certificate, then the NSA could issue seeming legitimate certificates for pretty much anything.</comment></comment></comment>


Spyce Kitchen, a robotic chef built by four recent M.I.T. grads - <AUTHOR> https://www.newyorker.com/magazine/2018/04/16/when-a-robot-makes-you-dinner <comment><USER2> It's just another automatic wok. There are many companies making those in China.[1][2][3][4] And those are just the pan style. The simpler rotating-drum machines are easily available on Alibaba.[5] Those guys didn't do their homework to see what's available.

The home-sized ones often take a cartridge of little plastic bins preloaded with the ingredients and coded with the instructions. Just slip one of those in the slot, push start, and get a good hot meal.

You want to compete with China, you need to know what's already been done there. Remember those "Bodega" clowns? They apparently didn't know that much more advanced automatic convenience stores already exist in China.

[1] [https://www.youtube.com/watch?v=0HkGRzzsKH4](https://www.youtube.com/watch?v=0HkGRzzsKH4) [2] [https://www.youtube.com/watch?v=jCTv-4sFt_s](https://www.youtube.com/watch?v=jCTv-4sFt_s) [3] [https://www.youtube.com/watch?v=8NTIciISVPA](https://www.youtube.com/watch?v=8NTIciISVPA) [4] [https://www.youtube.com/watch?v=-S-- wwu4S-w](https://www.youtube.com/watch?v=-S--wwu4S-w) [5] [https://www.alibaba.com/showroom/automatic-wok- machine.html](https://www.alibaba.com/showroom/automatic-wok-machine.html)

<comment><USER3> Well, no, it's not just an automatic wok - there's a consumer experience around an automatic wok. Integrating everything so that there's no human involved whatsoever is a bit more difficult than ordering an automatic wok from Alibaba. If you're trying to serve freshy-cooked meals from a vending machine, there is so much more going on than just the heating elements.

Just to pick one: the supply chain is a real issue. Getting fresh ingredients into the machines, keeping them running, performing maintenance... all of that requires a well-tuned supply chain, knowledge of food sources, etc., especially since Spyce is targeting an upscale "fast-casual" (~healthy) demographic.

As a disclaimer I was pitched by this team in 2015-2016, and was pretty convinced that they weren't facing much local competition.

<comment><USER4> So they have to buy an automatic wok on alibaba, and then do the exact same things every other fast-casual restaurant already does?

</comment></comment></comment><comment><USER5> People seem to forget that nearly all frozen meals and frozen pizzas are all robotic made by the many millions per day. Just by very expensive, large and high speed robots.

The innovation is now trying to make robots that are more flexible, smaller and low volume food production while not being super expensive.

<comment><USER6> Applebees could be all cooked by Robots also since all their food is microwaved frozen food. (I tell friends if you can't smell (edit) cooking outside the restaurant they are just a microwave kitchen.)

Fast food could also be run by robots fairly easily. I am imagining in 15 years most places will have robots doing the majority of cooking in restaurants. They won't spread disease, make food consistently, won't call out sick nor require an hourly wage.

<comment><USER7> When you can't "smell cooking" (as I assume you meant to write), it means their HVAC works, and if you can't "see cooking" (the other reasonable option?), it means they know how to put up a wall. Your friends should be taking you with a grain of salt.

"All their food" at Applebee's is not "microwaved frozen food"; I know plenty of people who got their start as cooks and chefs there. Something like three- quarters is made in-house and you'd have to be blind and unable to feel your tongue to not be able to tell a microwaved steak.

<comment><USER6> Looks like Applebee's is actually starting to cook items. I guess public pressure has changed their ways. Good for them. They absolutely were the king of microwaved food in chain sit downs for decades.

Appetizers are all frozen and pre-packaged they just deep fried at almost all chains.

Heck I worked at Ethan Allen Inn in Danbury CT a LONG time ago and all the meals were frozen and prepared in France and shipped over. Easily $75 to $125 per person in the 90s.

Smell outside a restraunt is certainly a true statement. No HVAC (A/C or Heater) is going to filter the kitchen's vent. Tell me you can't smell the difference between Burger King's fake grilling and McDonald when your outside of them? Same thing with restaurants. The one's that microwave a ton will

<comment><USER8> I just ate at The Modern in NYC the other day. The Modern is a Michelin star restaurant. I didn't smell cooking. Half the dining experience at Michelin restaurants is all about tightly controlling the inflow of stimuli to your senses. No good restaurant would want you to smell someone else's seafood cooking while you start on desert. Is your experience limited solely to to restaurants with poor HVAC?

<comment><USER6> I stated specifically outside not inside. You smell cooking from outside since kitchen's are vented. Now in NYC sometimes the vents are on top of a 25 story building and that beautiful NYC post winter stench might cover it up.

If a restaurant has a ton of items on the menu I guarantee you that most of that is just prepared food that is microwaved.

Seems like people are mad that I believe that most food in restaurants are not cooked.

<comment><USER7> I don't think people are "mad". But you have a track record of saying trivially disproven, unsubstantiated things on HN and you backtrack poorly from them, then you sprinkle in weirdly fixated antagonism like "NYC post winter stench". It's bad posting, and it's wrong besides--the gap between "they don't cook anything" and "they fry frozen appetizers and cook everything else as anyone else would" is not so small that you can handwave it away with "lol people are mad". I mean, hell, Applebee's has had apply-fire-to-food line cooks for _twenty years_ or more. I knew kids in high school who worked there (and we'd go there because we got a discount).

(And if there's any wind at all, modern roof-mount kitchen venting will ensure you don't smell much of anything if there's even moderate wind.)

<comment><USER6> > I don't think people are "mad". But you have a track record of saying > trivially disproven, unsubstantiated things on HN and you backtrack poorly > from them

I either state my person experience from many years ago. (Don't need to present a research link) OR I present my research. Sorry you don't find me as a positive addition on HN.

I was stating my personal experience of working at a restaurant that had their meals prepared in France was frozen and shipped to America. The preparation was boiled in bags or microwaved and got high dollar for the meals. That is my personal experience.

Long time ago most chains like Applebee's and Tuesday's meals were prepared hours, days or weeks before a person would eat them and either they were boiled in a bag, microwaved or deep fried. This still happens more than people know. That is my statement.

Here is an article on expensive French Restaurants use of pre-pared food.

[https://www.telegraph.co.uk/news/worldnews/europe/france/728...](https://www.telegraph.co.uk/news/worldnews/europe/france/7285770/Majority- of-French-restaurants-using-ready-made-factory-food.html)

So I guess me saying that if I can't smell a kitchen cooking food it probably is making pre-pared meals. I could also state that if the menu has hundreds of items they are also pre-pared meals, but to you that is poor posting?

I much rather have a few option that are fresh and that is what the OP Restaurant is doing with robots and one human at a garnish station. Most of America's restaurants do not use fresh food or prepare your food that day. Applebee's has gone out of their way to change the way they make food.

"Today, the country's largest casual dining chain lights up 2,000 new wood- fired grills for a revamped menu with steaks that Applebee's hand-cuts on the premises. Amid the barrage of price-driven industry promotions, Applebee's thinks its upgrade to USDA Choice beef, along with the stacks of logs outside restaurants and the aroma of wood smoke inside, will pique consumer interest. That's something the chain needs right now: In the last fiscal financial year, same-restaurant sales were flat, and this year, Applebee's expects sales to range from a negative 2 percent drop to a 2 percent gain." [http://www.adweek.com/brand-marketing/applebees-bets-big- rel...](http://www.adweek.com/brand-marketing/applebees-bets-big-relaunching- brand-around-wood-fired-steaks-171477/)

<comment><USER9> This is 100% correct. I seriously can't believe people are hating on you. Too many rude comments!

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I find it interesting how good the top schools are at making sure they get credit for things. I often read "Harvard scientist..., MIT grads, Stanford..." in headlines. You rarely read "University of Minnesota" (just a made up example) so the casual reader may think that Harvard, MIT and Stanford are the only schools that do interesting things.

And it really works. At a startup I worked at we had a guy from MIT and whenever the VCs talked to to the low ranks they inevitable ended up talking to him. And no, he was not the best engineer. Not even close.

<comment><USER11> It's name dropping, appealing to people who are easily impressed.

<comment><USER12> This. Regardless of the school name you prefix it with "graduates designed" conjures up mental imagery of bolted assemblies with fasteners you can't actually get a wrench on and massive stamped parts with a size tolerance of whatever the default in their cad software was"

</comment></comment></comment><comment><USER13> Nice to see them getting coverage, we were at the same startup incubator (Greentown) before we both moved on to larger offices. I can attest that the food this machine makes is, in fact, tasty.

<comment><USER14> The description in the article suggests that the machine does not actually make any of the food, it just measures and dispenses pre-cooked items into a bowl? So it's a glorified automatic dog feeder?

<comment><USER13> No, the machine actually does do the cooking. There's an induction based heater that also mixes the food. Different sorts of raw vegetables are added by a hopper in a sequence that depends on their cooking time. Finally the mixer/cooker dispenses the meal into a bowl.

</comment></comment></comment><comment><USER15> Here's a post from two years ago that has a video and some photos[1]. Not sure what warranted a new article from the New Yorker (maybe a product release?).

[1] [http://www.businessinsider.com/mit-students-invented-a- robot...](http://www.businessinsider.com/mit-students-invented-a-robotic- kitchen-2016-4)

</comment><comment><USER16> I've been predicting robotic fast food for a decade now. And it's here! By cooking with no human hand ever coming into contact with the ingredients or utensils, clearly a health benefit is accrued. And by steam-cleaning the cooker periodically, quality is improved.

I'd envisioned a somewhat different robot. I thought the ingredients could be tube-delivered like caulking guns, on a rotating 'tool carousel' so you could cook different recipes by selecting and timing. And process vertically so you avoid most 'conveyor belt' issues. Finally do it as drive-thru with automated ordering (touch screen/phone app) to eliminate the rest of the human factor.

The result should be good quality, fast food at a radically cheaper price.

<comment><USER17> > no human hand... clearly a health benefit

That is a non sequitur. The most dangerous illness associated with fast food (poor nutrition aside) such as E. coli[1] and Hep A[2] are most readily attributed to ingredient suppliers, not improper food handling.

[1] [https://www.cdc.gov/ecoli/2015/o26-11-15/index.html](https://www.cdc.gov/ecoli/2015/o26-11-15/index.html)

[2] [https://www.cdc.gov/mmwr/preview/mmwrhtml/mm](https://www.cdc.gov/mmwr/preview/mmwrhtml/mm)

<comment><USER16> And who handles the ingredients improperly? Doesn't refrigerate them sufficiently? Uses expired ingredients? Fallible humans. Lets remove them from the equation.

<comment><USER18> Robotic slaughterhouses would still have problem keeping fecal matter out of meat. The best way of preventing most food illnesses is radiating the food, but our irrational society won't go for that.

<comment><USER19> Irradiation does have issues of it's own, like making things taste funky [0]

[0]: [https://www.sciencedirect.com/science/article/abs/pii/S03091...](https://www.sciencedirect.com/science/article/abs/pii/S0309174008002337)

</comment></comment></comment></comment></comment><comment><USER20> I'm surprised Moley ([http://www.moley.com/](http://www.moley.com/)) didn't get a mention. I'm super excited about robotic food preparation, especially in the case of consumer facing robotics where its a unit in your own kitchen.

With that said, from the robotics progress I've seen/studied, more fundamental robotics progress needs to be made first. The approaches used right now are just not durable/reliable enough for mass market adoption. Best of luck to that team though.

<comment><USER21> The price of $15k according their YouTube video is ridiculously low. Decent robot arm costs you $5k alone. Not sure how they will plan to make some profit even buying parts in bulk.

<comment><USER22> $5k is on the low end. The demo kitchen they did was with 2 UR5 robots, list price somewhere around $20k each. They put 2 5 finger hands on the end, which probably cost at least the same again each. I'd bet you'd be getting well towards $75k (or maybe even significantly more) just buying the components.

</comment></comment></comment><comment><USER23> Wow, really wanted a picture in this article. Will have to read it later to learn what it looks like.

<comment><USER24> There's a picture in the social share. Check out @spycefoodco on Facebook or Twitter to see!

<comment><USER25> Why not just link to the picture instead of pandering your social media accounts?

<comment><USER26> I went to their Twitter and looked for the picture. I assume this is it. I don't see anything else: [https://pbs.twimg.com/card_img/983333636975054848/siPS_w5d?f...](https://pbs.twimg.com/card_img/983333636975054848/siPS_w5d?format=jpg&name=600x314)

</comment></comment></comment></comment><comment><USER27> >conceived as an engineering solution to every hungry college student's gripe—where to get good, cheap food fast. (It's the same market that the meal- replacement drink Soylent is after.)

Pretty broad definition of "good" if Soylent fits in there.

</comment><comment><USER28> How on earth is there not a photo to go with this?

<comment><USER17> [https://www.youtube.com/watch?v=yc8D-CnDMiE](https://www.youtube.com/watch?v=yc8D-CnDMiE)

<comment><USER24> That's an old video. Our new robotic kitchen has been completely redesigned and reengineered since then. There's a photo in the social share...check out @spycefoodco on Facebook or Twitter to see the image.

<comment><USER17> Is it so hard to give us a link to the video?</comment></comment></comment></comment>


France introduces a new VISA for entrepreneurs and startups - <AUTHOR> http://blog.migreat.com/2014/02/20/france-introduces-a-new-set-of-visa-for-talents-entrepreneurs-and-startups/

<comment><USER2> What is the current tax situation in France for an individual running a lifestyle business? (Ie: Earns enough to support the founder, every other task contracted out)

<comment><AUTHOR> I think your get a few years 'free', then it goes from 25% to 32% something. I'm lacking references here but that's what I recall</comment></comment>


Ask HN: What's your favorite book that almost nobody else knows or talks about? - <AUTHOR> <comment><USER2> Illusions: The Adventures of a Reluctant Messiah. By Richard Bach.

Well written, funny, thoughtful.

</comment><comment><USER3> For Want of a Nail by Robert Sobel

</comment><comment><USER4> Armor - John Steakley (Sci-Fi)</comment>