Microsoft As The Firefox Savior? - <AUTHOR> http://parislemon.com/post/13698115578/microsoft-as-the-firefox-savior

<comment><USER2> Mozilla and Firefox don't require a savior. With hundreds of millions of users, any search service would be happy to pay for Firefox's search traffic.

Ex. Opera has about 1/10th the usage of Firefox and it has a lucrative deal with Google (and Bing and others) that put about $50M in its coffers every year. Search traffic is valuable, both at small scales like Opera and at large scales like Firefox.

</comment><comment><USER3> I wouldn't quite write Firefox off yet. They're iterating faster and making some good improvements to the browser. Personally I use Chrome & Safari, but my mom uses Firefox, and I've certainly noticed the speed improvements going from version 4 to 8. They've reduced the bloat too, we're on 2gb RAM, and the number of tabs we have open sometimes is astonishing, and it's always responsive these days. What do you guys experience?

<comment><USER4> I prefer Chrome and Safari because I'm a Webkit fan. But I got my dad on Firefox and he loves it. Inertia will keep him there just like inertia kept him on IE until I pushed FF on him. Firefox is decently speedy and I even prefer it to Safari in terms of speed (though I haven't used Safari5 much at all so I cant really compare that version).

Chrome does a better job with lots of tabs. Firefox definitely slows down with each tab. I absolutely love the way each tab in Chrome is its own separate process. Why doesn't Firefox follow their lead?

<comment><USER5> > Chrome does a better job with lots of tabs. Firefox definitely slows down > with each tab. I absolutely love the way each tab in Chrome is its own > separate process. Why doesn't Firefox follow their lead?

Many people report the opposite, that Chrome does poorly with hundreds of tabs. The reason is that there is a tradeoff: Running tabs in separate processes as Chrome does takes more memory, but it does help with responsiveness. So whether Firefox or Chrome ends up 'faster' really depends on the number of tabs (and which web pages they are on), and how much memory you have. There is no perfect approach that is fast on everything.

<comment><USER4> You're very right. I suppose Chrome _feels_ faster and that often counts more than facts. I still love the separate processes. Really cool idea, I think. Everyone's mileage will vary when it comes to this I suppose.

</comment></comment></comment></comment><comment><USER6> I don't see anything new here, the potential of a MS-Firefox partnership has been brought up many times, with the pros or cons for all parties.

Then there's some claims that Firefox _and_ Chrome are bloated, to which I can only say: you _are_ aware that current webpages are more complex than those of 5 years ago, are you? I strongly suspect both browsers have gotten significantly _faster_ over the years in relevant benchmarks.

If the author had done some basic research, he could have avoided this:

 _But Marco is right, the real key going forward is mobile. And Mozilla is going to have a very hard time competing there simply because they do not control their own platform. Firefox Phone, anyone?_

This effort already exists for some months: <https://wiki.mozilla.org/B2G>

</comment><comment><USER7> _Then Firefox too became bloated. And it slowed down. I started using Mozilla's Camino (their Mac-focused browser) as a result. Then Chrome arrived, in a similar way to the way that Firefox had. It was refreshingly fast…_

This quote made me laugh, because Firefox was forked from Mozilla because Mozilla was too bloated. It just seems like a perpetual cycle.

<comment><USER8> Accusing Chrome of becoming bloated seems harsh, technologies like SPDY and V8 have improved the browsing experience and isn't it a main priority of the Chrome team to never increase the start-up time?

<comment><USER9> This doesn't change the fact that more and more features get tacked onto a browser which have nothing to do with browsers. Chrome didn't have much useless features a year ago, but now Google is trying to make it into a platform.

<comment><USER8> Which non-browser features have been tacked onto Chrome?

That's a genuine question, the only thing I can think of is the 'Apps' dashboard with a link to the Chrome Web Store, apart from that Chrome seems to consist of just the essential elements of a browser.

<comment><USER10> Chrome native client, Flash plugin (built in), PDF browser. The PDF browser is the only one useful to me, and it's been broken in Linux for the last 3 versions of Chrome...

Some of the newer WebKit features are getting bloated as well, and are built- in even if you don't need them - e.g. the new Javascript de-obsfucation feature in the developer tools.

<comment><USER11> Don't know about you but I prefer my plugins to be auto-updated to the latest, safest versions. Last I checked the non-bundled Flash still had to be manually updated from time to time by the user. The built in Flash/PDF is updated with Chrome. You might not think this is useful, but just wait till you click on a link and get pwned. Even if you don't, because you're on Linux, what about your parents?

<comment><USER12> Homer: Mr. Mayor, I hate to break it to you, but this browser is infested with Flash.

Helen: Think of the parents!

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Until webkit introduce a better debugging tool than it currently has, i dont think any web developer is going to stop using firefox and firebug as their main development browser.

<comment><USER14> I hear this all the time, yet not one person can tell me precisely what Chrome is lacking when it comes to dev tools. What is it you're missing? Anyone?

</comment></comment><comment><USER15> I remember Mozilla people saying something like this few years ago - "We put Google Search as default not because Google funds us, but because it's best for our users."

But now that Bing is equally good (kind of), I think they can really consider it if need be and still manage to not seen as selling out its users.

<comment><USER16> Google search has mind share, which (unfortunately) is more important than actual search accuracy.

</comment></comment><comment><USER17> Firefox is too slow, and it is getting slower with every release. Mozilla should stop using Gecko, and switch to WebKit ...... or should release a WebKit version.

I believe that there is still huge scope for a better browser. Chrome is Google's browser - and open community cant trust Big G. Chromium has a big minus point: no auto-update. You need to download and install newer versions manually.

I want a fast browser (may be WebKit + V8) developed by any non-profit and reputed organization like Mozilla.

<comment><USER16> Switching to Webkit isn't going to speed Firefox up. Gecko is very fast, especially now. As is SpiderMonkey. Firefox's biggest enemy when it comes to speed is add-ons -- which ironically is one of its best features.

Also, Chrome does definitely auto-update. It does it better than Firefox does (and I'm saying that as a Mozilla employee).

Give Firefox 8 (or 9 or 10 or 11, if you're into betas or nightlies) another chance, with a clean profile. I think you'll find it to be incredibly fast.

<comment><USER17> yeah, I use nightly as my default browser. It is faster than the Fx8, but not as the Chrome - even without add-ons.

I agree that add-ons are slowing down Firefox. I expect Jetpacks to overcome this problem, but it seems that add-on devs are not much happy with jetpacks/addon sdk.

>> Also, Chrome does definitely auto-update

I am talking about _Chromium_ here

</comment></comment></comment><comment><USER4> This isnt going to happen. Search is too important to Google to let go in Firefox. Remember, Google is not a browser maker (well, technically it is I guess), its focus is on search. Chrome is the unofficial child of Googlebot and the reason it exists is to help them dominate search. It wouldn't make sense for Google not to renew with Mozilla because that would be a gift to Miscrosoft's Bing.

As far as bloat goes, well addons account for a lot of bad performance and we have to remember that Firefox is old and there are people who have been using it for ages. Those people are carrying a lot of baggage in the form of old browser profiles, the user database, maybe even years worth of cookies and history. Setting up a totally fresh Firefox install would speed things up for many.

But I can't be a Mozilla apologist. I switched to Chrome but use FF for testing. I've found that FF _is_ what I wouldn't exactly call "slow" but just "less fast" than Chrome.

It seems most software ends up bloated. Anyone who codes knows that code is never finished. There's always that temptation to add more and more to a project. Security updates and under the hood stuff is boring. New features are sexy! Sex sells. I recently created my own little web dev boilerplate and the first version was a nice starting point. Then I had this urge to add stuff until it was no longer a boilerplate but pretty much an entire website minus content. Ridiculous. It sucks but it's reality and we need to control that impulse to constantly add where no additions are needed.

Edit: spelling.

<comment><USER18> > Chrome is the unofficial child of Googlebot and the reason it exists is to > help them dominate search.

Technically Google is in the business of advertising. They don't really care how you see the ads, so long as advertisers remain happy. Search just happens to be a good way to present those ads.

<comment><USER4> Okay that's fair. I stand corrected. Even so, it's still to their benefit to make sure people are directed to where their ads are (google.com) and that means renewing with Firefox in the context of this discussion. They must be first in search for their ad network to be so lucrative.

</comment></comment></comment><comment><USER19> Mozilla is in trouble if the PC and the entire "desktop computing" model continues to be sidelined in favor of mobile devices and natural UI's. Of the three mobile devices I own (phone, tablet, ipod) on none of them do I need to go to www.Google.com to find information, nor I do use any Firefox browser. What happens to Firefox when I no longer need a laptop or desktop computer of any kind? The quality of the browser and the team, the philosophy, and goodwill is meaningless if their product isn't on the devices I'm using.

<comment><USER4> Mobile is huge but the desktop isn't going anywhere any time soon. That's apples and oranges. The dust will settle and desktop and mobile will find their place as tools and nothing more. A lot of people talk about the death of desktop computing and that's just bull. Furthermore, Firefox is on mobile already. They don't need their own platform to survive. Firefox stands for something that differentiates it from the other browser makers. There will always be a market for what Mozilla offers and it isn't going away any time soon. People that are concerned about privacy will ditch Chrome, people who enjoy a fast browser that renders pages as they were meant to be will ditch IE, and as for Safari... well I'm not sure if anyone really uses it all that much (it's a great browser but to me it just collects dust).

<comment><USER19> Sure, buy that huge desktop computer, and 27" monitor, mouse, ergonomic keyboard, swivel chair.... to watch youtube videos and use Facebook.

Nope. The desktop computer is dead. Home users will go tablet.

Enterprise users don't use Firefox today, and they probaby won't tomrrow unless something drastic happens.

<comment><USER4> I still disagree. The home desktop will sharply decline and I agree that the way people use computers these days don't warrant the full desktop experience but we're overlooking a few things that mobile devices including tablets won't be able to replace for quite some time because of UI restrictions alone.

People will still need to do word processing at home. Yes, tablets do an awesome job, you can get wireless keyboards etc. but there will still be users who feel more comfortable with the desktop. That's an edge case so I'll go on.

Movie editing. I don't think the iPad can replace iMovie and won't for some time. I'm sure they can come close but then people still want to burn to DVD. Same with photo editing.

And there's a lot more I think we're overlooking. There's no doubt that desktops are on the decline but their not going the way of the mainframe. They'll find their place and that place won't be as prominent as it is but I really doubt it'll be obsolete for home users at least not in the next 5 years.</comment></comment></comment></comment>


"Some people really benefit from hearing advice that everyone knows..." - <AUTHOR> https://twitter.com/patio11/status/936615043126370306 <comment><USER2> Extensive discussion a couple of months ago: [https://news.ycombinator.com/item?id=15826445](https://news.ycombinator.com/item?id=15826445)

</comment><comment><USER3> Tweet storm concatenated: [https://threadreaderapp.com/thread/936615043126370306.html](https://threadreaderapp.com/thread/936615043126370306.html)

<comment><USER4> Wow, what a stunningly helpful service, especially since Patrick seems to make use of Twitter threads more often than a lot of my other followers. Thanks for introducing that page/app to me

<comment><USER3> No worries! I found it myself by reading through the replies to the tweet storm.

</comment></comment></comment><comment><USER5> > Salaries in the tech industry are up _a lot_ in the last few years

This is an impression i have perceived more than experienced the last few years. Does someone have some research on the topic, specifically outside of the parallel payscale universe that is the valley? For instance: what is a reasonable expectation for salary levels once you hit 30 with 7+ years of startup strategy and coding experience?

</comment><comment><USER6> Disagree on the view that ideas are not valuable. its a common clique that people assume is true.

Ideas that are not well researched are worth little. But ideas that are scrutinized and based on months of customer interviews and market research are extremely valuable.

<comment><USER7> >> But ideas that are scrutinized and based on months of customer interviews and market research are extremely valuable.

Everyone inherently knows that. That's an "idea" that is more like a research project that had tons of effort put into it.

Patrick's comments are for the people who think "BLOCKCHAIN BUT FOR DATING SITES."

<comment><USER8> A more charitable example of a valueless idea would be my idea of a jewelery company that takes you through the process of forging your own engagement or wedding rings. For something that sentimental, I think there's a lot of people who would appreciate being able to say they did more than just drop down a few thousand dollars on a jewelery store counter.

But, making goldsmithing accessable to the general public would probably be a very difficult business to start even for someone experienced. How do you cheaply train up random people to get good results? Maybe with the right equipment and expert guidance, people could do it. However, the research and design that would go into putting that workshop and program together would have to be pretty extensive.

Hence, as good as an idea as I think it is, it's valueless without a detailed plan and some actual validation.</comment></comment></comment>


Ask HN: How do you handle estimates when there is no spec? - <AUTHOR>

I've gotten back into freelancing over the last 9 months or so, and I've been pleased to find myself getting better projects than I had in the past. That said, I've been running into problems with estimates.<p>Clients invariably want an estimate for a project before they hire you. But it's impossible to give a good estimate before you go through requirements gathering, writing stories, etc. I'm considering splitting requirements/spec and development into two separate projects, but I thought I'd see how other HN freelancers handle estimation in the face of uncertainty. <comment><USER2> Good clients understand that figuring out the what is as important as how and when. If you have issues with people not understanding the importance of each of those verbs in terms of business and technology then move on politely. Don't waste your time.

</comment><comment><USER3> Have you considered in those situations stating that with the limited requirements and storyboards that you would quote them per hour say 100/hr?

</comment><comment><USER4> Give them an estimate for how long it will take you to finish gathering requirements, and offer to pick the discussion back up when that's done.

</comment><comment><USER5> I always do estimates based on assumptions. And then list out my assumptions.</comment>


The Switch-Router War Is Over, and Hyperscalers Won - <AUTHOR> https://www.nextplatform.com/2019/07/23/the-switch-router-war-is-over-and-hyperscalers-won/ <comment><USER2> I did a lot of network work early in my career (high school job at a small town ISP in the early 90's), and have read deeply about / waxed nostalgia for the Arpanet era ever since.

Networking now is as different from my ISP days as they were to the days of IMPs. It's remarkable.</comment>


Ask HN: What's the next innovation in computer languages? - <AUTHOR>

What's the next innovation in the computer language landscape?
 - Punch cards
 - Machine instructions, Assembler
 - C and native languages
 - Managed, Interpreted and Garbage Collected systems<p>What do you envision as the next step in this journey? <comment><USER2> I would expect that mixing dynamic & static typing still is an area that could lead to some language breakthroughs.

Dynamic typing is great for exploratory programming and static typing offers additional correctness guarantees.

Some work has been done in Haskell, Clojure and Racket in this direction (allowing static and dynamic types to co-exist) but I think lots more is possible.

</comment><comment><USER3> I think that we are only scratching the surface as regards support for static analysis and automated refactoring.

Also, I think that we will start to apply some of the machine learning and statistical pattern recognition techniques that have become so "du jour" recently to programming - enabling development tools to do some really sophisticated things.

</comment><comment><USER4> I'll take a stab:

* Concurrency support at the language level.

* Immutable data structures becoming the default.

Making Clojure (2/2) and Go (1/2) some up-and-comers. Erlang probably deserves some credit, but I'm not familiar with it.</comment>


#GetStarted2014 Enter your own idea for the chance to win! - <AUTHOR> http://getstarted2014.co.uk/getstarted2014/ideas/6515 <comment><USER2> Vote for this startup idea to win $70k from #GetStarted2014 [http://getstarted2014.co.uk/getstarted2014/ideas/6517](http://getstarted2014.co.uk/getstarted2014/ideas/6517)</comment>


Ask HN: What are you building on Google App Engine? - <AUTHOR>

I was wondering what kind of apps/businesses folks were working on that are based on the App Engine. Would be very curious to hear what your experiences are like, especially about the limitations of the platform and how you worked around them.
I built a tile cutter (http://www.piritiles.com) app that'd let you instantly create a Google Map of any image a while ago, and now working on a more comprehensive map/mashup building app that I'll be launching in a couple months.
One of the interesting (and not very clearly documented) issues I've faced was the weird 500 errors the app would generate when you have consistent request response times over a few seconds. Technically all requests need to return in 30 seconds and the occasional ~10s response was okay, but for background processing intensive apps like Piritiles, using TaskQueue API (which was just coming out of beta at the time) was essential. <comment><USER2> I built <http://www.scoratic.com/> Its a daily list of the most valuable dropping domain names.

My biggest problem was ingesting data. The CSV file I needed to process was above 10MB and unable to be divided using range headers in my requests. This file size was too large to be requested by App Engine. I had to write a separate app on a VPS to process the raw file into a smaller and smaller more efficient file and then ingest that file to app engine.

At the end of last year, App Engine lifted this file size restriction and have been able to adapt the code and now it is full automated.

</comment><comment><USER3> I made <http://www.trackthisnow.com>

<http://www.glerts.com/beta>

<http://www.readevery.com>

<http://www.bettermylist.com>

<http://www.dealzfull.com>

<http://www.teampinch.com>

<http://www.newsgrasp.com>

all on app engine

</comment><comment><USER4> I haven't built anything worth bragging about, just a Zillow app playing with the Google datastore (cool stuff there).

Ran into the same thing with those 500 errors. I recall the error message seeming to me like it was a rare occurrence, not a Fail Whale "don't worry it happens all the time" kind of thing.

</comment><comment><USER5> I've built <http://www.tweethit.com> Basically it's TweetMeme for online products. Processing Twitter Streaming API, about 400k tweets per day.

Having some problems with failing cron jobs without any error messages though.

</comment><comment><USER6> My entire company's website runs off AppEngine - <http://www.getaround.com>

</comment><comment><USER7> <http://acronym.mmblr.com/>

LOL</comment>


DOJ confirms new criminal probe linked to Waymo v. Uber lawsuit - <AUTHOR> https://arstechnica.com/tech-policy/2017/12/doj-confirms-new-criminal-probe-linked-to-waymo-v-uber-lawsuit/ <comment><USER2> Yes, that will happen when the judge in your civil case becomes convinced that you destroyed evidence during discovery. The legal system has _no_ sense of humor about this; destruction of evidence undermines the whole process after all.</comment>


Hackers Remotely Attack a Jeep on the Highway - <AUTHOR> http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ <comment><USER2> Some questions for the researchers, or anyone else who thinks this was okay:

1) Were public roadways and speeds of 70mph absolutely necessary to demo this?

2) What was the plan if the trucker approaching at 70mph hadn't seen the Jeep stalled early and had to swerve or panic stop, possibly crashing and injuring themselves or others?

3) Anyone notify the Missouri State Highway Patrol about this? They may be contacting the researchers with questions about this demo if they weren't consulted in advance.

4) What's the plan if they trigger a bug in the car software of the people they had tested this with earlier? The article mentions them tracking people remotely as they attempt to learn more about the exploit.

I could go on but why bother? In case any of you think this was cool or even remotely (no pun intended) ethical, I'd like to know if you have a problem with letting these two test this on a loved one's car. How about they remotely poke around your husband or wife's car and explore, as long as they promise not to intentionally trigger anything?

If I ever learned this had been tested on a vehicle I was in, I'd make sure this cost the researchers dearly.

EDIT: I've just phoned 'Troop C' of the Highway Patrol at their main number, +1-636-300-2800 and they seemed pretty keen to follow up. The fact that the vehicle was disabled where there was no shoulder, was impeding traffic, and the demo not cleared with them in advance has them concerned. I'm all for testing exploits and security research, but this isn't the right way to do it. And to film it and post it to a high traffic site is nuts.

<comment><USER3> Calling the police on security researchers...I honestly cannot believe this is considered acceptable behavior. A much less aggressive (and thoughtful) move would be to contact the researchers directly. Wow.

Back to the article, I think that this type of exploit will become more and more common as vehicles become more connected and automated. We need to know that we can trust the software and firmware running on the devices that literally have the power of life and death over us. Unfortunately, this is a VERY complicated issue, and no one has a solution yet AFAIK.

I watched a talk by Cory Doctorow last year where he suggested validation at the hardware level (a la trusted platform modules), but unlike the typical TPMs that only allow vendor software to be authenticated, these TPMs would allow the user to directly authenticate the firmware. If you know the firmware is good, then each layer can validate the next layer up all the way to the OS.

I have yet to hear of a system that allows the user to directly authenticate software/firmware at the hardware level. Is anybody working on research of this nature? Or are there insurmountable problems with this approach?

<comment><USER2> Too late to edit my original comment again so I'll post a reply here as a general reply to those who reacted negatively to my decision to phone the police.

While I strongly support free speech and believe security researchers should be given some extra latitude when appropriate, what I saw was not at all appropriate. I saw two well respected security researchers sitting in a room like Beavis and Butthead laughing and remotely disabling a vehicle on a multi- lane interstate highway, like it was a big joke. The reporter in the Jeep literally says "This is dangerous" and asks urgently for help. This all filmed and posted to Wired for the world to see, like they are proud of it.

Before working with computers I drove tractor-trailers for a while and was lucky to achieve a million-mile safe driving award. I have a pretty good idea of the dangers here and I know that stretch of road well, I've crossed it many times. I know from experience that a car stopped in the middle of a multi-lane interstate is one of the most dangerous situations you can be in. I've had people hit me who didn't see my huge trailer with flashers on and warning triangles out on a sunny day - it happens quite often. I've seen dozens of people killed in situations exactly like this. You see it coming and a random driver just plows into the stopped vehicle.

I exercised my judgement and decided to phone the local Highway Patrol office. I've read the negative comments and I disagree, I still think it was the correct thing to do. If you are a researcher and you do something this dangerous, and are foolish enough to then post it on a high-traffic site like Wired, I think you forfeit any right to a discreet warning and you deserve to have the police show up demanding answers to some tough questions.

<comment><USER4> You've seriously seen "dozens" of people killed?

<comment><USER5> Is it really inconceivable that someone who has literally driven tractor trailers more than a million miles has seen dozens of people killed in accidents?

<comment><USER6> No, not at all. I'm just a regular middle aged driver with perhaps 300k miles under my belt and I've passed numerous fatal accidents on the roadway.

I just sat back and tried to estimate (since of course, I don't have a CB in my car and can't follow traffic details like a trucker) but I'd guess I've driven past at least 5 fatalities -- and that's just fatalities I've noticed (body on stretcher, read about it on the news later, etc)

</comment></comment></comment></comment></comment></comment><comment><USER7> To recap the facts:

\- Man drives car on public highway @ speeds of up to 70mph

\- Hackers turn on windshield wipers and fluid to blur view

\- Hackers Blare music and obscure any comms link to driver

\- Hackers disable vehicle on Highway at location with no shoulder

And there are people who are not only ok with type of experiment but think there should be more of it.

I understand that these exploits need to get attention... but I really can't stop thinking about my wife and kids being behind this guy while he shows how dangerous this can be.

I applaud the person who notified the police.

<comment><USER8> > but I really can't stop thinking about my wife and kids

What about all those wives and kids that would have been endangered if the flaw had continued to go unfixed and exploited in a more malicious manner?

Can we please not make "BUT THINK OF THE CHILDREN" arguments? Appealing to emotion makes arguments, well, emotional.

<comment><USER9> The two options here are not "test on highway with other drivers" and "let flaw exist with no testing and no exposure". There are _many_ ways to responsibly test this while not endangering others on a public road. For example, using a private road, a large empty parking lot, an abandoned airforce base, the salt flats, etc.

The Mythbusters test stuff like this all the time. What do they do? Use an abandoned airforce base or the Utah salt flats. Rule number one, _don 't endanger the public._

<comment><USER10> > For example, using a private road, a large empty parking lot, an abandoned > airforce base, the salt flats, etc.

The researchers did many of these things, according to the article. They were ignored by auto makers.

<comment><USER9> If you increase the danger of a situation to increase it's exposure, you can't be surprised when that causes repercussions. I doubt they will go to jail, but I do think alerting the authorities was the right call.

In fact, they may have been counting on that. If they _really_ want to increase the exposure of a story, start a public debate. The easiest way to do that? Get some public outrage going. They called this all out, they'll need to deal with the consequences.

<comment><USER10> I don't disagree with you on that. The researchers (and WiReD) should certainly be aware of the risks here, and be prepared to accept the repercussions thereof.

On the other hand, while two wrongs don't make a right, I'm glad that the researchers made that choice, so long as said choice results in manufacturers actually taking car security seriously for once.

</comment></comment></comment></comment></comment></comment><comment><USER11> So, it's becoming abundantly clear that vehicle companies (autos, jets...) have approximately zero knowledge how to hire software engineers. Presumably they're somewhat more successful hiring mechanical engineers because that's always been their "thing".

It's all well and good for us to chuckle at the terrifying software/systems decisions being made by these teams, but how do we address the root of the problem? It's very clear that entire meta-categories of horrific errors are being made at a very fundamental level. Is this a problem of outsourcing? Of confusing "coders" with engineers?

And how do we solve it? Shame the software team such that they can never get hired in a serious role again anywhere? Professionalize the job into a strictly licensed regime like other branches of engineering?

Whenever I read these types of articles, my main thought has always been, "so who, the _hell_ , wrote the code?" It'd be interesting to know their story.

<comment><USER12> The fact that a dashboard system that controls your radio or AC has access to cut your transmission is also a _hardware_ configuration issue. Accessories should be physically secured from ignition and drive train. The internet connected features of the car, in turn, should be severed from both of these. It should not be physically possible to turn on the wipers from the embedded processor that receives packets on the IP address of the car.

<comment><USER13> And what are we going to do for self-driving cars? These are almost certainly going to rely heavily on internet access to perform basic driving functions. Figuring out how to make complex systems like these be secure in a trustworthy way is going to be a huge challenge as more and more critical devices are connected to the Internet.

<comment><USER14> No way a self driving car can rely on Internet access to "perform basic driving functions". Lag and connection failures would kill people.

They might need Internet access for updates, in which case, there should be a physical switch that connects the net and disables the engine.

<comment><USER15> An air gap is hardly a solution for traffic information the route planner HAS to talk to the computer responsible for getting from A to B. In the same way that firewalls are no longer particularly relevant, air gaps appear to be flawed now too, the only way to solve any security issue is better code quality..

<comment><USER14> It's not perfect, but an air gap can help reduce the attack surface and interval.

Better code quality is important too, of course.

I agree with cameldrv that it's going to be a challenge.

</comment></comment></comment></comment></comment></comment><comment><USER16> All the researchers and the journalist had to do was to talk to the Highway Patrol and say, "We'd like to test this on a highway; what do we need to do to make that happen?"

That's it. Maybe the State Patrol would say, "Sorry, there's nothing you can do to test this here legally", or maybe they would have said, "Pay for overtime for 10 troopers and you can do it."

The point is, we don't know. We can speculate, but we don't know.

The 'researchers' and journalist elected instead to conduct this experiment on a state highway, in "real world" conditions, without any safety mechanisms in place. Not only is this unethical and dangerous, it is (and should be) illegal.

No one should stop these experiments from taking place; and the CFAA should be amended to allow security researchers to research issues; but the problem I have is the inherent danger in this experiment.

What would we be saying if the journalist had been killed, or a mother and her two kids because of this? Do you think public sentiment would support security researchers if this had turned out differently?

If anyone had gotten hurt, you'd be looking at legislation that strengthens penalties for security researchers; not at legislation that takes security research more seriously.

This was an extremely childish move that had the propensity to hurt our industry more than help it. It is incumbent upon us take safety seriously in conducting these experiments.

We can't count on level heads from outside the tech industry if we aren't willing to show that we care about people's lives and their safety when we're conducting these experiments.

<comment><USER17> > This was an extremely childish move that had the propensity to hurt our > industry more than help it. It is incumbent upon us take safety seriously in > conducting these experiments. We can't count on level heads from outside the > tech industry if we aren't willing to show that we care about people's lives > and their safety when we're conducting these experiments.

Agreed. I would have no problems with them doing this on a test track, closed highway, or even a quiet road at low speeds. Even if we take the best possible negative scenario—say, the car is disabled going at 25 miles an hour, the driver can't handle manual steering, and then runs into someone's fence—the insurance companies are going to throw the book at the driver when they learn that they purposefully disabled their car and engaged in dangerous behavior on a public street.

I'm all for pushing the boundaries of security research (there are people in the labs all around me right now doing crazy stuff), but at least we in the academic world get our crazy stuff signed off on by a panel of competent experts.

</comment></comment><comment><USER18> _All of this is possible only because Chrysler, like practically all carmakers, is doing its best to turn the modern automobile into a smartphone._

I think this is the biggest problem. Stop making "smart" cars with all these unnecessary features. Even if you can't resist adding entertainment or navigation, don't ever physically connect those systems to the critical systems like engine and transmission computers except through a one-way (to display information) link, like it's done on airplanes.

I'm happy to have a much older vehicle with none of these "enhancements". It has a physical throttle, hydraulic brakes, and steering linkage for which remote hijacking is physically impossible. I can add navigation and entertainment with a smartphone mounted on the dash. It may not be as fuel- efficient or safe(?) as the cars today, but maybe the tradeoff is worth it. That also suggests there could be a market for new "dumb" cars which have all the modern improvements to engines and safety, but none of these "smart" exploitable features.

(I'm not so paranoid as to get a mechanical EMP-proof diesel though...)

<comment><USER19> It amazes me that while more and more jurisdictions are banning cell phone use while driving, vehicle makers are increasingly resorting to touch screens for things like stereo and climate control. When using a smartphone while driving is illegal, how are in-vehicle touch screen controls meant to be operated by the driver not banned?

As much as I love Tesla and what they are trying to do to the car industry, they are the worst offenders in this. Hopefully by the time I can afford one, there will be legislation making entirely touch-screen dashes illegal and they'll have the usual 3 dials for climate control, that you can operate without having to take your eyes off the road.

<comment><USER20> How would you like those three dials to control the rest of the car systems? And, isn't this what BMW tried to do ages back with that single 'iButton' control that everyone hated?

<comment><USER19> Uhh, the same way almost every non-luxury car made between 1960 and 2010 did it? A dial each for temperature, fan speed, and where the air is blowing. Plus a button for air conditioning and/or recirculate. No touch screens, no menus.

People have been using cars without touch screens for 50+ years. The UX is a pretty much a solved problem by this point. Yet now car manufacturers seem to want to mess with something that worked great, just so their cars seem cutting-edge.

<comment><USER20> You do understand that there is more than just climate control that can be adjusted in a vehicle these days? There's navigation and direction finding, traffic alerts, radar proximity warnings from other traffic, radio and entertainment systems, telephony functions, systems monitoring and alerting for various components, current engine and transmission ststus, location data, environmental data...

</comment></comment></comment></comment></comment><comment><USER21> DARPA researchers demonstrated this stuff on a "60 Minutes" segment a few months ago [1]. The main difference is that they were in a large empty parking lot so as to not unethically put non-participants in danger.

That work and earlier work (including that shown in the 2014 Black Hat presentation by the researchers in the present article) drew interest of the Senate [2]. Senator Markey's office produced a detailed report, and has called for the NHTSA and the FTC to develop standards to deal with these issues (and also the numerous privacy issues modern cars raise) [3].

[1] [http://www.cbsnews.com/news/car-hacked- on-60-minutes/](http://www.cbsnews.com/news/car-hacked-on-60-minutes/)

[2] [http://www.cbsnews.com/news/sen-ed-markey-on-safety- privacy-...](http://www.cbsnews.com/news/sen-ed-markey-on-safety-privacy- concerns-for-cars-vulnerable-to-remote-hacking/)

[3] [http://www.markey.senate.gov/imo/media/doc/2015-02-06_Markey...](http://www.markey.senate.gov/imo/media/doc/2015-02-06_MarkeyReport- Tracking_Hacking_CarSecurity%202.pdf)

</comment><comment><USER22> Lot of comments here are accusing the "hackers" of negligence, but do not forget the writer, camera crew, and editors of WIRED were fully in control of the demonstration. This happened in the context of journalism, not security research. Blame WIRED if you think they screwed up, not the folks behind the computer.

It was up to WIRED to ensure the safety of the demonstration, and evidently they failed given this passage,

 _After narrowly averting death by semi-trailer, I managed to roll the lame Jeep down an exit ramp_

Seems to me they should have at the very least had a chase car trailing the demo car with a sign, flashing lights, or flags to alert nearby drivers.

<comment><USER23> I think people are quick to single out the researchers because there is more at stake when researchers act recklessly. When a journalist does something reckless, it's a problem with that journalist. The Constitution protects other journalists continuing to do what they do.

When a hacker does something reckless, it's usually painted as a problem with all hackers. Which then fuels calls for draconian laws which would hinder future research.

<comment><USER24> I think it's because the article clearly names the two researchers, while WIRED is a faceless organization. It's a lot easier to get mad and blame the one with a face.

</comment></comment></comment><comment><USER25> This discussion is going insane.

I see lots of people arguing about the safety of how these guys conducted the hack. Okay, sure, there is probably an issue there of some degree.

But it's a very small issue compared to the fact that hundreds of thousands of vehicles are arbitrarily hackable _right now_ , with more rolling off the assembly line all the time, and people are driving these around _right now_.

Why is most of the discussion here about the minor issue? Why is everyone so eager to derail discussion from the major issue? I thought HN was trying to be a reasonable place.

<comment><USER26> > Why is most of the discussion here about the minor issue? Why is everyone so > eager to derail discussion from the major issue? I thought HN was trying to > be a reasonable place.

I find these criticisms _extremely_ reasonable. Plus, the big discussion is not about them doing something illegal, the big discussion is about people here being totally fine with it.

And given that the topic you (I assume) want to discuss is something along the lines of "negligent behavior in technology", I also find it very relevant that negligence is countered with more negligence.

<comment><USER25> They might be reasonable in isolation but are not being levied remotely in proportion.

I just realized what the problem is: this is bikeshedding. Everyone knows about people driving around and feels qualified to have moral indignation in that area, whereas few people know anything about actual cars.

<comment><USER26> No, when people's lives are at stake, I extremely disagree about calling that "bikeshedding".

<comment><USER25> Please make an effort to read and understand my point.

Yeah, maybe there was a case when a couple peoples' lives were at stake but nothing happened.

The real issue is that tens of thousands or hundreds of thousands of peoples' lives are at stake RIGHT NOW, under conditions that are much less controlled than what people are deriding as uncontrolled conditions. But people are griping about the 1-2 instead of the 10,000-400,000.

How is this not dead simple to understand? I don't get it.

<comment><USER26> > Please make an effort to read and understand my point.

Please don't assume disagreement implies I didn't make an effort. I understand your point, I just vehemently disagree with it. Bringing up the word "bikeshedding" when discussing putting people in danger of death is just something I can not agree with.

> Yeah, maybe there was a case when a couple peoples' lives were at stake but > nothing happened.

This is exactly why I so vehemently disagree. If we found all the people who were in traffic with them at the time, do you think they'd agree that doing experiments in public traffic next to them is a purely aesthetical issue? Recklessness isn't defined by the outcome, but by the possible outcome.

> The real issue is that tens of thousands or hundreds of thousands of > peoples' lives are at stake RIGHT NOW, under conditions that are much less > controlled than what people are deriding as uncontrolled conditions. But > people are griping about the 1-2 instead of the 10,000-400,000.

Yes, and I'm saying both are very important issues. Experiments on public roads in actual traffic are something that should not ever happen. I'm also not sure I'd put the amount of people they endangered in the 1-2 range, since there was at least one other person in the car, one in the truck behind, and others in the cars that passed them.

I also wouldn't go so far as calling this controlled, since that usually means a controlled setting, safety precautions and such.

> How is this not dead simple to understand? I don't get it.

As said, I do understand, I just disagree. It would also make it much easier to talk about this if you weren't trying to insult me and others.

I agree that the flaw itself is a very big issue. I disagree that the way the experiment was done isn't. And nobody here is arguing that it's good that the cars have that fault, so it's quite natural for the discussion here to be around topics people disagree on.

You know what the perfect location and media would have been for such an experiment? A television car show with a dedicated track and a big audience of people driving cars.

</comment></comment></comment></comment></comment></comment><comment><USER27> Should hackers actually kill somebody, I struggle to find a reason why the relevant automotive engineers and their managers shouldn't be charged and convicted of negligent homicide, or worse. After all, somebody had to make the decision to connect a radio receiver to the CAN bus. Others are aware of the wireless and choose not to remove it.

To be a professional is to have a duty to refuse to do stupid stuff like this, even if it's legal and even if your job depends on it. But is it legal? Why would we need any new laws for this? Connecting a wireless receiver to the same network that controls a car's brakes and steering seems to me like reckless endangerment. No need to wait for innocent people to die.

If history has shown us anything, it's that we cannot rely on software to separate two systems sharing a network. Only physics can do that. If we must have wireless for entertainment, then the entertainment and vehicle control networks must be air-gapped.

This seems blindingly obvious to me. What am I missing?

<comment><USER28> Criminal negligence is a high bar. We don't want to send people to jail for mistakes, accidents and miscalculations.

Civil liability is a lower bar. Regular negligence is essentially not using reasonable care. Whether air-gaping a cars computer is reasonable car would be up for debate. But I think you'd have a good case.

Product liability is similar to negligence. It holds the builder, designers, sellers, etc. liable for design defects. But I'm not familiar with caselaw about how hacking vulnerabilities intersect with design flaws.

>If history has shown us anything, it's that we cannot rely on software to separate two systems sharing a network. Only physics can do that.

Yet, a shocking number of critical systems are exposed to the internet.

</comment></comment><comment><USER29> "...whether the Internet-connected computers were properly isolated from critical driving systems, and whether those critical systems had "cyberphysical" components—whether digital commands could trigger physical actions like turning the wheel or activating brakes."

Shouldn't this be the most basic design consideration for any company building autos? The liability from litigation should bankrupt any company that doesn't prioritize this.

<comment><USER30> Hell i thought an airgap would have been the first thing to occur. Why would you need wireless access to non entertainment systems?

It honestly beggars belief in my opinion.

<comment><USER31> Remote start via cell phone is a very marketable feature.

Once you get there, doing things like turning on the heat or AC are nice tack ons.

<comment> jon-wood Remote start I can see the reasoning for, but remote stop just seems to be asking for trouble.

<comment><USER13> The obvious but security-oblivious way to do this is to just connect the entertainment system that has the internet connection to one of the car's microcontroller busses. Even if it just needs to send a single command, it's easier than adding another pin and another wire to the appropriate microcontroller on the other end. The problem is that everything on these busses is completely trusted, and there's no authentication. The window motor can't tell whether the signal to roll down the window came from a switch or from the entertainment system.

The simple solution is just to have a separate wire for everything, and source devices that aren't supposed to control destination devices don't get those wires connected. The problem is that the automakers went to microcontroller busses because this creates a rats nest of wires.

The level 2 solution is have some sort of low-level filtering on the commands that are going out from a controller on the bus, so any command that the entertainment system sends to turn off the transmission doesn't make it onto the bus.

The level 3 solution is to have some sort of cryptographic authentication of entities on the bus, so that the endpoint can decide what commands it's going to accept from what source.

As you go from level 1 to level 2 to level 3, the system is more flexible, adaptable, and upgradable, but it's more complex, and thus more brittle to attack. Sorting out how to handle this sort of thing is going to be a big challenge as IoT pushes into more devices.

<comment><USER32> Encrypted and authenticated data on the bus won't happen anytime soon for cost reasons. Filtering the commands the controller can put on the bus seams reasonable, but would only be useful, if implemented on a second controller (probably won't happen, either).

I think the best approach is to secure the internet connection properly. Don't permit incoming connections at all and just permit a single outgoing TLS connection to the server of the manufacturer, define a very simple protocol and spend enough time to be sure the client is secure and validates everything.

<comment><USER33> "outgoing TLS connection to the server of the manufacturer"

That is one of the principles of how Audi's system operates for security reasons.

<comment><USER32> Interesting. It's the Blackberry way and generally a good idea.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> Given that cars get recalled all the time for "this one part is kind of flimsy and might break 3% of the time", I am not sure why "some guy in China can drive your car off a cliff" is not grounds for an immediate and full recall.

If you talk to auto manufacturers in a way that they understand, they will understand.

</comment><comment><USER34> "Toyota, in particular, argued that its systems were "robust and secure" against wireless attacks."

That's what they said about unintended acceleration. It turned out they were lying. [http://www.edn.com/design/automotive/4423428/Toyota-s- killer...](http://www.edn.com/design/automotive/4423428/Toyota-s-killer- firmware--Bad-design-and-its-consequences)

</comment><comment><USER35> Previous research on this topic from 2010:

[http://www.autosec.org/pubs/cars- oakland2010.pdf6](http://www.autosec.org/pubs/cars-oakland2010.pdf6)

Experimental Security Analysis of a Modern Automobile

"Even at speeds of up to 40 MPH on the runway, the attack packets had their intended effect, whether it was honking the horn, killing the engine, preventing the car from restarting, or blasting the heat. ... In particular, we were able to release the brakes and actually prevent our driver from braking; no amount of pressure on the brake pedal was able to activate the brakes. Even though we expected this effect, reversed it quickly, and had a safety mechanism in place, it was still a frightening experience for our driver."

<comment><USER33> There is an extraneous "6" at the end of the paper url, it should instead be:

[http://www.autosec.org/pubs/cars- oakland2010.pdf](http://www.autosec.org/pubs/cars-oakland2010.pdf)

</comment></comment><comment><USER36> Please take a moment to write the NHTSA about this hack and ask them to issue a recall for the affected vehicles.

[http://www.nhtsa.gov/Contact](http://www.nhtsa.gov/Contact)

<comment><USER33> I don't know if it will do much good, even if it did eventually lead to a recall, FCA (parent of Jeep) is under investigation by the NHTSA for allegedly poor handling of recalls.

[http://www.detroitnews.com/story/business/autos/chrysler/201...](http://www.detroitnews.com/story/business/autos/chrysler/2015/05/18/nhtsa- fiat-chrysler/27531693/)

</comment></comment><comment><USER37> I revisited this thread and thought: How would I go about running these tests and creating awareness for this issue?

A dynamometer would cover the vast majority of what they wanted to show. There was no need to create the danger they created with this vehicle. They really didn't know how the driver would react, "don't freak out" guarantees nothing. A professional driver (like a stunt driver) would have been far more appropriate.

The business about disabling the breaks should have been done a pile of hay bundles or something like that in front of the car.

For exposure they could have contacted any number of TV stations or networks who would have jumped on this immediately.

In all, the choices they made were reckless, stupid, dangerous and potentially criminal. I don't doubt their tech credentials at all. They are tech-smart people, no question about that. However, they have proven, beyond a reasonable doubt, that they are poster children for that stereotype of socially clueless engineers and/or the other stereotype of scientists/engineers who are so into what they are doing that they are completely blind to the idea that they could seriously harm people through their careless actions or inaction.

</comment><comment><USER7> Wow. Just because you are savvy enough to do the research does not make you a researcher. These two really need to rethink the way they are "testing" this and perhaps educate themselves on ethics in research.

Their judgement collectively was worse than a pack of 5th graders with high grade fireworks.

<comment><USER25> I don't think you understand. Anyone in the world can do this. Right now. Any time.

<comment><USER7> Anyone could shoot up a public place... should amateur researches be showing up in malls with firearms to test preparedness?

This case is even worse the the one I mentioned as there is a really easy way to safely demonstrate this exploit.

<comment><USER25> If it were not demonstrated under real conditions, the car companies would just say "this was a fake test not representative of real-world conditions, isn't that true Mr. Journalist?" and the journalist would have to admit that that was true and then they would say "Under real-world conditions our cars are safe; customers have nothing to worry about."

This has been their playbook about everything for a long time so I don't know why you think it would be different in this case.

<comment><USER38> There is no way a "not real-world conditions" argument could be made if this same test was done on a test track. No automaker would even try it because it would generate even more bad press. The "researchers" did the test on a public, in-use highway for better press/cool factor. Completely irresponsible.

<comment><USER25> Look at what Toyota did with the whole unintentional acceleration thing. About as irresponsible as you can get.

<comment><USER28> The ones that turned out to be mostly old people hitting the gas instead of the accelerator?

<comment><USER39> Yeah, no. Check this out: [http://www.edn.com/design/automotive/4423428/Toyota-s- killer...](http://www.edn.com/design/automotive/4423428/Toyota-s-killer- firmware--Bad-design-and-its-consequences)

<comment><USER40> Interesting! How does Toyota's code compare to other car manufacturers?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER41> This is very serious, because it can be used on a large scale and has terrorism potential. This could be used to kill people or disrupt an entire city. Where's Homeland Security on this? This is their job.

Meanwhile, __do not buy a Chrysler product with the "connectivity group" __. It 's an option that costs about $500-$600.

</comment><comment><USER42> So if I'm understanding this correctly, the initial vulnerability is remote- exploitable and relies on a firmware patch. Why wouldn't the manufacturer use the same exploit to patch all affected vehicles rather than calling them in for service?

<comment><USER31> Presumably they lack permission to do such a thing.

The researchers only experimented on a car they owned/controlled.

<comment><USER42> The manufacturer presumably has permission to do so. As for the attackers patching vulnerable vehicles, I hadn't thought of that, but of course that's a possibility as well. Pretty much the definition of white hat. :)

<comment><USER31> Yeah, it appears they do:

[http://www.driveuconnect.com/terms/](http://www.driveuconnect.com/terms/)

(term 17)

</comment></comment></comment></comment><comment><USER43> I'm baffled (reporting ethics aside).

One would think that car industry would be the one which has learnt about road safety the hard way. That experience should have manifested into extreme caution when adopting and implementing anything new, open and complex.

Sadly it is starting to look that everything they learn, they do by trial and error. Not by doing those things we take for granted from engineering and IT perspective.

</comment><comment><USER44> Every single highway crash involving a loss of control is now potentially a high-end assassination, including those that have taken place in the last few years.

How many people do you think will be murdered this way before investigators and the justice system catch up?

</comment><comment><USER45> When I studied real time systems, it was clear that critical systems (in this case the brakes, accelerator, wheel) needed to be in a physically separate network from non-critical ones (music, air conditioning). I guess it must be cheaper to build all in a single network, but it sounds irresponsible.

Also, this test should not have been done in a public road. That was irresponsible.

<comment><USER33> There often are multiple CAN buses (though there is a push to a single high speed bus) and the ECU (or BCM and so on) are supposed to make sure the commands are safe. In practice they often communicate with one another (manufactures want to sell features like remote start or use cheaper system such as electric parking brake) and the module does not do as much verification as it should.

</comment></comment><comment><USER46> > _The most disturbing maneuver came when they cut the Jeep's brakes, leaving > me frantically pumping the pedal as the 2-ton SUV slid uncontrollably into a > ditch_

I was in that situation. No brakes, high rocks on one side, 100 meters cliff on other side, 20km of downhill in front off me. I guess I will not be buying Jeep anytime soon.

<comment><USER47> If you think that "drive-by-wire" is a specifically-Jeep problem, I've got some bad news for you....

It is a safe assumption that these guys just happened to use a Jeep, and with some work almost any modern car could have this done to it.

</comment></comment><comment><USER48> Does Wired really wonder why so many of their readers have ad blocking software? [1] I can't even read the article on their website because every ad I see is covering up some sort of text of the article. None of the ads have a close, hide, or dismiss button either so I can't just go and hide them.

[1]: [http://i.imgur.com/IZymUKm.png](http://i.imgur.com/IZymUKm.png) [2]: [http://i.imgur.com/C7LiA60.png](http://i.imgur.com/C7LiA60.png)

<comment><USER49> Something is wrong with your browser or screen resolution. The page renders fine in Chrome with no artifacts like that, etc.

</comment></comment><comment><USER50> This is scary. Malice or incompetence I think it's unacceptable for systems handling the breaks and other crucial functions of the car to be anywhere close to interacting with internet connection. I am going to stick to old style cars for a while. This is really scary.

</comment><comment><USER51> I'm not going to comment on the question of whether or not the highway patrol should have been called or not - just say I understand where poster tombrossman was coming from.

However, I fully agree this was a ridiculous stunt. They could have gotten the same results by demonstrating (on the highway, if they insisted) the air conditioner going full blast, the radio, and the picture of the hackers on the screen. Anything else (cutting transmission, obscuring visibility) should have been saved for a safer environment. The point still would have been made.

And it's got nothing to do with the vehicle and driver itself (though I wonder how the hackers knew the exact driving situation - was it plastered with cameras?) - what if two unrelated vehicles got in an accident for some reason and the test driver had to get out of the way, but couldn't?

And to make it worse, the cranked radio made it hard for the tester to communicate with the hackers. Very dangerous stunt.

Also, and I know it was unrelated to this particular hack, but if the UConnect recognizes voice commands (I assume so), and sends it back for processing, then might it not also be able to bug (eavesdrop) on the car's interior?

Many disturbing revelations came out of this, and I applaud them for making it known, but I criticize them harshly for the cavalier way they endangered public safety.

</comment><comment><USER23> I feel like, public safety aside, people should be mad at these researchers because they give credibility to every ignorant politician, prosecutor, or journalist out there who says that all hackers threaten the public good. How are you supposed to draw a line between blackhat and ethical hackers when the "ethical" ones endanger public safety all the same?

</comment><comment><USER52> Well luckily my Chrysler despite only being a year old does not have this connectivity. It does have Uconnect which I despise, I keep contacting Chrysler to demand that they offer the ability to use Apple Carplay or the Google equivalent. To be fair there has yet to be a vehicle that has a nice easy to use controls for radio or media.

<comment><USER53> Same situation, same sentiment. Chrysler is apparently "on the list" for CarPlay compatibility, but across all marquees, there are only two cars you can buy _today_ that have it installed, and both are Ferraris. (The 2015 Volvo XC90 may have some form of CarPlay "preparation".) Don't hold your breath for backwards compatibility.

All I really want is two things:

1\. The Voice button on my steering wheel to activate Siri. (Not the _horrible_ UConnect voice assist.)

2\. Waze maps on screen. (UConnect navigation is shit and not worth the price.)

</comment></comment><comment><USER54> As big of dicks as these researchers are, I just have to say, to anyone out there working on software to run cars, airplanes, robots, other mobile vehicles ... some day, within the next 5 or 25 years, it's pretty likely some nut job is going to use an exploit take control of one or more of these vehicles and crash them/use them as remote-controlled / swarm weapons, possibly killing lots of people.

If you're writing that software, make sure you do a really, really good job on security. Because no one wants to be the guy 'git blame' shows wrote the exploitable feature that led to ??? deaths.

The industry really should have stringent standards that prevent ridiculous breaches like this, I would say as well as simulators (or physical demo vehicles) available online/open source that people can pen-test against and win prize money. And maybe write all the code in Rust?

</comment><comment><USER55> I don't get it. Everyone seems to be either upset at the researchers for their test or defending them. Why is no one upset at car companies putting tech in our cars that allows for remote shutdown of said car. Is this what we bailed them out for?

</comment><comment><USER56> Hopefully people selling armored cars and armored trucks have good pen testers on their teams. Run flat tires and armor-plated doors don't help much if an attacker can shut down the engine and open the doors remotely.

</comment><comment><USER57> I own a 2015 Jeep Cherokee and have poked around with Uconnect and the API services it exposes. Theres a whole new world of exploitation (and eventually modding) that is coming.

</comment><comment><USER49> Hah, I found it really funny as I scrolled down there's a big ad for a Fiat in the article: [http://i.imgur.com/rSyYPO4.png](http://i.imgur.com/rSyYPO4.png) Fiat owns Chrysler who owns Jeep... maybe not the best marketing idea to advertise your cars in an article about exploiting them with potentially catastrophic results.

</comment><comment><USER58> Good luck trying to hack my 1971 Volskwagen.

</comment><comment><USER59> _The two researchers say that even if their code makes it easier for malicious hackers to attack unpatched Jeeps, the release is nonetheless warranted because it allows their work to be proven through peer review._

Huh? If they have a video of their turning a care off remotely, do they really need peer review of the details?

<comment><USER33> Yes, there have been numerous times when security researchers show video and then the peanut gallery argues if it was staged or not. There is just no way to be sure otherwise.

<comment><USER59> OK. Then you put a journalist in the video, who makes sure it wasn't staged, and we trust them because their careers depend on their integrity.

</comment></comment></comment><comment><USER60> Research can be done to drive a point without making that into a drama. you can demonstrate the science without the hollywood so to speak. I think what was done here could have been demonstrated without the risk that was taken. I think the risk that was taken was poor judgement.

</comment><comment><USER61> I think a basic idea should be: panic stops disconnect all wireless access.

Which will probably result in lots of calls from people after they avoid hitting a dog. But still.

<comment><USER62> Disconnecting will not restore corrupted firmware. Once virus is there, disconnecting just prevents data transfer.

<comment><USER61> Exactly. But at least you'd break the current control link and possibly/hopefully be able to stop and steer.

Maybe in addition to breaking a link on a panic stop, stopping and steering would be set to a non-commanded mode that relies less or not at all (maybe impossible with current design?) on software commands.

<comment><USER31> The malicious firmware could just omit all that stuff.

I guess the disconnect could be physical/mechanical and require physical intervention to reconnect (but cost, etc.).

</comment></comment></comment></comment><comment><USER63> I'm willing to bet FCA wil recall all of these "UConnect" enabled vehicles within a month to patch this. This will blow up fast.

<comment><USER33> You might lose some money:

[http://www.detroitnews.com/story/business/autos/chrysler/201...](http://www.detroitnews.com/story/business/autos/chrysler/2015/05/18/nhtsa- fiat-chrysler/27531693/)

There is a patch available, but that is not a recall. A recall takes some time under the best circumstances and FCA pushes back hard on expensive ones.

<comment><USER63> The feds have been breathing down their necks lately due to too many defects. I'm sure they brought the hammer down hard (behind the scenes) on this one, thus forcing them to announce the recall this morning.

<comment><USER33> I just saw the news and came here to say you would have made a great bet, cheers!

</comment></comment></comment></comment><comment><USER64> Anything connected on the internet is hackable. We've seen this time after time, so I'm not surprised.

</comment><comment><USER65> That was a lot of uninformative text to plow though...

Apparently someone has found a remote exploit that affects some model of Jeep. It requires an attacker to find the IP address of the Jeep. Which implies that a Jeep has an IP address. The communication between the Jeep and the world is something called Uconnect.

<comment><USER66> They've also found a way to scan the Sprint network for cars connected to Uconnect and retrieve the cars' VIN and location.

<comment><USER67> I'm still curious if this can be done without physical access to the car in advance. The last time one of these showed up, it was very understated that all the remote access stuff involved reprogramming an ECU and plugging in a phone you control.

The article doesn't provide any clear information on whether this works purely remotely.

EDIT: Scrap that, seems it does - weird that the article doesn't lead with that more prominently. In which case _wow_ \- pinging the network and grabbing GPS coordinates for cars?

</comment></comment></comment><comment><USER68> It's weird that they said the demonstration wouldn't be life threatening when it actually was.

</comment><comment><USER69> There's a patch available for this already: [http://www.wired.com/2015/07/patch-chrysler-vehicle-now- wire...](http://www.wired.com/2015/07/patch-chrysler-vehicle-now-wireless- hacking-technique/)

</comment><comment><USER70> Good research by the hackers, stupid execution.

Calling the police was indeed the right thing to do.

Maybe next time, the hackers can test on the vehicles driven by the car executives, while they are driving, have their family in the car with them, etc.

Can't wait to see that comment thread...

</comment><comment> andrey-g I recall that last time they used a piece of hardware to connect to the CAN bus via cellular. Are they now able to control the CAN bus via the infotainment system? Does it have it's own cellular transmitter?

</comment><comment><USER71> Ok, so if the Dodge Dart and the Alfa Romeo Giulietta are built on the same platform , do they share the same vulnerability in the computer systems?

or is it more about the Uconnect than anything else ?

</comment><comment> a-dub meh. cars stall all the time. if they hadn't gone for the freakout factor with the reporter, there wouldn't be high profile press, embarrassed automotive executives and politicians scrambling to get a handle on the issue.

the real issue is that the automakers are producing fundamentally dangerous vehicles and the federal government is allowing it. these vehicles could be exploited maliciously to cause serious physical harm or death.

this is actually a problem. not some onetime stall of a jeep on the highway.

</comment><comment><USER72> Did anyone bother to read the full article? If so, you would find out that it was a [somewhat] controlled experiment.

> To better simulate the experience of driving a vehicle while it's being > hijacked by an invisible, virtual force, Miller and Valasek refused to tell > me ahead of time what kinds of attacks they planned to launch from Miller's > laptop in his house 10 miles west.

> Instead, they merely assured me that they wouldn't do anything life- > threatening.

> Then they told me to drive the Jeep onto the highway. "Remember, Andy," > Miller had said through my iPhone's speaker just before I pulled onto the > Interstate 64 on-ramp, "no matter what happens, don't panic."

<comment><USER73> be sure to check out the video [http://dp8hsntg6do36.cloudfront.net/55ad80d461646d4db7000005...](http://dp8hsntg6do36.cloudfront.net/55ad80d461646d4db7000005/9aca04ce-083b-4756-bda9-a37a148bf90flow.webm)

<comment><USER72> All right, I concede. I did not watch the video but only read the article - that was a bit insane of them.

When I read the article, in my mind, I pictured them driving the car on an empty-ish highway/road. That was clearly not the case.

</comment></comment></comment><comment><USER74> Surprising the comments critical of how the test was performed publicly equate exploitation with guns:

> How about they remotely poke around your husband or wife's car and explore, > as long as they promise not to intentionally trigger anything?

> Calling the cops on a loud neighbor might not be acceptable, but calling the > cops on a neighbor firing a gun in the general direction of your house > certainly would be.

> Anyone could shoot up a public place... should amateur researches be showing > up in malls with firearms to test preparedness?

The lack of sound judgement _and_ arguments is astounding.

</comment><comment><USER75> Last wired on this was kinda bullshit - they let the researchers install a system on the CAN bus. Was this a legit wireless takeover?

</comment><comment><USER76> >> The attacker's PC had been wired into the vehicles' onboard diagnostic port, a feature that normally gives repair technicians access to information about the car's electronically controlled systems.

Is this even really considered an issue?

<comment><USER31> Here's the context:

 _Back then, however, their hacks had a comforting limitation: The attacker's PC had been wired into the vehicles' onboard diagnostic port, a feature that normally gives repair technicians access to information about the car's electronically controlled systems.

A mere two years later, that carjacking has gone wireless._

So the issue is right there in the surrounding text.

</comment></comment><comment><USER77> So, a HN commentator apparently called the cops on these guys after reading the Wired article.

Several commentators more or less agree, arguing that performing these tests on the I-40 was criminally negligent.

Stop right there. Grow some balls. These guys are elite, their demo was badass, and I've done stupider things on I-40 _for no reason_.

And wtf you called the cops? _head in hand_

<comment><USER78> > These guys are elite, their demo was badass, and I've done stupider things > on I-40 for no reason.

"Elite," seriously? Is it 1995? Is the movie "Hackers" some type of inspiration to you? I'm almost surprised you didn't go all l33t speak.

They endangered people's lives. It is as simple as that. If you too endanger people's lives "for no reason" on I-40 I hope they get you too.

<comment><USER77> They demonstrated that hackers can take lives using a laptop and a cell phone. And they displayed their own picture on the dashboard screen while doing it.

Yes, elite. I'm not bringing it back; they already did.

<comment> squeaky-clean They could have demonstrated that in a closed parking lot, and not a real highway.</comment></comment></comment></comment>


Detroit Lives - the unseen story - <AUTHOR> http://www.palladiumboots.com/exploration/detroit

<comment><AUTHOR> I'm a proud fifth generation Detroiter. This is the story that does not get told.

There are big opportunities for enterpreneurs along with even bigger risks. Like the guy in the video says, "where is else is a 24 year old going to be handed a nine story building?"</comment>


Baseline - a designer framework - <AUTHOR> http://baselinecss.com/ <comment><USER2> Looks interesting, but no support for IE6 and IE7 can be a deal-breaker for many users, especially when there's 960gs (<http://960.gs>) which supports those browsers.

<comment><USER3> as someone who deals with the front end for a company whose business is a web app, no support for ie6 (with patch files, conditionals, whatever) really is a deal breaker. the sad fact is 15% of our customers still use ie6.

draw your own conclusions, but those customers generate significantly higher revenues per customer than those who use modern/semi-recent browsers.

960s is great.

</comment></comment><comment><USER4> What's a "designer framework" anyway? I would just call this a template...

<comment><USER5> A template typically has a set page layout, this allows you to create your own layout.

</comment></comment><comment><USER6> It looks great. Needs some more work to correct some of the shortcomings mentioned below and will fly.

</comment><comment><USER7> YUI includes a similar-looking baseline framework.

Anyone care to compare the two?

</comment><comment><USER8> yet another css framework... What I want is a UI framework for web apps (forms, menus, modal windows, etc.) such as the ones for iPhone development

<comment><USER9> Maybe qooxdoo is what you are looking for? It looks a little bit desktopy for me, but I haven't taken a close look at it.

<http://qooxdoo.org>

<comment><USER10> There is also extjs (<http://extjs.com/>)</comment></comment></comment>


Mathematicians Are Stunned by This Chicago Professor's New Proof - <AUTHOR> http://www.chicagomag.com/city-life/October-2015/Why-Computer-Scientists-and-Mathematicians-Are-Stunned-By-a-Chicago-Professors-New-Proof/?utm_source=Twitter&utm_medium=referral&utm_campaign=Reader+tweet+mobile+reveal+bar+28668+Dec%2031%202015%2009:38 <comment><USER2> It's true that this is a really, really big theoretical advance, but it has almost _zero_ impact on P vs NP. It's been believed for a long time that graph isomorphism is "close to P" for some suitable definitions.

And this story has been discussion here on HN many many times over the past few weeks.

So this is a nice article about a seriously major breakthrough, but take all the P vs NP speculation with a huge handful of salt.

</comment><comment></comment><comment>====

Discussions:

[https://news.ycombinator.com/item?id=10731022](https://news.ycombinator.com/item?id=10731022) (75 comments)

       Landmark Algorithm Breaks 30-Year Impasse (quantamagazine.org)

[https://news.ycombinator.com/item?id=10505231](https://news.ycombinator.com/item?id=10505231) (41 comments)

       Quasi-Polynomial Algorithm for Graph Isomorphism (scottaaronson.com)

[https://news.ycombinator.com/item?id=10553879](https://news.ycombinator.com/item?id=10553879) (33 comments)

       A Quasipolynomial Time Algorithm for Graph Isomorphism: The Details (jeremykun.com)

[https://news.ycombinator.com/item?id=10610361](https://news.ycombinator.com/item?id=10610361) (3 comments)

       A Little More on the Graph Isomorphism Algorithm (rjlipton.wordpress.com)

</comment><comment></comment><comment>====

Here are some of the other submissions:

[https://news.ycombinator.com/item?id=10504883](https://news.ycombinator.com/item?id=10504883)

       Graph Isomorphism in Quasi Polynominal Time
       (calendar.google.com)

[https://news.ycombinator.com/item?id=10506476](https://news.ycombinator.com/item?id=10506476)

       Graph Isomorphism in Quasi-polynomial time
       (uchicago.edu)

[https://news.ycombinator.com/item?id=10508418](https://news.ycombinator.com/item?id=10508418)

       Laci Babai and Graph Isomorphism
       (lucatrevisan.wordpress.com)

[https://news.ycombinator.com/item?id=10512074](https://news.ycombinator.com/item?id=10512074)

       A Big Result On Graph Isomorphism
       (rjlipton.wordpress.com)

[https://news.ycombinator.com/item?id=10542464](https://news.ycombinator.com/item?id=10542464)

       The world's fastest isomorphism testing
       program (1993) (stonybrook.edu)

[https://news.ycombinator.com/item?id=10547501](https://news.ycombinator.com/item?id=10547501)

       Summary of Babai's Breakthrough on Graph
       Isomorphism (reddit.com)

[https://news.ycombinator.com/item?id=10547881](https://news.ycombinator.com/item?id=10547881)

       Babai's Breakthrough on Graph Isomorphism
       (reddit.com)

[https://news.ycombinator.com/item?id=10553139](https://news.ycombinator.com/item?id=10553139)

       New algorithm efficiently solves graph isomorphism
       problem (sciencenews.org)

[https://news.ycombinator.com/item?id=10553152](https://news.ycombinator.com/item?id=10553152)

       Graph Isomorphism in Quasipolynomial Time
       (uchicago.edu)

[https://news.ycombinator.com/item?id=10562857](https://news.ycombinator.com/item?id=10562857)

       Solution to graph isomorphism problem found,
       improves understanding of P and NP (sciencenews.org)

[https://news.ycombinator.com/item?id=10565125](https://news.ycombinator.com/item?id=10565125)

       Claimed breakthrough in graph isomorphism
       algorithm (technologyreview.com)

[https://news.ycombinator.com/item?id=10601316](https://news.ycombinator.com/item?id=10601316)

       Graph Isomorphism in Quasipolynomial Time I [video]
       (uchicago.edu)

[https://news.ycombinator.com/item?id=10634234](https://news.ycombinator.com/item?id=10634234)

       László Babai Claims Quasipolynomial Algorithm
       for Graph Isomorphism (aperiodical.com)

[https://news.ycombinator.com/item?id=10687741](https://news.ycombinator.com/item?id=10687741)

       Laszlo Babai's Talk on His Quasipolynomial
       Time Algorithm for Graph Isomorphism (uchicago.edu)

[https://news.ycombinator.com/item?id=10729128](https://news.ycombinator.com/item?id=10729128)

       Graph Isomorphism in Quasipolynomial Time
       (Babai's Preprint) (arxiv.org)

[https://news.ycombinator.com/item?id=10730670](https://news.ycombinator.com/item?id=10730670)

       Graph Isomorphism in Quasipolynomial Time
       (arxiv.org)

[https://news.ycombinator.com/item?id=10735861](https://news.ycombinator.com/item?id=10735861)

       Graph isomorphism is quasi-polynomial time
       by Laci Babai (arxiv.org)

[https://news.ycombinator.com/item?id=10737655](https://news.ycombinator.com/item?id=10737655)

       Algorithm Solves Graph Isomorphism in Record
       Time (quantamagazine.org)

[https://news.ycombinator.com/item?id=10786874](https://news.ycombinator.com/item?id=10786874)

       Graph Isomorphism in Quasipolynomial Time
       (arxiv.org)

<comment><USER3> Thank you for spending so much time on this and other reference-cleanup and dupe-cleanup efforts; it can be a pretty thankless job in my experience.</comment></comment>


Honeycomb Has A Fighting Chance Against The iPad - <AUTHOR> http://techcrunch.com/2011/05/15/honeycomb-has-a-fighting-chance-against-the-ipad/

<comment><USER2> I don't know why this should come as a surprise. All the arguments that I've seen that somehow the iPad will avoid the same fate as the (still highly successful but not market leader in OS) iPhone have been weak, pushed mostly by people who have a stake in its success. It is extremely hard to beat a competent and _good_ platform so willing to allow any company to succeed and do what they will with the platform. It comes down to the simple fact it is essentially Apple vs. the rest of industry (minus a few outliers). Not even Apple can do that. They came close with MP3 players, but tablets are much more dangerous; they are a PC market disruptor, not a Walkman disruptor. So far it seems all of those companies are willing to bet on Android. And considering Android is lead by a software team willing to iterate furiously and have some sort of quality, I have little doubt they will take the lead in the tablet space.

<comment><USER3> Don't forget that carriers will always push anything non-Apple simply because they make more money that way. I've heard several people now say that they chose an Android device because they "don't have an Apple computer, so in that case it's better to go Android." I think that's becoming the standard way salesmen are going right now.

</comment></comment><comment><USER4> The litmus test for a tablet to me is, "Why would I buy one of these when I could just buy an iPad?". As of yet, there is not a single competing tablet with a good answer to this question, and Mr. Kincaid is unable to provide one in this article, in spite of his desperate attempt. In fact, he pretty much just reiterates the problems that all of the reviews for non-iPad tablets have already presented: performance problems, "buggy as hell", not enough apps optimized for the form factor. Why do these guys think that out of the blue, Android tablets are going to just miraculously going to start being great?

<comment><USER5> > Why do these guys think that out of the blue, Android tablets are going to > just miraculously going to start being great?

Possibly because that's exactly what happened with Android phones? Some of the early Android phones (G1, Hero, etc) were pretty buggy, slow, and kind of wonky. The original Droid was decent, then the N1 came out and was seriously competitive. And there's been basically a string of steadily improving models since then.

It seems reasonable to assume the Android tablet market will proceed similarly.

<comment><USER6> Android, including the N1, never stopped being buggy as hell, though. Froyo made wifi flaky, 126.96.36.199 made Gmail flaky, Cisco VPN support never got implemented, etc.

Using Android requires a continuous effort to search for workarounds

<comment><USER5> That's a lode of horse shit.

My N1 and my wife's have both been rock solid.

And by Cisco VPN, do you mean IPSEC? Or Cisco's proprietary SSL VPN?

</comment></comment></comment></comment><comment><USER7> I strongly feel that just like the iPhone, the iPad will be the gold standard for tablets. And just like the iPhone, it will have competition from an open challenger.

However, in the case of tablet, I strongly feel that the challenger is NOT android. Android works well on a phone, but a tablet is a different experience and it needs certain design elements which, frankly, Google has not proven capable of doing.

I have no doubt the challenger will be linux based, but it seems more likely that the it will be someone with a design and usability bent rather than technical-only acumen.

However, all of the challengers could be undone if they cannot play well with quality apps. Getting developers to your platform is absolutely key.

<comment><USER8> You don't actually provide any examples of what you're talking about, so it's hard to say what you're actually saying, making your post mostly useless fluff.

</comment></comment><comment><USER9> Not to be shackled to iTunes is more than enough reasons for me to get a Honeycomb tablet.

</comment><comment><USER10> i like the android tablets more than ipad for the same reason i like android devices more than the iphone: customization. android gives the user credit for being smart and recognizes we don't all want our phones to look and act exactly the same. what a boring world it would be if we all had apple devices. android is my little buddy that can be setup and function in the way that is best for me...not steve jobs.

<comment><USER11> I am not an android user so do not know. What kind of customization is possible with Android? I am assuming you are not talking about apps as the apps available for Android are also available for the iPhone.

<comment><USER10> just think of all the stuff you wish you could do with your ipad, and that's pretty much what android tablets can do.

widgets & hardware support via USB come to mind immediately, but there is much more.

<comment><USER11> Could you please elaborate? I am curious. I do not even follow your widgets and hardware support point.

<comment><USER10> that's exactly my point. you dont know what these things are because you use an ipad. there is a whole other world out there. if you don't know what widgets or usb hardware support is, google it.

<comment><USER11> You did not make any point. You also assumed I am an iPhone user. Anyway I was not trying to grill you, I was genuinely curious. Nice to know you are enjoying your android phone.

<comment><USER12> I'm not sure why the gp is avoiding the issue.

Live widgets on home screens are great. They give you interactivity and live updates without having to enter an app. So things like weather, news, calendars, etc.

The home screen in general is a lot more accessible to developers. E.g. I can add a shortcut to a contact on my homescreen that, when I tap it, opens up a small modal dialogue with quick access to phone calls, texts, emails, etc. I can alternatively add a shortcut that directly dials the contact with the first tap.

Another thing that I really like about Android over iOS is that developers have a lot more access to the settings of the phone than in iOS. This allows apps like Locale, which lets you set different contexts depending on different parameters such as location, time, battery level, orientation, etc. This allows me to set my phone to vibrate and turn off wifi when I leave the house for example. I no longer have to remember to set my phone to silent or any other such nonsense.

I fully acknowledge that there are many things iOS does better than Android, but these are the reasons that some people prefer Android, and they're for the most part just as true about tablets as phones.

<comment><USER11> Thanks! I did not know the widgets on the home screen can be modified by developers. That could be really useful. Very good to know.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Once again, VHS beats Betamax?</comment>