Chrome Is The New C Runtime - <AUTHOR> https://www.mobilespan.com/content/chrome-is-the-new-c-runtime <comment><USER3> He's talking about using bits and pieces of Chromium's infrastructure in other programs, but didn't address open source licensing at all. I haven't looked at it myself, but according to Wikipedia, Chromium's source is licensed under: "BSD license, MIT License, LGPL, MS-PL and MPL/GPL/LGPL tri-licensed code, plus unlicensed files". This is all fine, but anyone using this code needs to make sure they understand what license(s) the code they are using is under and what the terms of those licenses are. Just because it's open source doesn't mean you can just do whatever you want with it; even less restrictive licenses like BSDL might have conditions like the advertising clause, and you should always be aware of any copyrights in the code and be sure to preserve them.

That said, I'm sure the Chromium source is a great resource- just a strange and important omission from the article.

I would also suggest that anyone looking for a platform-independent runtime check out APR (Apache Portable Runtime): [http://apr.apache.org](http://apr.apache.org). It's lower-level than some of the Chromium libraries mentioned in the article (it would be equivalent to the "base libraries" block in the "Chrome Development Platform" figure), but sometimes that's all you need. Plus, it's already designed as a library for other applications to use, there's no need to repurpose anything like you might have to do with the Chromium sources.

<comment><USER4> I don't see how it would be different from using any other MIT-licensed code in your project. The Apache License doesn't seem any less restrictive than MIT at first glance?

Edit: I assumed the entire codebase was multi-licensed, it looks like you're saying that different parts have different licenses, which does sound like a headache.

<comment><USER5> The core Chromium codebase itself uses the same license (a BSD-style license). Chromium itself uses certain other third-party libraries that have different licenses.

</comment></comment></comment><comment><USER6> As someone not at Google, but who's re-used multiple parts of Chromium (as described in the article), the code (especially the stuff under base/) is possibly the best documented large-scale, open-source C++ codebase I've seen.

<comment><USER7> I haven't worked with Chromium, but the main C++ code-base at Google is like this for the most part too (especially the core stuff).

The C++ culture at Google is amazing, and proof that large-scale C++ can actually be really nice if you stay within best practices. It takes a lot of effort and experience from a lot of knowledgeable people to craft these practices, but thankfully Google publishes its C++ style guide ([http://google- styleguide.googlecode.com/svn/trunk/cppguide.x...](http://google- styleguide.googlecode.com/svn/trunk/cppguide.xml)) so that everyone can reap the benefits of this.

<comment><USER8> Avoiding exceptions is a worst practice. The guide even admits they're only doing it because they're so far beyond a critical mass of exception-unsafe code that they've lost hope of solving the problem.

If the profession ever wants to produce anything reliable in C++, one of the first things that needs to happen is to start treating all unsafe legacy code like toxic waste, marking it clearly, handling it carefully in isolation, and disposing of it with prejudice as soon as possible. I don't ever expect to see this, which is partly why I switched to languages that try to handle failures and mistakes gracefully.

<comment><USER9> > Avoiding exceptions is a worst practice

You say this very matter-of-factly. Many (myself included) do not believe in exceptions, and in C++ where they are poorly implemented, think not using them is _best_ practice.

I would summarize, but this 10 year old article I've seen on HN a dozen times does a much better job than I:

[http://www.joelonsoftware.com/items/2003/10/13.html](http://www.joelonsoftware.com/items/2003/10/13.html)

Error handling is essential, but exceptions are far from a perfect solution. The Linux kernel is an impressively complicated, and robust piece of software and they get along just fine without exceptions. One just needs to be vigilant when handling errors.

<comment><USER10> > The Linux kernel is an impressively complicated, and robust piece of > software and they get along just fine without exceptions.

The amount of error-unwinding goto spaghetti, ERR_CAST/IS_ERR/PTR_ERR/... and all the bugs coming from it is not "just fine".

<comment><USER11> But how much of that would be solved by exceptions without convertng to a fully garbage-collected language?

<comment><USER10> Dunno.

Passing -ENOMEM 5 layers upwards stops being fun very quickly.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> As an example of this type of Chromium library re-use, Firefox and Firefox OS use the Chromium ipc library for messaging between the main UI process, plugin processes, and content processes (in Firefox OS or in Firefox with the experimental multi-process mode enabled).

[https://hg.mozilla.org/mozilla- central/file/tip/ipc/chromium](https://hg.mozilla.org/mozilla- central/file/tip/ipc/chromium)

[https://wiki.mozilla.org/IPC_Protocols](https://wiki.mozilla.org/IPC_Protocols)

<comment><USER13> Yes, we (OP) use the ipc library too. It's a great asynchronous IPC mechanism which works across platforms.

</comment></comment><comment><USER14> Contrary to many, I'm profoundly concerned about the culture around Chrome development, and the attitude here is indicative of that. There really is a belief by those that work on it, or have worked on it, that it's much better than it really is, when what actually happened was it was much better than the competition at launch, but now there isn't much between them at all. This notion that Chrome is decent on mobile is still absolutely bizarre.

The more long term concern is the way it's creating a sort of development priesthood. You have the chosen few that are making decisions and developing the platform largely in secret and pushing the code out to mere mortals from on high. This wouldn't be so bad, except the decisions are not made in the interest of the mortals, but of the priesthood and the strategic interest of their Googly God, and they exhibit a level of contempt for the mortals by disallowing them direct access to things such as the components so lauded here. In an ideal world most of what's mentioned should not be in the C++ layer, but in JS, except the hooks to provide that are simply never going to be exposed (at least in the near term because of the JS performance it would be technically dubious), leading to this them and us situation where they get to develop all the low level stuff, and no one else does, especially if any patches would conflict with the interest of their lord and master. They simply aren't dogfooding their entire development stack. Mozilla, for all their flaws, do actually engage the rest of the world in what they're doing, and early Java, while slow, did have a relatively small JVM with an enormous class library which was mostly written in Java itself. You could argue Sun's error was to Swing too far in the other direction by insisting on being all Java where at the time it really should not have been.

So yes, sadly I've come to view many Chrome devs as smug self serving slightly delusional types persistently confused that the masses don't acknowledge their brilliance, and this piece is evangelism to try and persuade us of this. The truly scary part of this is they just might be right to have this point of view in order to prevent what happened to Android where groups outside succeeded in nullifying many of the expected advantages of a standard open mobile platform, and I suspect it's this which has led to their open but closed approach to things.

<comment><USER15> I read an article about using core Chromium components as a cross-platform library that comes complete with a build system. What did you read about?

</comment></comment><comment><USER16> Im using the chromium codebase to build a sort of netxgen "browser" (not web browser).. but more akin to a application platform with p2p in mind (and other crazy ideas). While the idea proposed by the author may sounds cool, i think chromium is a huge codebase to be used like the author says so trivially..

Its ok; if you need multiprocess ipc + net + actor-based thread concurrency + gpu compositor + webkit.. (like i do)

But, dont know if it worth the trouble otherwise..

For instance, it takes a very long time to compile everything, it takes long to debug (the final chrome binary with debug symbols end with 2G.. all loaded in the heap) and you got a big codebase to know about.. so use it with care and in need.. otherwise you will waste your precious time trying to kill a fly with a canon

<comment><USER17> This is the argument that resonates with me the most. Unless you're already intimately familiar with the codebase and build system (with all their attendant quirks), it could consume a huge amount of time and effort to tease apart the stuff you need from the vast chromium codebase.

For the record, I'm working on a new C++ project where I ended up picking up small (very small) pieces of chromium codebase with the rest being in conservatively written C++ (but not as conservative as described in google code-style guide). In general, I'd say /base and /threading libraries are useful sources to raid at the beginning of your project. These are high quality implementations of basic things most programs would need and somewhat easier to disentangle from the rest of the code.

<comment><USER16> i think theres a safe threshold someone can use as a rule, before things get too much complicated..

first: know how to use gyp and ninja build tools then.. you can embed: base, crypto, net and ipc..

Anything more than that, things start to get more complicated.. for instance: if you want to use the 'ui'.. then you have to embed 'cc' and 'gpu'.. and to work right.. you will need the browser process + the gpu process.. and will have to create a custom-renderer, or adapt the renderer process to yourself.. so now you will realize you are doomed!

The other Chrome components past the ones i've pointed out, will need to use the IPC and multiprocess logic from chrome.. so that part should only be used in very specific scenarios..

Edit: i think the 'cc' module, the chrome compositor, also has some sort of autonomy from the multiprocess IPC core.. so could also be used with: base, crypto, net and ipc

</comment></comment></comment><comment><USER18> I'm posting this from a Chromebook Pixel, which I use for all of my development. No crouton, just stock ChromeOS.

This movement is really interesting to me. If I could clone myself, I'd be working on an exokernel in Rust that just exposes a V8 VM, and uses a DOM implementation as the native drawing interface. Processes == tabs...

Of course, there's higher level work that needs to be done to expose more of the machine in JavaScript. Check out [http://extensiblewebmanifesto.org/](http://extensiblewebmanifesto.org/) , signed by Google, Mozilla, and W3C TAG members, as well as #extendthewebforward on Twitter.

<comment><USER19> Have you any experience with VNC clients on ChromeOS? If so, what's the performance like?

I found the following, which mentions Chrome Web Browser, is that equivalent for the sake of applications? [https://chrome.google.com/webstore/detail/vnc- viewer-for-goo...](https://chrome.google.com/webstore/detail/vnc-viewer-for- google-chr/iabmpiboiopbgfabjmgeedhcmjenhbla?hl=en)

<comment><USER20> A lot of VNC Viewer for Chrome is just the standard RealVNC stuff compiled into NaCl, so you should find the performance to be pretty good. If you've used any of RealVNC's mobile apps you should have a good expectation of what you're getting (except better because you might be using a wired connection & a desktop computer has more power than a mobile device).

</comment></comment></comment><comment><USER21> XULRunner is almost 8 years old now, it was invented for the same purpose TFA uses Chromium but it's actually documented:

[https://developer.mozilla.org/en- US/docs/Mozilla/Projects/XU...](https://developer.mozilla.org/en- US/docs/Mozilla/Projects/XULRunner)

<comment><USER22> XULRunner is a good option to build HTML or XUL based apps. We were looking for a great cross platform library for native (c++) apps. With support for OS specific features.

<comment><USER23> > We were looking for a great cross platform library for native (c++) apps.

Isn't that what Qt is for, with the added bonus that it's what Qt _is actually for_ and thus e.g. documented and supported?

<comment><USER5> Qt is a higher-level application dev framework with UI support (like MFC but cross-platform). We were looking for lower-level constructs - especially in the networking and P2P areas.

<comment><USER24> I know that you are an ex-chrome dev so this is all moot as Chrome is the code you knew when you started, but really that is exactly what QtCore + QtNetwork is for. You don't have to use any of the GUI bits when you use Qt if you don't want to. I have written many "Qt" applications that were console apps simply to use the built in capabilities.

Edit: in fact just to highlight how similar it is, the way that QtWebKit works is that it is built on top of these modules in a [hand wavy] similar way that blink is built on top of the chrome development platform (I have hacked on Qt, WebKit, and Chrome).

</comment></comment></comment></comment></comment><comment><USER25> Just a heads up, Web of Trust has this sited rated very poorly[1], ostensibly for spam. As a result, any users with the Web of Trust browser extension installed are shown a Big Scary Warning that they must click through before seeing the site's content.

The warning is based on one review, and doesn't seem accurate in this case, so this might be something to try to get resolved.

[1] [https://www.mywot.com/en/scorecard/mobilespan.com?utm_source...](https://www.mywot.com/en/scorecard/mobilespan.com?utm_source=addon&utm_content=rw- viewsc)

<comment><USER13> We asked them to review it a few days ago. It's from before we owned the domain. Thanks for the heads-up.

</comment></comment><comment><USER26> Chromium is _huge_. If I just wanted to use the HTTP library (with tls and spdy) then how would I build just that, and cleanly integrate the build into my own project in a way that won't require constant revisiting every time I update my chromium sources?

<comment><USER5> You would only link with the net library (and its dependent libraries - <USER2> base and crypto)

<comment><USER24> And what about source and binary compatibility. What are the current guaranties? (his second question)

Edit: to be clear after you get your app up and running with the current version how much time has to be spent on ongoing maintenance down the road?

<comment><USER13> You build the libraries and link them into your libraries. If you maintain a cadence of updating your Chrome checkout every month, you will mostly be OK (though this can vary, of course).

<comment><USER27> Why not just stick with a stable version for a while? Updating every month sounds like a huge headache.

<comment><USER28> Because the Chrome team makes huge, breaking changes to their code APIs with breathtaking rapidity. If you don't update that often, it'll just get harder and harder and harder to do.

Google can do this (in general) because they have a single source tree (although IIRC Chromium isn't actually part of that). Point is: when you only care about your own code, as the Chrome devs do, third parties are in a really bad place to try and stay current.

</comment></comment></comment></comment></comment></comment><comment><USER22> Hi all,

I'm the author of the post. Happy to answer detailed questions on using Chromium as a Dev platform. Any suggestions for a follow-up post?

<comment><USER29> Simple sample app would be great for the next post.

<comment><USER30> I second this. Would love to see an actual app skeleton that links with Chromium's sources.

</comment></comment></comment><comment><USER31> Judging from the number of dependencies I think it'd be more fair to say Chromium is the new Boost.

</comment><comment><USER32> Chromium, Gecko and Webkit codebases are huge, they are hard to compile. They are optimised for use in the browsers and nothing else. They are not universal runtimes yet! I like that idea but please don't make it sound like chromium runtime is ready for everybody to use for their projects.

<comment><USER5> I'm not sure what you mean by "optimized for use in browsers". I can't speak to the other 2, but Chromium is basically a vast collection of C++ cross- platform libraries that can be used in many applications.

<comment><USER24> While a class/library/etc might be used by chrome and all of its many users, it was originally designed to solve an issue for the browser and it might have a horrible api for anything else or much more likely be completely missing api that other applications would not only want, but need.

</comment></comment></comment><comment><USER33> Recommending Chrome is a bit like recommending bionic when everyone else is enjoying (e)glibc?

The Chrome runtime has some good libraries but using that over say Qt really only makes sense if you're a (former) Chrome developer. For everyone else it's just needless pain.

<comment><USER34> No, please. Bionic is not a replacement for (e)glibc, its a small subset of a libc for Android. Now Musl, thats a real usable implementation.

</comment></comment><comment><USER35> Sounds like Chromium might be the successor to APR, the Apache Portable Runtime. I believe that the authors of Chrome consciously tried to provide functionality that replaced APR, presumably because of their multiprocess model.

</comment><comment><USER36> This is what mod_pagespeed/ngx_pagespeed does. We need many basic things and we use the Chromium libraries for that.

(You could say that's because we're kind of like a browser, but we don't actually use the most browser-like components of Chromium. We do need an http(s) fetcher and html/css/js parsers but the Chromium ones aren't a good fit for our usage.)

</comment><comment><USER37> With the same reasoning you can use nginx as a C runtime.

</comment><comment><USER38> Chrome is more like Java or .NET runtime than C runtime. You can build full blown apps as Chrome packaged apps. Google has not polished it very well. If done well, developers can use it to build apps that run on Windows/Mac/Linux without change.

<comment><USER39> It CAN be like Java or .NET if you build on top of it with packaged apps, or it can be like the new C runtime if you statically compile bits of chrome in to your application, as a 'stack' that you build on, which is what the author is describing.

</comment></comment><comment><USER40> While looking for cross-platform (iOS and Android) networking and security resources, Google kept giving me references to the Chrome codebase. Having compiled Chromium for a homebrew Chrome book (and tired of copying settings between two separate codebases), I'm going to try this. :)

A big shout out to the author of this stack overflow post, where I first confirmed that it might indeed make sense to develop function-based middleware in C or C++ and share it between iOS and Android to bridge the low and high levels of your app: [http://stackoverflow.com/revisions/5234868/2](http://stackoverflow.com/revisions/5234868/2)

</comment><comment><USER41> This is interesting. Ideally, if the rendering and audio parts are of high performance enough, it could be used as platform abstraction for game development.

<comment><USER42> Have you seen the Epic Citadel demo? It's pretty amazing: [http://www.unrealengine.com/html5/](http://www.unrealengine.com/html5/)

<comment><USER43> Have you seen original real player it's pretty amazing tech too. Except that it's forever ago. Just epic citadel vs when they actually coded that demo.

</comment></comment></comment><comment><USER44> Interesting, it seems kind of like the scenario where the "web stack is the new GUI", with desktop projects like Light Table being built on Node-Webkit. You're reusing browser infrastructure for native apps.

What other alternatives are there? Apache Portable Runtime?

</comment><comment><USER45> To the author: I think you should 'Find and Replace' all (except a few) occurrences of 'Chrome' to 'Chromium' in your article.

<comment><USER5> Yes, Chromium would be the technically correct usage, I used Chrome as it is the more familiar term.

</comment></comment><comment><USER46> But otherwise I still see no reason to use something designed for a specific use-case over something which is designed for general development. Though if it is a proprietary app it might work because there people seldom care about using latest version of libraries, sad as it may be.

Further, I really don't like the idea of adding a third-party draw API to a language standard. Dunno if we really want to blur the line between language and library.

</comment><comment><USER47> There is a lot of code in Chromium that covers ground that Qt does not and there are good reason to prefer permissive licensed code for your project that you can directly modify. Qt is a fine library but hardly the be all end all of what is out there. ISO C++ committee recently posted to the Cairo library and C++14 might have a standard 2D based on it. There is a lot of room for different projects

</comment><comment><USER48> Thanks for bringing this to limelight

Just started experiencing this early on this week via Node Webkit, it is just awesome what NW with Chromium brings to the table.

The first thing that came to my mind is that this should have been there 15 years earlier through Java/Embedded browser. However the powers of the time (read IE) were not interested/even actively blocked embedded browser usage.

</comment><comment><USER47> sigh people just cant stop using something just because its "cool", rather than what is right!!!

</comment><comment><USER49> So you write your mobile apps in C++? and you can't take advantage of iOS or Android STL?

<comment><USER5> Libraries like STL (which Chromium code uses extensively) and boost are lower- level. Chromium has much higher level abstracts.

<comment><USER46> The reason to use specialized code is because your needs match them. Not everyone wants to bother linking to a general purpose library and adding a dependency when you can reuse some specific code and be done with it. Also, language standards cover libraries extensively and this is hardly a new trend and once it is standardized, it can no longer be considered third party. This has already happened quite a bit with C++11 which standardized many commonly used portions of the Boost library. Nevertheless, I mentioned the standardization aspect not to debate about it but to use it as an example to point out competing projects.

</comment></comment></comment><comment><USER50> That's how NSPR was/is used by projects other than Netscape/Mozilla, too. Producing such a library is generally an unavoidable consequence of writing a popular multi-platform application -- unless you reuse someone else's.

</comment><comment><USER47> Idea of adding a third-party draw API to a language standard is not a good idea

</comment><comment><USER51> it'd be fine if the libs were actually libs, with a documented api (you know, in man, it's nice).

that's not the case tho, and that's why its a blog post and not something everyone and their dog uses.

</comment><comment><USER52> I think Qt is a much lighter and feature rich alternative. Light because you only need and see the Qt dlls and feature rich because the things described are already in Qt.

</comment><comment><USER53> No, it's not.

</comment><comment><USER54> Can I use the p2p libs to make some bitmessage-like app, using the bitcoin protocol to spread data ?

</comment><comment><USER55> C/C++ web stack is really needed for performance reasons.. good project I would say....

</comment><comment><USER56> I for one welcome our new C Runtime.

</comment><comment><USER57> oh just fuck this entire idea

<comment><USER47> I really don't like the idea of adding a third-party draw API to a language standard

</comment></comment><comment><USER58> "Person-hours".</comment>


Bionic Bodies: Why the Future for Quadriplegics Looks So Bright - <AUTHOR> http://www.theatlantic.com/life/archive/2011/11/bionic-bodies-why-the-future-for-quadriplegics-looks-so-bright/247362/

<comment><USER2> Reminds me of the quote: "The future is already here — it's just not very evenly distributed."

</comment><comment><USER3> This method is awesome, but the biggest problem isn't batteries, or whatnot. It's that the electrodes don't always last as long as we want. Often it's on the order of 6 months to a year in humans. No one wants to have their head cut open repeatedly.

If a doctor said "you can walk for 1 year only" would you take it? I would, but not for the personal benefit. The loss of walking so soon after gaining it would be hard. I'd really only be doing it for the scientific advancement.

I've worked in labs that do similar things, I'm not trying to knock it, I'm just saying there are still a lot of hurdles to be overcome to make it a realistic solution. And we've been working on these hurdles (electrodes lasting longer) for 10 years.

</comment><comment><USER4> They only talk about healthcare and functional replacement? People seems to not talk much beyond that. The implication could be staggering.

</comment><comment><USER5> Hopefully battery tech will progress fast enough to power these devices. Right now it definitely isn't there as evidenced by Darpa's exoskeleton which is still powered via a cable.

</comment><comment><USER6> Are there any companies which work in this field and need programmers? In Europe?

</comment><comment><USER7> Nerve damage can be healed. I wish there was more focus -- or at least equal focus -- on that fact. I've healed minor nerve damage in myself. This would be a matter of scale. A lot of the information already exists and even main stream medicine is working on regenerative medicine. It would just need to be ramped up, basically. And it would give better quality of life and be cheaper in the long run to just repair the body.

<comment><USER8> Why bother healing nerve damage if the replacement limb is better than the original would ever be?

<comment><USER7> This article mentions an exoskeleton, not a replacement limb. In other words, you keep the non-functional part and add something on top of it. (I've met a couple of quadriplegics. They are, in some sense, slowly rotting hunks of meat. I know this in part because I have a compromised immune system and it makes me very ill to be around one of them.)

If you lose a limb and they replace it with a prosthesis and are working on improving those, great! Seriously. But if you have your original equipment and it just doesn't work, that's a different situation. For example, with organ transplants, you take anti-rejection drugs the rest of your life. I see no reason to believe that a replacement really is as good as getting the original part to work properly. Everything I have seen seems to put a great deal of emphasis on gee-golly-whiz (headline grabbing) solutions (organ transplants, exoskeletons, etc) and not nearly enough on keeping people healthy to begin with or healing what is still there.

<comment><USER8> > I see no reason to believe that a replacement really is as good as getting > the original part to work properly.

It's certainly possible:

[http://www.engadget.com/2008/01/17/prosthetic-limbed- runner-...](http://www.engadget.com/2008/01/17/prosthetic-limbed-runner- disqualified-from-olympics/)

These legs allow him to run more efficiently than his original legs would have.

[http://www.npr.org/2011/06/13/137029208/heart-with-no- beat-o...](http://www.npr.org/2011/06/13/137029208/heart-with-no-beat-offers- hope-of-new-lease-on-life)

The relevant quote is: "'These pumps don't wear out,' he says. 'We haven't pumped one to failure to date.'" The same can not be said of the human heart.

The rest of your argument is from lack of imagination.

<comment><USER7> _The rest of your argument is from lack of imagination._

My opinions on this topic are mostly rooted in having "atypical cystic fibrosis" and getting the hole in my left lung to close (tissue regeneration) when doctors say that is not possible.

Peace.

</comment></comment></comment></comment></comment><comment><USER9> Fuck. Yeah.</comment>


Schneier: It's Time to Regulate IoT to Improve Cyber-Security - <AUTHOR> http://www.eweek.com/security/schneier-it-s-time-to-regulate-iot-to-improve-cyber-security <comment><USER2> Even though many people scoff at the idea of government regulations, the economic incentives in IoT security are really all messed up and it's not really clear that the market will fix itself because so much of the damage can be externalized somehow. Does the manufacturer of a cheap and outdated IoT device care if it's participating in some ddos attack? Or like Schneier said, does the consumers care if they don't notice?

There seem to be some soft mechanisms that governments could explore. Maybe something like demanding opening the source code once security updates for the device stop, so consumers could help themselves. Or at least, an even more modest regulation, simply allowing all consumers to hack their own devices without fear of violating any laws.

One thing that could hurt the market is maybe making manufacturers liable for the damages caused by security holes in their devices, but regulation doesn't have to go that far to make an impact.

<comment><USER3> > One thing that could hurt the market is maybe making manufacturers liable > for the damages caused by security holes in their devices

That's what insurance is for. Something like this was discussed in my torts class in law school, except that was long before IoT devices existed so it was about things like lawn mowers.

The idea is that it might make the most sense economically to make the lawn mower manufacturer liable when users cut off a finger or toe, even if it was due to consumer stupidity instead of any negligence on the part of the manufacturer, because the manufacturer is in the best position to estimate the risks and purchase insurance to cover them.

Presumably, the manufacturer will pass on the costs of those insurance premiums to the consumers. The manufacturer still has an incentive to try to build safe mowers, because if their insurance company ends up paying out a lot the premiums will go up. They can pass those higher premiums on to the consumers, of course, but that will make them more expensive than their safer competitors.

The manufacturer is in a good position to deal with insuring for these injuries because they know how many mowers they are selling. Other candidates have less useful information. For example, a consumer usually has no idea what their chances are of suffering a lawn mower accident, so have no idea how to decide how much insurances is needed. Health insurance companies will have a good idea in the aggregate of how many of these accidents occur in a year, but they have no idea which of their customers use lawn mowers.

Done right, this should not hurt a market much.

I'm not sure it could work for IoT, though, because a lot of IoT devices are made by new companies that probably will not be around long. With things like lawn mowers, you could takes years to get around to cutting your hand off, and still reasonably expect the manufacturer to be around. Not so with a lot of IoT devices.

<comment><USER4> > That's what insurance is for

What are the outcomes for using insurance, and what are the outcomes for using regulation? Does anyone know the answers in a technical policy sense (not in a philosophical sense)? They are different tools useful for different problems.

Thinking out loud, insurance seems like a poor solution when people will suffer serious, irreparable harm. If the lawnmower severs a foot, then an insurance payout isn't really sufficient; regulations should prevent that from happening in the first place. More broadly, my point is that there are larger issues than economics.

> Presumably, the manufacturer will pass on the costs of those insurance > premiums to the consumers.

In economics, that is not the case. Businesses don't price goods at 'cost- plus'; they don't look at their costs and add a profit margin. Think of the soda at the movie theater on one hand, and on the other the car being sold at a loss because the market is soft; think of software. Like all businesses, the lawnmower manufacturer already is pricing their product at the level that maximizes total sales revenue, which depends on supply and demand; raising the price will reduce revenue (probably because unit volume will decrease too much to be compensated for by per-unit revenue increase). If they could raise the price and bring in more revenue, they would have done that already.

There is an issue of elasticity: If your customers' alternatives are limited - i.e., if they can't go without your product, if there are limited competitors and substitutes - then you can raise prices more easily. A Van Gogh painting is highly inelastic; lawnmowers are much less so.

<comment><USER5> On insurance vs regulation -

What isn't being mentioned here is that insurers will require insured companies to do a bunch of stuff in order to remain insured. Have some processes in place, do some things, and so on.

Just like your car insuruance isn't valid if you drink and drive, your software company insurance might not be valid if you aren't using source control and have no testing or code review proccess.

So in some ways, what you get out of insurance is market driven 'regulation'.

Possibly, because a rival insurance company can impose different conditions, insurers are incentivised to require only the stuff that really reduces risk, while regulators might make irrational regulations driven by moral panics in the press. Similarly, they might be more responsive to supporting new technqiues that reduce risk at lower costs, because customers will seek out an insurer that lets them use those.

Possibly, insurers are less suceptible to moral hazard, where regulator employees have close relationships with industry heavyweights and make policy that helps their buisness, at the expense of consumers and sector rivals. Insurers mostly want to make money.

Regulators might be better sometimes because their staff tend to be very mission driven (they want to fix the problem, not make money). They will get a kicking from the public if there is a big accident and laws and regulations did not prevent it, while an insurer is only punished if they don't satisfy current law. So a regulator might be more proactive.

<comment><USER4> Excellent points; thanks.

I'd only add that the insurer's incentive to reduce risks to their profits is not always aligned with consumer's risks. As a simple example, the insurer may require the vendor to have consumers sign away their legal rights to reduce the risk of expensive lawsuits.

</comment></comment></comment></comment></comment><comment><USER6> Not that I'm a fan of government regulation for technology issues like this but the security situation is beyond a joke.

For one, it's time to hold companies (and executives!) accountable for security of the data they are charged with protecting, often without your consent (eg Equifax).

For another, insufficient product liability for companies being lax--even negligent--with security. Honestly I don't see an outcome like network- connected lightbulbs bringing down the Internet as particularly far-fetched.

Frankly I don't even know what the market for IoT even is. Who needs $50 light bulbs that will DDoS someone one day? Or, worse, compromise your network to an attacker.

And all for what? So you can turn the lights on after you go through multiple steps to unlock your phone?

<comment><USER7> > And all for what? So you can turn the lights on after you go through > multiple steps to unlock your phone?

I wanted network-connected lightbulbs so I could have them turn on at the time I needed to wake up, when that time was well before dawn.

I never installed them because I didn't know how to secure them and my schedule got more reasonable, but I think the use case is pretty compelling.

<comment><USER8> Why would light bulbs need to be connected to the Internet for the use case of being turned on at a specific time? They'd just need to be connected to a timer for this.

I mean, an Internet connected light bulb use-case would a bulb that flashed whenever a stock you owned went down in price, which is ridiculous despite being the least ridiculous example I could think of.

IoT security cameras and an automated kitchen you phone to, to prepared you dinner if you were coming home unexpected seems like the least crazy IoT device an individual could own - most IoT stuff seems more like what a global company would want rather than an individual.

<comment><USER9> > despite being the least ridiculous example I could think of.

A lighbulb flashes when visitors ring the doorbell, which is useful for people with visual impairment. the doorbell has a hidden rfid reader, and certain guests have an rfid card. the doorbell flashes differently for each visitor.

<comment><USER8> " _A lighbulb flashes when visitors ring the doorbell, which is useful for people with visual impairment. the doorbell has a hidden rfid reader, and certain guests have an rfid card. the doorbell flashes differently for each visitor._ "

How is this an example of something that needs to be connected _to the Internet_. My point is most examples are about local connect to justify a jump into a world-wide, insecure net.

I mean, all the light bulb examples are contrived because a PHONE has all information-conveying ability of a light bulb and is designed for information- conveyance. Light bulb are designed for the light-consumption needs of those nearby and examples of light-bulb-control at a distance are either poor substitutes for phones or "weirdness" \- haunted houses and art-happenings.

</comment></comment></comment></comment></comment><comment><USER10> Always love Mr. Schneier, but I think torts would be a better way of handling this.

There are several problems with regulation: a) Whack-a-mole, new ideas and business models arise faster than the speed of government. b) Regulatory capture, like what happened to our banking regulations. c) More often than not, penalties are captured by the regulator, but compensation is not made to the injured parties. d) International law / trade agreement complications. I'm sure there are many more.

If manufacturers knew they'd be on the hook for damages in a dollar-to-dollar way, they'd put more engineering into their work, they would price it accordingly, and personally I'd be fine with that.

<comment><USER11> The creation and definition of torts (or the generalization of existing torts to cover new relsted domains) is a mechanism of regulation.

<comment><USER10> Yes. In the postwar period, the word regulation typically entails new laws, possibly a new regulating agency, and a mix of civil and/or criminal penalties. I think a more liberal interpretation of existing torts would be simpler, more just, and harder to game.

<comment><USER12> It also encourages the tiering of IoT such that insecure-and-cheap remains on the market and is pushed towards people who can _least_ afford to be pwned.

Regulation is not blind, but it does raise the floor.

<comment><USER10> "least afford"??? As though these IoT devices weren't pure bored yuppie disposable income in the first place?

I would figure large service providers, and big companies with fleets of marginally protected devices, would be the ones to bear most of the damages coming from shoddy IoT devices being pwned and rolled into larger ddos/ransomware/etc attacks.

<comment><USER12> At the moment, yes, they are at the high end of the market. In three years, you can expect that to be either in the process of moving downmarket. In five, they will be comfortably midmarket and still moving downward. And, the cheaper the device, the more corners cut in production. The more corners cut, the higher the likelihood that at least some of them are in terms of security.

<comment><USER10> We are governed by people who have trouble agreeing that 30 year olds propositioning minors is a bad thing.

I just think broadening the concept of liability in our industry to the point where some company's negligence is _finally_ made an example of has a much better chance of improving things than a panel of regulatory agency appointees that have either already been paid as industry lobbyists, or are operating under the carrot of a future position as a highly-paid exec--just like the FCC, or Robert Rubin, or any of Trump's appointees, or so many others...

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> On the surface, I agree with this.

In practice I expect it to result in fewer products on the market that are more expensive and no more secure as this sort of regulation will simply select for large companies who are experts at paperwork and soft bribes.

I wish I had a better idea.

<comment><USER14> > I wish I had a better idea

Something that already works are various forms of certification.

Examples are:

* "Norton protected" on websites

* Underwriters Laboratories on US products

* US DOD Trusted Computer System Evaluation Critera for how the US military checks the security of a product

* ISO 9001 for quality management

* Oregon Tilth for certifying organic products

Some of these are more valuable than others, but are at least a separate stamp of approval.

With my magic wand I'd have a group come together to form such a certifying organisation and provide it with a marketing budget. The marketing would mirror the success of "check for a green padlock on a website to know it is secure" \- look for the stamp on a product box.

If that doesn't happen and there are more serious incidents is that consumers would look to Google, Apple, Amazon etc. eg if the proposed device doesn't work with the Apple hub and been vetted by Apple, then they wouldn't buy it.

<comment><USER15> The problem with certifying a device (presumably as secure) is that security is a process, and a device that is secure now may not be tomorrow. For a device to remain secure requires regular updates.

<comment><USER14> ISO 9001 for example does certify process. I'm sure organic does too.

</comment></comment></comment></comment><comment><USER16> China already ignores safety and radio regulations. Sure, add more. They'll keep flooding Amazon and eBay with _cheap_ crap and people will keep buying it. Good IoT will just become even more expensive.

The only way to avoid a botnet apocalypse is to secure home routers. Outbound traffic should not be an automatic right. People should have to authorise each device for each type of traffic.

I argued this long-hand when OVH was taken down by "security" cameras. Good to see we've made no progress.

[https://thepcspy.com/read/when-did-we-stop-caring-network- se...](https://thepcspy.com/read/when-did-we-stop-caring-network-security/)

<comment><USER17> > _People should have to authorise each device for each type of traffic_

Nobody wants to do this. I'm a quarter way paranoid about electronic security and even I don't want to do this.

<comment><USER16> Sure. I've been through this though. See the link.

I recommend a certification programme, with manufacturers justifying the access their device needs. A little _signed_ JSON blob of hosts and ports it plans on connecting to. The device communicates this to the router. If the signing certificate is still valid and the manufacturer trusted, the router could just allow _that_ access, or prompt the user to just let them know that device is trying to connect. No confusing detail. And just once, at the same time you're setting up network stuff, so it's not weird or extra hassle.

It's leaps and bounds better than what we currently have. The vast majority of us have zero idea what the devices on our network are actually doing, all while we're each throwing dozens of these cheap internet-enabled things online.

For legacy devices, a more iterative approach might be needed but it can still be prompted: "Dell computer is trying to connect to clearlybaddomain-dot-com. Allow, Allow All, Deny, Quarantine". You could even layer on some "known bad" hosts or traffic patterns via centralised lists to automatically quarantine devices at the router level.

Nothing here is rocket surgery. One developer for a few months. An entity like Google could do this in an afternoon. There's just surprisingly little appetite for it.

</comment></comment></comment><comment><USER18> While we all lament about incentives & regulation which are out of our control, there are still a lot of technical issues to solve, perhaps we can start there.

A few examples: \- It's currently pretty hard to add HTTPS on a router admin page. \- Browsers can't do service detection on a local network, so we have to resort to central servers to manage headless devices (or ugly, unreliable local IPs). \- Punching through firewalls / NAT is still hard, so we again resort to central servers.

It's really fucking hard to do IoT at scale, in a easy-to-use way that's secure and that respects the user's privacy. I think we can solve that.

</comment><comment><USER19> I think a better solution is to buy non smart versions of toasters, microwaves and kettles.

</comment><comment><USER20> May end up in a situation where the network layer of hardware and their respective wrappers/software is monopolized by a group of compliance savvy folks who have done the necessary audits, certifications, etc. In theory it is not necessarily bad, but regulations have a bad reputation because of how poorly these things are generally implemented.

</comment><comment><USER10> IoT is a solution that has been looking for a problem for _at least_ 20 years now. It's like every EE department in existence feels compelled to cram micros and ethernet into every toaster, thermostat and lightbulb.

I guess it only took this long for enough people to become insane enough to justify a market for it.

 _Preach on brother Bruce!_

<comment><USER21> I'm surprised more people aren't willing to consider not having the IoT as the solution. It doesn't look like we'll get a decent solution to security anytime soon and the average person doesn't seem to get much out it anyway. It's just more trouble than it's worth.

</comment></comment><comment><USER22> Yes it is. Importing a cheap Chinese WiFi access point that has an exploitable default password should be as illegal as importing Chinese fentanyl.

<comment><USER23> That's ridiculous, why? I'd understand some sort of certification process and requiring certified products to have ample warnings but why should it be illegal?

If I want to buy cheap hardware or software that isn't certified I should be able to.

<comment><USER24> Same reason it's illegal to drive a car that's not certified for roads or build a building that don't meet safety standards.

You have a right to pose a danger to yourself. You don't have a right to pose a danger to others.

<comment><USER25> In my opinion you should be liable for any such danger you pose to others with the ability to shift that liability to whoever sold you source of such danger while assuring you that it is safe.

In fact it is then inconsequential whether some device puts you in direct danger or in danger of somebody comming after you for putting them in danger.

<comment><USER24> > In my opinion you should be liable for any such danger you pose to others > with the ability to shift that liability to whoever sold you source of such > danger while assuring you that it is safe.

Right. So you, the little guy, is going to shift the blame to a rich company that does this for a living. Say it's a company such as Google which makes some IoT devices. Would you be able to prove in court, and in front of their engineers and lawyers that they've sold you an insecure device? Do you even have access to their source code?

</comment></comment></comment></comment></comment><comment><USER4> We can think of the Internet as a public resource, like the electromagnetic spectrum.[0] The FCC regulates what can use the spectrum, requiring that devices do so safely, in a manner that will not interfere with other devices or cause harm to people or property. The same could (and I think should) be required of devices that connect to the Internet.

Frankly, I'm tired of trying to find time to find specs (and then learn how it really works) to figure that out for myself; I secretly dread receiving anything networked for the holidays. It's difficult for me; most end-users have no hope of protecting themselves - and they seem to assume that any product sold must be safe. They assume it is regulated, in effect.

[0] Arguably the Internet is physically different than spectrum. Physics 'creates' the spectrum and its physical limitations make it a public good; there are only so many frequencies, and propagation is part of the equation. The Internet is a creation of humans and in theory can be recreated or modified at will. But that theory isn't realistic: The Internet cannot be replaced or substantially modified; the public has no realistic option of using a different Internet if they don't like this one. In any practical sense, it's a public good.

</comment><comment><USER26> This is also a business model problem. Consumer hardware companies do not have the margin to make and support software that needs to run for ten years or more.

Before the iPhone, software and hardware were often different and had different business models.

<comment><USER27> This is the big problem, and regulation can not fix it. If companies are expected to pay programmers and testers and support staff to keep their devices up-to-date, that money needs to come from somewhere, and cloud "services" that don't provide any value but exist only for MRR and lock-in are only going to result in a bigger attack surface and a bricked device when the company folds or loses interest.

</comment></comment><comment><USER28> It's simply not going to happen as long as elected politicians and officials are mostly technically-illiterate. These are the same people seriously considering back doors to encryption in the name of security.

Give it 5-10 years when enough of them have died off; then change will happen.

<comment><USER29> No, in 5 or 10 years they will be replaced by new technically-illiterate people.

</comment></comment><comment><USER30> Can someone educate me on one IoT point: devices presumably send and receive traffic over a router. That router presumably has security measures such as a firewall in place to reject malicious traffic. So, assuming a competent user, shouldn't security be primarily handled at the router level rather than the IoT device level? Of course IoT devices should also be secured, but my thinking is insecurity and lack of political motivation to regulate could probably be largely mitigated this way?

That said, I've more or less completely ignored IoT so far aside from passing interest in how easy Mirai was and I've only briefly dabbled in firewall configuration, so many of my assumptions could be wrong.

<comment><USER31> "Assuming a competent user" is absolutely not what IoT is about, it shouldn't be what most of our decisions as engineers should be about. I don't want to have to be a "competent user" for my fridge, lightbulbs, sex toys - i.e. everything is potentially going IoT.

Separately, no - attacks like CSRF will quite happily be routed and compromise an incompetently designed IoT device.

<comment><USER30> I was thinking about blocking all traffic routed for the IoT device which comes from any address outside a set of explicitly trusted sources (such as the vendor's service and the user's smartphone or something). Then attacks like CSRF and default admin credentials become a moot point unless those trusted sources become compromised.

<comment><USER31> That's how CSRF works - I get you to communicate to the device from your "trusted" smartphone or other device. There is nothing you can do at the routing level to protect against it. It is entirely up to the endpoint receiving the request to have implemented proper CSRF protection against attacks.

CSRF has been around since 2001 and is in the OWASP top 10. It would be absolutely valid for regulators to require reasonable steps to be taken to prevent its abuse, along with similar attacks.

</comment></comment></comment></comment><comment><USER32> I am cautiously leaning towards the perspecive that Schneier is right. This problem is not going to be solved by market forces. Ordinary non technical consumers will buy things like wifi security cameras for the absolute cheapest price at $45/unit, based on them having attractive retail packages or what appears to be a good feature set/spec/price. I have not seen any signs that people are moving away from known-insecure things in droves, because in my estimate, only 1 to 5% of users of such things actually care about the operating system/under the hood software configuration of their IoT devices.

<comment><USER33> Hell, even for highly technical users it's almost impossible to evaluate a lot of this stuff.

I mean, I program embedded systems for a living - and I couldn't tell you which IoT dash camera or digital camera with wifi or internet-connected car entertainment system is secure.

<comment><USER34> That's easy - presumably none. At least if you take secure as an absolute value.

</comment></comment></comment><comment><USER24> I don't think that government certification is the answer here. This will turn security into a check-mark. Companies will do the bare minimum to get certified and won't invest a penny more. This would solve some of the more extreme cases we see, but I doubt it'll make a real impact.

Instead, I feel that accountability would work much better here. If you're selling an IoT device, and you haven't taken industry standard precautions for securing it, then you're on the hook for whatever your device is used for. The same can be applies to companies storing personal information e.g. Equifax.

<comment><USER35> I think Schneier is right. The market has utterly failed here and there is no reason to think it will start working. Class action lawsuits are _very_ slow and you have issues of trying to prove actual harm. To use his example if my TiVo is part of a botnet but continues working perfectly, have I been harmed in a way that's likely to let me sue someone?

What happens when you want to sue a company for lack of updates when the company went out of business 6mo after it was created (like Juciero)? You can't sue them, where a law could have forced them to be secure from the start or put up a bond to support the devices for a while.

Companies will do the bare minimum to get certified? You realize that's a _massive_ jump compared to what happens now.

<comment><USER24> You're right, and perhaps ideally we should have a mix of both accountability and certification. I don't know who could or would sue TiVo for the attack, and I don't know how to solve the problem of out of business companies. This approach has its drawbacks.

However, give the certification process some thought too. I can see quite a few drawbacks here as well.

First, a significant advantage for established, rich companies. We'll be swamped with IoT from Apple, Google, Facebook and Amazon while small competitors have a hard time getting their products to the market.

Second, you'd need give the regulatory body access to both your software and your hardware. And what if the device is connected to some cloud server? That body may need to look at its code too to make sure that your control server is compliant. And what about the network? The database? Where does it end? And do you need to re-certify each and every version of your server? What if you introduce a security vulnerability?

Third, certification can't be a one-time deal. That protocol your lightbulb uses to talk to the microwave oven for whatever reason? Well, someone broke that and can now make both of them divulge your dirtiest secrets. The same regulatory body would have to keep track of such vulnerabilities and force manufacturers to update their devices - and what if the manufacturer has gone bankrupt? What if he doesn't want to update these devices? Are you going to force people to throw away their light bulbs? You'll have to, otherwise you're back to square one in which all devices are compromised, only now it takes a little bit longer.

Imagine the bureaucracy all of this will require.

<comment><USER35> You're right, it's not easy. But even specifying hilariously trivial stuff like HTTPS, certificate pinning, no hardocded backdoors, and per-device random initial passwords would probably be a huge boon. Simple security without even talking about the problems on the service servers.

I imagine a market would appear for some of the basic software (Linux diaries, etc) to help make things easy for small companies that do want to do it all themselves.

I like the government idea because frankly I can't think of anything else that would work (outside a rediculously improbable change in consumer behavior).

<comment><USER24> > HTTPS, certificate pinning, no hardocded backdoors, and per-device random > initial passwords would probably be a huge boon

That's what I meant by check-mark security. Yes, it is better than nothing, and by all means let's do that. It's low hanging fruit, and it should be plucked. But in the end it amounts to little more than hanging an air re- freshener on a huge pile of garbage.

I'm just pointing out that such certification might cause executives in companies that today put more effort into securing their devices to stop putting in that effort. If it's all the same to the consumer, why spend any more than the bare minimum to get a check mark?

Today there's no clear bar, and a good engineering team will always be able to convince a responsible management that they need to put effort in security. But once that fairly low bar is set, I think that the next order from the management will be "make our devices certifiable and nothing more".

<comment><USER35> Just like car safety we have to keep raising the bar.

Checklist car safety means a pretty safe car these days, and the companies that go beyond do amazing things.

</comment></comment></comment></comment></comment></comment><comment><USER36> Something similar existed called FIPS-140, though it is hard to certify and not a good fit for IoT.

IoT router/firewall might be one of the solution here, i.e. adding IoT pattern into existing routes/firewalls to protect IoT devices, in addition to your PCs and sometimes BYODs(smart phones etc).

It is very hard to make all IoT devices secure due to limited resource they have, so the first line of protection should be done on the router/firewall/gateway I think.

<comment><USER37> OK, so how do you distinguish automatically "abuse" from "proper use" for arbitrary devices, and how would putting the code that is able to do that on a separate device be easier than compiling it into the firmware of the devices themselves?

<comment><USER36> Look, your PC and BYODs are still prone to attacks, they're much much more powerful than those networked IoT devices, and they still need firewall to protect.

I of course hope all firmware will be safe, and they should be safe as much as possible, still, you need a more powerful device to safeguard them. Put another way, no matter how secure my wifi-bulb is designed, I'm not going to expose it to the internet, and I will put it behind my firewall/NAT-router.

<comment><USER37> > they still need firewall to protect

Why?

> you need a more powerful device to safeguard them

Why?

> I'm not going to expose it to the internet, and I will put it behind my > firewall/NAT-router.

Why?

</comment></comment></comment></comment><comment><USER38> As we move towards a more decentralized future, it's hard to see governments controlling or regulating something like IoT.

Sure, the idea of billions of devices around the world connected somehow is scary, but government regulation is not the answer. If anything, regulation needs to be decentralized. More open source, community involvement with reviews and discussions, more self regulation

</comment><comment><USER39> One thing that should be happening is that ISPs should have to monitor traffic to look for DoS agents, bad bots and perhaps some common vulnerabilities, with the ability to throttle the pipe or shut it off if problems aren't remedied.

Regulating IoT is tougher, but is analogous to licensing the airwaves.

</comment><comment><USER40> I would rather see independent (private) solutions before inviting a bunch of bureaucratic red tape to manufacturers.

For example, someone could create a company that issued certificates of security. Manufacturers would pay a small fee to these companies to perform security tests and give them a certificate of security. They can put that label on their products to provide confidence to consumers. Some products may warrant a much higher level of scrutiny than others so there could be different levels or different companies that offer it.

I think people will naturally choose the products that are 'certified' over the ones that aren't, and manufacturers will have to end up doing it to stay competitive.

<comment><USER41> Lightning cables that aren't MFi certified are still widely used. See their presence is gas stations and other stores nationwide. Lots of "MFi certified" cables online are likely fake. Who knows?

USB Type-C can deliver enough power to seriously damage your $1000 MacBook if the cable/adapter is designed poorly. There is a certification process, but most products on the market are still below-par. Below I will link a list. Guess what, those "bad" products are still bought en masse.

This week, I discovered that pretty much all the water filters that are popular for the type I'm looking for aren't even certified to filter out harmful materials. NSF 53 certification exists, but it looks like the market didn't do any research into it and trusted NSF 42, which was touted but is a much less strict standard, filtering out odor and taste (important in its own way). Theoretically, these filters could be passing on lead and asbestos.

Your solution _might_ work for a _part_ of the market, but it is almost guaranteed that there will still exist a significant (if not majority) part of the market, that doesn't care about certification/prefers the cheaper product.

[https://docs.google.com/spreadsheets/d/1vnpEXfo2HCGADdd9G2x9...](https://docs.google.com/spreadsheets/d/1vnpEXfo2HCGADdd9G2x9dMDWqENiY2kgBJUu29f_TX8/pubhtml#)

</comment></comment><comment><USER42> Bullshit.

What makes 'IoT' any different from an ordinary network-connected computer? You're either saying "it's time to regulate networked computing devices" or, "I want to carve out an easygoing regulation-free niche for _MY_ product[s] to artificially excel in."

I try not to be needleslly pessimistic, but this article has no definition of 'IoT' beyond 'networked computer with sensor', so three guesses as to which one it is.

<comment><USER35> I can easily update my Mac or my Windows PC. I also know that Apple and MS will be around for a while.

How do I update my lightbulb? Who will make updates for? Maybe Phillips will for their product but what about smaller OEMs? What if the company quickly goes out of business like Juicero?

Depending on what you buy and where you buy it do people even know who made it? Would you even know how to check for updates (assuming they exist)?

<comment><USER42> You can, but you very well might not. And your desktop computer is a far, far more valuable target in terms of computing power and network connectivity. Should we be regulating that device as protection against your choosing or forgetting to not follow best practices?

<comment><USER35> > And your desktop computer is a far, far more valuable target in terms of > computing power and network connectivity.

It's also FAR more secure. IoT devices are often easy to hack. And while they may not have much horsepower they have a network connection. You won't mine many Bitcoins but it doesn't take a lot power to be part of a DDoS.

And I have one computer, one tablet, one phone. I may have 5 smart lightbulbs, a DVR, a security camera or two, a indoor/outdoor thermometer....

<comment><USER42> Also a good point, but how would you propose that we measure 'security'? Is an Android phone that hasn't received a carrier update in 8 months "secure"? How about a home server running an ancient distro which long since stopped receiving package updates?

The phone is probably a bigger concern at scale, but I have seen plenty of families with dusty "photo storage/backup" boxes that their family's resident IT person set up and networked when they were in high school.

</comment></comment></comment></comment></comment><comment><USER43> It is a bit out of control. I've written a small Python script [1] that finds dozens of vulnerable devices within minutes just by checking random IP addresses. There shouldn't be that many poorly secured devices floating around out there. It shouldn't be that easy to find them.

[1] [https://github.com/wybiral/dex](https://github.com/wybiral/dex)

</comment><comment><USER44> > there is a difference between when a hacker crashes a computer and you lose > your data and when a hacker hacks your car and then you lose your life.

Forget about hacking your car, what about the hacker that hacks a car fleet? What could a hacker do with a botnet of cars, each with cameras and maybe even face recognition. How about killing off people for the highest bidder at the push of a button.

</comment><comment><USER45> I fully agree on the need for action. But I don't get why IoT should get a special treatment compared to outdated smartphones, PCs, Macs and even video game consoles. Any device that connects to a network is a potential target.

So what about the old iPhone 5 and MacBook Pro from 2008 we gave to our kids for music, YouTube and getting started with computers?

</comment><comment><USER46> Last year I wrote a report on IoT for an info sec and crypto undergrad class, where I covered the usual flaws and explained why that's a worrying standard for an industry that's about to scale up massively.

The professor's response "this is just like all of those internet hit pieces". Hmmmmm.

</comment><comment><USER47> It doesn't help that most of the worst IoT devices come from China in which case regulation seems to be ignored routinely. Things like UL and CE/FCC markings are usually fake.

</comment><comment><USER48> One simple way to improve your security at home is to have a "guest" WiFi network which is separate from your real one and which all these questionable IoT devices can use.

<comment><USER49> That doesn't necessarily prevent them from infecting each other and other people/devices on the internet, or being used in attacks.

It's sort of like living in a neighborhood and having a rock pile you enjoy the aesthetics of, but know it's prone to having rattlesnakes move in, and instead of fixing the rattlesnake problem either as it happens or at the root, just putting a wall around your property excluding the pile. Sure, _you 're_ mostly safe, but when animals/children get bit, your solution starts to look quite a bit worse.

<comment><USER48> Agreed, it's definitely not full-proof by any stretch. But it's amazing how many people enter their WiFi password into devices they really have no control over that can then for example sniff your network, slowly but steadily crack your passwords, possibilities are endless.

<comment><USER37> If that is a security problem, you probably have a much bigger problem anyway. Secure passwords cannot be cracked, the public internet is hostile anyway and you should be protecting your communication with strong cryptography. Pretty much the only sensible reason why you should protect your internal network from access (including sniffing) is because you might have IoT on it that tend to have terrible security. Putting them all in the same, but separate, network, essentially achieves nothing.

</comment></comment></comment></comment><comment><USER50> I always get nervous when governments create laws regarding technology due to the relative speeds at which governments and technology evolve (slow and fast, respectively).

</comment><comment><USER51> Watch this go terribly wrong.

Honestly, I don't understand why consumers lack the restraint to simply _not buy_ unfinished products, but this is where the leverage to improve IoT security has to come from. If today's IoT devices are such a liability, then prove it in court; but don't think that you can write a law that ensures security instead of mere standardization.

Meticulously studying the introduction and effects of regulations in this vein, I highly doubt they will have the intended effect.

<comment><USER52> It can be all but impossible to do so (try finding a "dumb" major appliance currently), nor can buyers deterrmine or distinguish what is or isn't "finished", or what will be supported in 18 months, let alone 18 years.

</comment></comment><comment><USER53> Require manufacturers to pay in to a bounty fund for finding exploits, and make them responsible for fixing the exploits found.

</comment><comment><USER54> Government regulation doesn't infer that a technology will be better. IoT is a very immature industry/technology. Adding a byzantine of obsolete compliance laws is a good way to hamper this industry.

If we are going to regulate, we need to improve laws for consumer electronics across the board, with all the big players on board and participating.

</comment><comment><USER55> Ironic that the site with the article about improving cyber-security doesn't utilize HTTPS.

</comment><comment><USER56> Can't legislate security into existence...at least not very safely

<comment><USER57> You seem to be suggesting a law must say "the maker of any unsafe insecure product is subject to 50 years of jail or $4million".

More realistically, legislators should be crafting incentives. Establish liability statutes. Carve out liability exceptions for companies that can show they used industry best practices, hired engineers that are members of professional/industry organizations, pay for ethics training, establish good faith effort of security development (unit tests, integration tests, traffic encryption, encryption at rest, well designed key exchange architecture, software/firmware update architecture for at least X years after sale, etc).

Conversely, if a company does none of the above, it's easier for a consumer or an Attorney General to bring a case against the company, even if it's years too late to be useful.

The problem with litigation (as well as "free-market" solutions) is that this generally doesn't happen fast enough. The security damage of IoT will be externalized extremely quickly. Being able to identify and sue a foreign company that is far up the supply chain from the end-product.

</comment></comment><comment><USER58> Of course Schneier would want regulation in Iot. That's literally billions of tax dollars that would go to his and other tech consulting and compliance companies. What we really should push for is Open source regulation. Naturally government is always behind on cutting edge tech issues. Open source regulation would improve the efficiency of regulation while saving billions of dollars.

<comment><USER59> Could you elaborate? I'm being genuine here when I say that I have no idea what you mean by Open Source Regulation.

</comment></comment><comment><USER60> There are two pieces here, and Schneier (or at least this tiny summary of him) is wrong on both.

First, yes of course automobiles are regulated and should be. The fact that some things that are and should be regulated include embedded internet hosts does _not_ mean that all devices that include embedded internet hosts should be regulated. This is basic logic.

Second, holding one set of botnet victims responsible for the harms suffered by another (overlapping) set of botnet victims is perverse. Every host should be "secure"; very few are. A secure host wouldn't be a victim of a botnet, either by donating processor cycles or receiving unwanted traffic. If lawyers really need a job security program, consider that ISPs have lots of money and they actually could reduce DOS attacks; why not hold them responsible?

<comment><USER61> > consider that ISPs have lots of money and they actually could reduce DOS > attacks; why not hold them responsible?

You could hold ISPs liable, and they would block untrusted IoT garbage at the network level. Or you could hold IoT garbage producers liable, and they would make security changes and/or pay ISPs to do some firewalling. Either way, the costs and results will probably turn out about the same.

The best solution, of course, would be having fewer things uselessly connected to the internet.

<comment><USER60> Yes the best solution would be if the world were perfect.

How on earth is a civilized society going to keep "useless" devices off the internet? Who gets to decide what is useless? For example, medical devices are notoriously insecure: what politician is actually going to get behind an effort to make Grandma's life more inconvenient and also shorter just to satisfy some nerds' idea of a perfect internet?

The nerds on HN disappoint. When faced with a hard problem, instead of doing the hard work to fix it, they want to involve the lawyers...</comment></comment></comment>


Ask HN:  Anyone using  Python 3 in production? - <AUTHOR>

I'd love to make the switch over to Python 3 before I get tons of code written on my startup.  Anyone using it in production? <comment><USER2> Nobody is switching to Python 3. If you go first you get all of the pain and no advantages (plus switching later isn't very hard anwyay). I would import unicode_literals, division, and the print() function from __future__ and stick with 2.6.

<comment><USER3> What are the benefits of print()?

<comment><USER4> It has optional arguments which make certain things a lot easier and make it much more consistent with the rest of the language.

 _sep_ is the separator between arguments, so you can do something like:

        >> print('a','b','c',sep='')
        abc

_end_ is the value at the end of the line (useful, for example, if you want to print without a newline at the end).

 _file_ lets you specify a file to print to, so for example you can do _file=sys.stderr_ to print to stderr instead of stdout.

<comment><USER5> Being part of __future__, is print() slated for release in 2.7 or is it strictly a 3.x feature?

<comment><USER6> In 2.7, print is still the print statement by default:

<http://docs.python.org/2.7/library/functions.html#print>

</comment></comment></comment></comment></comment><comment><USER7> We in python-dev land have been working on discussing various help documents and things associated with the website. For now, if you have lots of 2.x dependencies - use 2.x - it's stable and well supported by the community.

If you're doing greenfield development, and don't plan on lots of external dependencies, use 3. Personally, if I didn't have dependencies on a few "really big" external libraries, I _would_ be running 3 in production.

This wiki page - a work in progress - should help you if you're thinking about switching.

<http://wiki.python.org/moin/Python2orPython3>

</comment><comment><USER8> We are running a web service (just the API no front end) written in Python 3 for a tiny bit less than one year.

Even under considerable load, the traditional Apache/mod_wsgi combination never failed (though we had some encoding issues during development).

The reason to go p3 was for one the new string handling, which I personally find absolutely beautiful and the idea of future proofing the application. We are a small shop and certainly don't have the resources to rewrite the thing in 3 years when all the cool stuff is happening in python 3 land.

This was also the reason to start development of another application in PHP5 just when 5.0.0 came out. There it paid off, though with p3 I'm not quite sure. It looks as if we are stuck with 2.x maybe forever.

</comment><comment><USER9> The big holdback for my outfit is the lack of NumPy support.

<comment><USER7> This is coming this year, as far as I have been told.

<comment><USER10> it is kind of there if you use the trunk, actually

</comment></comment></comment><comment><USER11> We are not switching anytime soon. I have not looked at what they did to the syntax (hopefully nothing). There is really no advantage for us and most likely it will break things.

If are starting from scratch it might be OK. I guess it depends on your needs for library support.

IMO it was a bad idea to split development like they did. But I am just a user and not in charge. :)

If it was me I would pick 2.6

<comment><USER12> The syntax changed in some areas. For example, the print statement no longer exists; there is a print function to replace it.

</comment></comment><comment><USER13> We aren't running Python 3 yet -- we are using Python 2.6.

The most impressive things that might push us to upgrade are the new VMs like unladen swallow or PyPy, assuming they don't get backported support for 2.7ish style python.

But right now, most libraries are made for 2.x only, and there isn't yet a large enough performance or memory use gap to force us to take the porting hit.

<comment><USER14> Unladen swallow is still based on the 2.x series: [http://code.google.com/p/unladen- swallow/source/browse/trunk...](http://code.google.com/p/unladen- swallow/source/browse/trunk/Include/patchlevel.h)

What I'm writing today to distribute is targeted at 2.x, where x>=5. If I didn't want to distribute it, I'd be using 2.6 and writing as close to 3.x as it allows.

<comment><USER15> <http://www.python.org/dev/peps/pep-3146/>

<http://svn.python.org/view/python/branches/py3k-jit/>

</comment></comment></comment><comment><USER16> No Django support, no Python 3.

<comment><USER17> Ditto. I do mostly Django development, so I'm tied to 2.6 for the moment, but I'll upgrade the second that I can.

Also, Ubuntu ships with 2.6 and I'm too lazy to switch

</comment></comment><comment><USER18> There's no great benefit for the pain. The really cool work in the language - new GIL-removal work, PyPy, pip and virtualenv, etc aren't yet included in Python 3.

When I make the jump, it will probably be to the inevitable 3.5 or 4.0 that includes all the juicy stuff.

<comment><USER7> Why on earth would PyPy be included? If GIL-Removal, PyPy, pip and virtualenv being included is your "must have" list, you're going to be waiting long after everyone else has moved onward :)

For me, it's simply "I just need my dependencies" - which is a simple statement, but an incredibly hard problem.

<comment><USER10> I think the problem is that python 3 is just different, without much improvements over 2 for many people. For example, the things which IMO were worth fixing at backward incompatibility price (like the import system, improved C API with ABI across minor versions, packaging) were not fixed.

I have (in small parts) contributed to the python 3 conversion for numpy/scipy, and the only reason why I have done so is to be a good "python citizen", and because numpy is a major library in the python ecosystem. But I don't see any advantage in doing so. The cost is high, and the advantages near inexistent for me

<comment><USER7> You see - the reason your hit list of itches were not fixed were because no one stepped in to do them - this isn't anyones fault, but it doesn't mean important things were not fixed. Instead, the other itches (such as bytes vs. strings/unicode) were fixed.

Function annotations, the standard library cleanup, and other things came along for the really big ride, which was the bytes/unicode/etc ride. So, there's lots of improvements that came with 3.0 - but the nice thing is is that it continues to evolve.

We now have a New (more rational) GIL, we're probably going to have a futures package (<http://www.python.org/dev/peps/pep-3148/>) and so on (heck, python3 is also getting a jit). And things will continue to be added. Everyone knows and admits that the transition will take years, but now with 2.x being "done" (meaning, no more releases past 2.7) and more great work being done in 3.x, hopefully people in general will start to see the benefits.</comment></comment></comment></comment>


Show HN: GitPoint – GitHub for iOS - <AUTHOR> https://gitpoint.co/ <comment><AUTHOR> Hi HN, author of the app here!

Every single GitHub client I tried to use on iOS was either too simple (single-feature), required payment for the most basic of features and/or didn't have the best UI. That gave me enough reason to build this.

GitPoint is built with React Native and although there are quite a few things that still need to be added to the app [1], launching an Android version is my top priority.

I know the first thing almost everyone would think about before downloading an application like this is security. To use GitPoint, you have to allow the application to authorize your account in order to have complete read/write access to user and repository information. To alleviate any concerns, it's virtually impossible for me to access any user data even if I wanted to with the way the app is set up. Once a user authenticates, their access token gets persisted (with encryption) to the AsyncStorage of their own device and there is no way I would be able to retrieve that sort of information.

As always, I would appreciate feedback of any kind whatsoever :)

[1] Issue List: [https://github.com/gitpoint/git- point/issues](https://github.com/gitpoint/git-point/issues)</comment>


Have your own file exchange service - <AUTHOR>

A few months ago I discovered this software gem on StackOverflow (http://stackoverflow.com/questions/2034038/simple-file-upload-download-manager-for-distributing-files):
http://www.thregr.org/~wavexx/software/dl/
It allows to run your own file exchange server and create automatically-expiring downloads (and uploads). It's perfect for emails and quick file exchange. I didn't put an url because yesterday I was moved by reading the following post in the mailing list:
http://thread.gmane.org/gmane.comp.web.dl-ticket-service.general/150
It's rare to see this kind of attitude, and would like to know what HN'ers would suggest to the author to improve this software. The answer on SO mentioning "dl" is also underrated (despite being a much better fit), contributing to the problem. <comment><USER2> Clicky links:

[http://stackoverflow.com/questions/2034038/simple-file- uploa...](http://stackoverflow.com/questions/2034038/simple-file-upload- download-manager-for-distributing-files)

<http://www.thregr.org/~wavexx/software/dl/>

[http://thread.gmane.org/gmane.comp.web.dl-ticket- service.gen...](http://thread.gmane.org/gmane.comp.web.dl-ticket- service.general/150)</comment>


How to Get 100+ Comments on a non-Contest Blog Post - <AUTHOR> http://www.impressivewebs.com/how-to-get-100-comments-on-blog-post/

<comment><USER2> Summary: Take a side in a polarized environment

<comment><USER3> Subtitle: Use a flamewar to generate comments on your blog.

<comment><USER2> This is actually probably better than my original.

</comment></comment></comment><comment><USER4> For active bloggers - have you noticed higher numbers of comments furthering your sites goals at all? I see lots of people that actively try to increase comments, but I wonder if they're getting causation/correlation wrong.

A high-commented post probably indicates that you hit on a point well, and probably correlates with something meaningful. But do higher comments _cause_ improvement in other metrics? That is, does actively trying to get your comments up produce good results?

Most blogs have near unreadable comments for me - I rarely bother. But maybe my experience differs from others'. Thoughts from regular bloggers?

<comment><USER5> High comments don't really mean you hit on a point well. In my experience it means you polarized a bunch of people: some people fall over themselves thanking you, others call you an idiot.

</comment></comment><comment><USER6> tl;dr troll</comment>


Ask HN: What are the best text editors for different languages? - <AUTHOR> <comment><USER2> Vim</comment>


Django Async: What's new and what's next? - <AUTHOR> https://deepsource.io/blog/django-async-support/ <comment><USER2> I love Django / Django Rest Framework and have used it for a long time, but we recently dumped it from a project in favor of FastAPI.

There is just so many layers of magic in Django, that it was becoming impossible for us to improve the performance to an acceptable level. We isolated the problems to serialization / deserialization. Going from DB -> Python object -> JSON response was taking far more time than anything else, and just moving over to FastAPI has gotten us a ~5x improvement in response time.

I am excited to see where Django async goes though. Its something I had been looking forward to for a while now.

<comment><USER3> We ended up with 2 python layers:

\-- Boring code - Business logic, CRUD, management, security, ...: django

\-- Perf: JWT services on another stack (GPU, Arrow streaming, ...)

So stuff is either Boring Code or Performance Code. Async is great b/c now Boring Code can now simply await Performance Code :) Boring Code gets predictability & general ecosystem, and Performance Code does wilder stuff where we don't worry about non-perf ecosystem stuff, just perf ecosystem oddballs. We've been systematically dropping node from our backend, where we tried to have it all, and IMO too much lift for most teams.

<comment><USER4> Similarly, we ended up doing the same. Boring CRUD/CMS stuff is all in Django. That's 90% of our codebase and by far the most important. Our "user scale" endpoints are all implemented in Lua in NGINX and just read/write to Redis and data changes go into SQS and processed by Celery back in the Django app. It scales phenomenally well and we don't lose any of the great things about developing all of our core biz-critical stuff in Django.

</comment></comment></comment><comment><USER5> Great article. But I think this part may need as second look:

        If your views involve heavy-lifting calculations or long-running network calls to be done as part of the request path, it's a great use case for using async views.

That seems true for long-running network calls (IO). But for heavy-lifting calculations? I thought that was _the_ canonical example of situations async won't improve. CPU bound and memory bound, after all.

<comment><USER6> Perhaps they meant that heavy long-running calculations could be offloaded to a worker pool with a help of concurrent futures and run_in_executor()

\- [https://docs.python.org/3/library/concurrent.futures.html](https://docs.python.org/3/library/concurrent.futures.html)

\- [https://docs.python.org/3/library/asyncio- eventloop.html#asy...](https://docs.python.org/3/library/asyncio- eventloop.html#asyncio.loop.run_in_executor)

<comment><USER7> This will only help if the workers are separate processes. Thread workers will hold the GIL in Python and prevent network I/O while they are doing CPU bound tasks.

<comment><USER8> > Thread workers will hold the GIL in Python and prevent network I/O while > they are doing CPU bound tasks.

Using cython:

        with nogil:
            # whatever you need to do, as long as it
            # doesn't touch a python object

If you're doing heavy calculations from python you should at least be considering cython.

</comment></comment></comment></comment><comment><USER9> Whats the most elegant way for cutting edge Django to do websockets? is it still to 'tack' on the channels package [0] ?

compared to FastAPI[1] I really don't want to use it, I only miss the ORM since in FastAPI it looks like you have to manually write the code to insert stuff[2].

[0] [https://realpython.com/getting-started-with-django- channels/](https://realpython.com/getting-started-with-django-channels/)

[1] [https://fastapi.tiangolo.com/advanced/websockets/#create- a-w...](https://fastapi.tiangolo.com/advanced/websockets/#create-a-websocket)

[2] [https://fastapi.tiangolo.com/tutorial/sql- databases/#create-...](https://fastapi.tiangolo.com/tutorial/sql- databases/#create-data)

<comment><USER10> As someone who's done over a decade of Django work: Do use FastAPI, _especially_ if you need websockets and such.

Django is great for CRUD apps, MVPs and such. And I've used it with success for larger platforms, but it doesn't take long for me to want something closer to the metal whenever I need custom work. FastAPI has filled that need wonderfully well.

I also miss the ORM though… SQLAlchemy is a pain.

</comment></comment><comment><USER11> time and time again, whenever I start a new project, Django has always been my go-to choice after analyzing the alternatives. I've worked on large scale, mono-repo, billion users to side projects over the weekend, Django really stay true to the batteries included philosphy.

</comment><comment><USER12> Wasn't there an article about how the async syntax was benchmarked to actually be _slower_ than the traditional way of using threads? What's the current story on python async?

reference: [http://calpaterson.com/async-python-is-not- faster.html](http://calpaterson.com/async-python-is-not-faster.html)

<comment><USER13> The built-in event loop has meh performance, would love to see the benchmarks re-run using libuv - that would help close some of the gap.

<comment><USER12> They max out the speed with tests. It does use libuv. Uvicorn is the indicator as it uses libuv underneath.

If you heard of Gunicorn, Uvicorn is the version of Gunicorn with libUV, hence the name.

</comment></comment></comment><comment><USER14> I think the article and some of the comments are not really looking at this the right way.

For most things you're probably better off "doing the work" in a celery task, regardless if it is IO bound or CPU bound. Then use web sockets just for your status updates/progress bar, instead of having your front end poll on a timer.

<comment><USER15> The downside of using web sockets is they complicate deployment and reliable delivery is more difficult than `/status?since=$pk`

</comment></comment><comment><USER16> I love django, have not used it in years though. I've been in JavaScript land.

I'm consistently surprised that there are not awesome web frameworks in JavaScript similar to Django

<comment><USER17> I recently stumbled upon keystone and Strapi, they seem a potential contender

<comment><USER18> I'm also coming from Django. I've found Keystone to fit my brain a lot better than most alternatives. Tried strapi and it looks good for basic stuff but the documentation is just absolutely terrible, and once you get out of the really basic stuff you're on your own digging into their source code to understand how to do anything. Nonetheless, ok it looks promising and maybe in a few years it could be something more interesting (to me at least).

<comment><USER18> Oh, and by the way, the reason I'm not using keystone either is because it doesn't support sqlite (for real).

</comment></comment></comment></comment><comment><USER19> I've seen lots of blog posts, even the Django docs, saying async is available but still haven't seen any real world examples yet. Do any exist?

Also, I still haven't seen how the async addition will work with Class Based Views. Also, Django Rest Framework is still considering spending time for support. Until these two use cases are viable many users won't benefit.

</comment><comment><USER20> > If your views involve heavy-lifting calculations ...

Nooo, not at all. Your tasks should be I/O bound, not CPU bound to take advantage of asyncio. Maybe the async server using multiple threads with multiple event loops, but don't ever do a CPU-heavy task in an event loop because you just invalidated using asyncio completely.

</comment><comment><USER21> Looking at the async view example, at what point can we just drop async/await keywords and just have Python assume that everything is asynchronous?

<comment><USER17> javaScript ecosystem went out of the way to bring async await keywords, despite Node.js being asynchronous by using call backs and promises. The argument being code readability, While async await are just wrappers around Promise system.

</comment></comment><comment><USER22> I had a bad experience with Django. I found it cluttered and slow. I really wanted to like it. It might seem funny but a more straightforward framework like Symfony didn't get it in the way and ended up much faster. Python should be much much faster than PHP but I guess the framework matters a lot too.

<comment><USER23> > Python should be much much faster than PHP

How? Afaik PHP is faster than Python in most aspects.</comment></comment>


Boeing Army Computer System Costly, Unreliable, Lawmakers Say - <AUTHOR> http://www.businessweek.com/news/2011-01-12/boeing-army-computer-system-costly-unreliable-lawmakers-say.html

<comment><USER2> Does any one seriously believe that US defence/aerospace companies can actually perform feats of technology any more?

Personally, I blame this on the inability of the US to provide for career paths for technical employees, and discouraging any kind of experimentation (chemistry kits, model rockets, electronic tinkering, etc etc) on the part of kids or adults.

<comment><USER3> I work in defense, and I think I agree with you. The "crisis of conscience" I have is that, on one hand, there are all sorts of colossal fuck-ups and budget overruns that everybody points to when they talk about bloat in the federal budget. On the other hand, though, you have things like the underpinnings of the Internet or work into prosthetics and robotics that have come out of military research but have been highly beneficial outside of the military realm. I chose to put more weight on the "other hand" when I chose to work in defense, but I definitely wish that the country put more emphasis on hard technical problems than it does.</comment></comment>