Ditto - I'd like an application that makes it easy for me to access my files from the web. I'm happy to provide the LAMP/etc, but I don't want my files to just be floating out there for random company to access.
If Obama wanted an easy out he could have had it - the courts were about to throw DADT out the window, and his administration begged them not to. If he just stood back and did nothing the policy would be gone today.
The cynical side of me thinks that DADT is kept around so that the D's can keep campaigning on it, just like how abortion was kept around so that the R's could keep campaigning on that. If politicians actually cared about these kinds of issues you'd see them do something about - there have been plenty of times in the last decade where one party controlled the white house and both houses of congress, and that applies to either party.
These are sideline issues to politicians - useful for drumming up supporters on election day, but nothing they really care about.
That doesn't help when the user jailbreaks it and the new OS doesn't have the same capabilities as the OS you audited.
The solution is to simply issue your own hardware and make employee tampering a terminable offense. I'd fully support that as long as the company provided the device and its plan.
If I get to provide the device, then I get to decide what security policies it implements, and what policies it lies about implementing. Don't like that? Simple, stop sending me email after 5PM...
Yup. I could make a killing if I sold an Email app that spoofs whatever is most common in major corps but which silently ignores the security policies.
If employers want to control the phone, they should issue the phone. If they issue it, then they can be sure that it supports whatever features they need. They can reclaim and reissue phones once a quarter to reimage them or whatever for extra security.
The problem is that employers want employees to use their shiny toys to do work off-hours, without paying for them. However, they don't like the fact that they now lose control over the platform.
Yup. All of your problems would go away if the app asked for a list of permissions, and then you'd edit them to what you want to give. Obviously you can't revoke GPS since you'll get no value from the app, but you could just kill the network access.
Agreed - you should be able to tweak the permissions. So, if the app asks for location tracking, and you don't want to grant it, you can tell the OS to install the app but not let it know the location, rather than not install it at all. Of course, if you're installing a navigation app you'll have to accept that the app won't work. However, if you're installing an IM client maybe you don't want it to know where you are.
The API could make these kinds of situations work out so that applications don't have problems. If the app asks for a location just feed it someplace random. If an App asks for phone numbers give it some Obama's cell phone number, or whatever. In fact, bonus points if the OS lets you pick what kind of garbage you feed the app.
App makers will be less prone to pulling these kinds of stunts when all it does is corrupt their marketing databases.
I dunno - I always though the whole idea of being a free thinker is to do what is morally right in all circumstances, without regard to virtually anything else...
If the judge pulled out a statue passed by the legislature and signed by the governor that said that bisexuals who marry white girls ought to be jailed I'd smile and vote innocent without regard to the facts of the case. To do otherwise would be an act of injustice, without regard to the laws. If questioned regarding my reasoning I'd just say that I wasn't convinced that the guy married her, or whatever, and that I was following the directions of the judge to the letter.
I don't think that iPads ended up being in the corporate world because they were selected by IT as the best tool for some job. Typically some executive gets one for his birthday or whatever and now IT has to support it. Or, the head of IT buys one and pushes it out.
iPads are nice for browsing and consuming content, but horrible for creating it. However, most decision-makers in major business are net-consumers of information, so it may be well-suited to them. For the 100 worker bees generating the content that the 2 managers consume, they're probably not such a good fit unless they two are just data consumers.
Chrome OS could potentially be a good fit for a lightweight corporate client, with lots of security features that would appeal to that market. It just isn't quite done yet. Whether it will get done before it peters out is up for debate.
Uh, Win XP gets full security updates, and so does IE6. They'll both receive them until 2014. I doubt that any android phone on sale today will still be getting security updates in 2014, and many won't be getting them this time next year.
Windows has its issues, but MS gets tons of money from the corporate market, and long ago it figured out that this means supporting products for VERY long times.
Uh, 17% is A LOT of devices. Most phones more than a year old aren't on the latest and greatest version of android, and may never be. Most of them are susceptible to a security flaw discovered a few weeks ago, and do you think that most of these phones will ever see an update?
So, unless a company expects their employees to buy a new $500 smartphone every year, they can't expect them to run the latest and greatest android OS version.
Sure, Apple doesn't release new OSes for their oldest iPhone model either, but they didn't drop support for 3+ years - which is a far cry from one year. I'm not a fan of Apple, but they do support their hardware for a fairly long time - about the only vendor who does for longer is Microsoft (say what you will about Microsoft, but they STILL support windows XP - find any linux vendor still publishing security updates for a product released in 2000).
I love Android and plan to stick with it, but mostly because I'm not chained to the support provided by my vendor (I'm running 2.2 on a phone whose last vendor update was 1.6).
Ok, if CO2 levels become a limiting factor in office size I'm definitely starting my own business...
BTW, businesses would be more than happy to pipe in O2 and water/etc and pipe out waste if they could get away with having their workers jacked into the matrix or whatever. They're more than happy to do that with cattle/etc. You'll never find a chicken in a farm that doesn't get enough water - they could care less if there is room for it to take two steps, but they certainly care that it develops enough meat to sell.
Yup - this is also one of the reasons why the mass of a liter of water/etc was avoided as the basis for the kilogram. It is almost impossible to obtain water of any particular isotopic composition, and it varies around the world. Water is also non-ideal for other reasons as well which I won't get into...
So, the first half of your discussion is a great explanation of why the guys running those projects don't want to cooperate. It has nothing to do with why those of us paying the bill shouldn't force them to do so anyway.
The second half of your post was about the benefits of redundancy, and I'll agree with those. However, any discovery made by Fermilab certainly would be confirmed or refuted by the LHC once it is running again. I'm sure they'll get around to it before they give out the Nobel prizes, unless they decide to pull an Obama again.:)
The article stated that a big driver for continuing the search at current energies is that Fermilab is right on their heels and might find the Higgs first if they take a break for a year.
As I see it, the Higgs could fit into one of two energy ranges:
1. A range that the limited LHC and Fermilab can both probe now, with the LHC having some advantage. 2. A range that only the full LHC can reach.
If it falls into the latter, then nobody is discovering the Higgs for a few years until they get the LHC in gear. If it falls into #1, does it REALLY matter that much who finds it first?
If what we care about is the accumulation of knowledge then we should cooperate and not compete here. Retask the LHC for higher energies, and have Fermilab continue to explore the lower-energy space. This way we find the Higgs more quickly as we have two non-redundant operations working on the problem, rather than having one be completely redundant.
Also, who knows what other interesting physics we'll find at the higher LHC design energies, that we're just pushing off for years sticking where we are at now?
Can't the lead authors on the competing 1000-author papers maybe agree to pool their efforts, and settle for first and last on a 2000-author paper instead?:) Then we poor taxpayers footing the bill can at least feel like we're all getting SOMETHING for our money...
Well, it seems the point is that "always-on" isn't as reliable as you might think it is. In this case the author of the commentary expected to have continuous service, and ended up not having it.
I do agree that a netbook really isn't suited for travelling businessmen in general. However, when you consider being ultra-light, long battery life, and fully automatic backups and data sharing they would be the most to benefit if it actually worked.
I guess that is up to the consumer, but the parent was right that if having the latest and greatest OS version is important to a consumer, they're more likely to get that from Apple than any of the Android vendors.
That isn't the MOST important criteria, which is why I run Android. However, I am disappointed that in general an Android phone is almost completely de-supported a year from release. Heck - didn't somebody come up with some browser exploits for Android a month or so back and I haven't seen any news of updates for the G1 - they're starting to look like MS on their patch schedules...
Look, I like android. I own a G1. I run Cyanogenmod and all that (though it is starting to hit the boundaries of usability with v6+).
The fact is that HTC stopped supporting the G1 about a year after it was released. Everything since then required rooting the phone. In fact, HTC's design would not allow the Android to run anything newer than 1.6 - their design was imperfect which is what allowed it to be rooted.
I think that in the support-for-older-hardware category I have to give the win to Apple. They support their older hardware a LOT longer than any of the android vendors do. Even the true-blood ADP was deprecated basically at the same time as the G1 - before then it just got the updates a little sooner and didn't have to bypass vendor locks to root it (though ironically you need to put those locks in to take advantage of the newer firmwares that free up more RAM).
I'd still go with Android in the future, but I'm under no illusions that getting newer OS versions on the device a year after it is released won't require considerable hacking.
They don't need to modify any internal files. You just submit a file to a repository and get the maintainers to check it in. The file has to look innocuous to any inspection. Once they do that, you put instead a rogue version of that file with the same hash and size on your own mirror, and get somebody to use that mirror. You make sure the rogue file is signed by the official maintainers so that end-users trust your mirror. Since the hash matches you can just extract their signature and put it on your rogue file.
Now, for source file this isn't going to be very practical, since if I submit a file that is 100 lines of source followed by a 1000-line pile of random characters in a comment they're going to strip that out, defeating the attack. However, what about binary submissions.
Wait, you ask, who accepts binary submissions into an SCM? Well, check out any of the android distros - the phone manufacturers don't distribute source for some of their drivers, which means lots of binary blobs floating around. I'm sure they get checked into SCMs. All I need to do is say that I patched a blob to make some fix, and chances are somebody will accept it after testing. It is very easy to sneak a bunch of binary garbage in a binary blob - as long as you make sure that it isn't in the code path. If you're REALLY clever you might be able to put it in the code path - just look at any polymorphic virus.
Bottom line is that if your hash function allows pre-generated collisions LOTS of bad things can happen. Coming up with clever reasons why they're not likely to happen won't save you when it actually does happen.
Again, that is a lovely hypothesis, complete with proposed mechanisms/etc. However, I still haven't seen anything more than "well, that's how it happens in nature" as an explanation for why it couldn't be otherwise.
I'm sure the natural process exists for a reason - but it doesn't have to be the reason that everybody thinks that it is.
Are the passwords hashed when they are sent? I don't think the previous post was concerned about cookie theft, but rather password theft.
How does chrome sync your bookmarks? Simple - it has your Google account username and password stored locally on the machine. I'm sure it uses a cookie to bypass authentication when it can, but when that cookie expires it has to retransmit your username and password. Now, the question is how this is done. Obviously if they use https we're fine. If they use a challenge-response approach over http then the password is safe though the cookie is vulnerable. If they send the password in a form as plain text then anybody sniffing the connection has it.
I'm too lazy to sift through wireshark data to try to find my Chrome sync traffic, but I think this is a legitimate concern.
I was being facetious - 5-10 is WAY less than stuxnet took to get right.
I didn't even mention engineering support. If your goal is to destroy a nuclear reactor, how do you ensure that whatever you plan to have it do will destroy it? Chances are you either need to test it out on real reactor components, or gather data from people who have tested real components and have a good idea of how they perform, etc.
I imagine that when this worm hit things must have gotten pretty exciting in that bunker... Granted, I don't know what the worm actually does - if it just shuts things down then it would be no big deal. However, if I were trying to take out a facility the last thing I would have it do is an orderly shutdown...
I have no objections to this, although I doubt most employers would compensate for jury duty in such a future world.
Another option is to compel employers to pay for jury time, and have the government kick in a little extra.
Bottom line is that I'm fine if people make a little more with jury duty than their regular jobs. Then people will look forward to doing their civic duty...
Yup. I tend to agree. No guarantees that they were involved, but they could have cooperated with efforts (providing source code, helping analysts understand potential vulnerabilities, witholding patches, etc).
I'm sure that the usual NATO allies were all on board - certainly the nation where Siemens was headquartered and the US OKed the attack. Companies don't just do business with the Mossad or whatever without making sure their parent governments are OK with it.
The US triggered a massive refinery disaster in the USSR back during the cold war. This involved the full cooperation of vendors.
Symantec speculates a team size around 5-10 not including QA (whatever the heck that means).
Uh, good thing that programmers don't need QA or managers, and so on.
And yes, QA matters for an operation like this. You're probably having spies plant the bug, and they could get killed in the process. You don't risk spies on code that isn't tested.
Likewise, a fizzled attempt will likely trigger countermeasures making a future attack more difficult.
QA means getting it right the first time. That probably means creating a simulated environment and testing the software out in this environment. Sure, you don't need actual centrifuges and turbines, but you probably need software that emulates the feedback such machines would return to their controllers. I'm sure they didn't factor that into their "5-10" count.
I've worked on some IT projects where quality was serious business, and you can easily spend as much on testing as you spend on development. For a typical military-style coding effort factor in a WHOLE lot more.
Yeah, but am I the only one who kept thinking, "why is The Stig always trying to kill them?"
Oh, and I liked the bits on the mantle... :)
Ditto - I'd like an application that makes it easy for me to access my files from the web. I'm happy to provide the LAMP/etc, but I don't want my files to just be floating out there for random company to access.
If Obama wanted an easy out he could have had it - the courts were about to throw DADT out the window, and his administration begged them not to. If he just stood back and did nothing the policy would be gone today.
The cynical side of me thinks that DADT is kept around so that the D's can keep campaigning on it, just like how abortion was kept around so that the R's could keep campaigning on that. If politicians actually cared about these kinds of issues you'd see them do something about - there have been plenty of times in the last decade where one party controlled the white house and both houses of congress, and that applies to either party.
These are sideline issues to politicians - useful for drumming up supporters on election day, but nothing they really care about.
That doesn't help when the user jailbreaks it and the new OS doesn't have the same capabilities as the OS you audited.
The solution is to simply issue your own hardware and make employee tampering a terminable offense. I'd fully support that as long as the company provided the device and its plan.
If I get to provide the device, then I get to decide what security policies it implements, and what policies it lies about implementing. Don't like that? Simple, stop sending me email after 5PM...
Yup. I could make a killing if I sold an Email app that spoofs whatever is most common in major corps but which silently ignores the security policies.
If employers want to control the phone, they should issue the phone. If they issue it, then they can be sure that it supports whatever features they need. They can reclaim and reissue phones once a quarter to reimage them or whatever for extra security.
The problem is that employers want employees to use their shiny toys to do work off-hours, without paying for them. However, they don't like the fact that they now lose control over the platform.
Them's the breaks - the owner controls the phone.
Yup. All of your problems would go away if the app asked for a list of permissions, and then you'd edit them to what you want to give. Obviously you can't revoke GPS since you'll get no value from the app, but you could just kill the network access.
Agreed - you should be able to tweak the permissions. So, if the app asks for location tracking, and you don't want to grant it, you can tell the OS to install the app but not let it know the location, rather than not install it at all. Of course, if you're installing a navigation app you'll have to accept that the app won't work. However, if you're installing an IM client maybe you don't want it to know where you are.
The API could make these kinds of situations work out so that applications don't have problems. If the app asks for a location just feed it someplace random. If an App asks for phone numbers give it some Obama's cell phone number, or whatever. In fact, bonus points if the OS lets you pick what kind of garbage you feed the app.
App makers will be less prone to pulling these kinds of stunts when all it does is corrupt their marketing databases.
I dunno - I always though the whole idea of being a free thinker is to do what is morally right in all circumstances, without regard to virtually anything else...
If the judge pulled out a statue passed by the legislature and signed by the governor that said that bisexuals who marry white girls ought to be jailed I'd smile and vote innocent without regard to the facts of the case. To do otherwise would be an act of injustice, without regard to the laws. If questioned regarding my reasoning I'd just say that I wasn't convinced that the guy married her, or whatever, and that I was following the directions of the judge to the letter.
I don't think that iPads ended up being in the corporate world because they were selected by IT as the best tool for some job. Typically some executive gets one for his birthday or whatever and now IT has to support it. Or, the head of IT buys one and pushes it out.
iPads are nice for browsing and consuming content, but horrible for creating it. However, most decision-makers in major business are net-consumers of information, so it may be well-suited to them. For the 100 worker bees generating the content that the 2 managers consume, they're probably not such a good fit unless they two are just data consumers.
Chrome OS could potentially be a good fit for a lightweight corporate client, with lots of security features that would appeal to that market. It just isn't quite done yet. Whether it will get done before it peters out is up for debate.
Uh, Win XP gets full security updates, and so does IE6. They'll both receive them until 2014. I doubt that any android phone on sale today will still be getting security updates in 2014, and many won't be getting them this time next year.
Windows has its issues, but MS gets tons of money from the corporate market, and long ago it figured out that this means supporting products for VERY long times.
Uh, 17% is A LOT of devices. Most phones more than a year old aren't on the latest and greatest version of android, and may never be. Most of them are susceptible to a security flaw discovered a few weeks ago, and do you think that most of these phones will ever see an update?
So, unless a company expects their employees to buy a new $500 smartphone every year, they can't expect them to run the latest and greatest android OS version.
Sure, Apple doesn't release new OSes for their oldest iPhone model either, but they didn't drop support for 3+ years - which is a far cry from one year. I'm not a fan of Apple, but they do support their hardware for a fairly long time - about the only vendor who does for longer is Microsoft (say what you will about Microsoft, but they STILL support windows XP - find any linux vendor still publishing security updates for a product released in 2000).
I love Android and plan to stick with it, but mostly because I'm not chained to the support provided by my vendor (I'm running 2.2 on a phone whose last vendor update was 1.6).
Ok, if CO2 levels become a limiting factor in office size I'm definitely starting my own business...
BTW, businesses would be more than happy to pipe in O2 and water/etc and pipe out waste if they could get away with having their workers jacked into the matrix or whatever. They're more than happy to do that with cattle/etc. You'll never find a chicken in a farm that doesn't get enough water - they could care less if there is room for it to take two steps, but they certainly care that it develops enough meat to sell.
Yup - this is also one of the reasons why the mass of a liter of water/etc was avoided as the basis for the kilogram. It is almost impossible to obtain water of any particular isotopic composition, and it varies around the world. Water is also non-ideal for other reasons as well which I won't get into...
So, the first half of your discussion is a great explanation of why the guys running those projects don't want to cooperate. It has nothing to do with why those of us paying the bill shouldn't force them to do so anyway.
The second half of your post was about the benefits of redundancy, and I'll agree with those. However, any discovery made by Fermilab certainly would be confirmed or refuted by the LHC once it is running again. I'm sure they'll get around to it before they give out the Nobel prizes, unless they decide to pull an Obama again. :)
The article stated that a big driver for continuing the search at current energies is that Fermilab is right on their heels and might find the Higgs first if they take a break for a year.
As I see it, the Higgs could fit into one of two energy ranges:
1. A range that the limited LHC and Fermilab can both probe now, with the LHC having some advantage.
2. A range that only the full LHC can reach.
If it falls into the latter, then nobody is discovering the Higgs for a few years until they get the LHC in gear. If it falls into #1, does it REALLY matter that much who finds it first?
If what we care about is the accumulation of knowledge then we should cooperate and not compete here. Retask the LHC for higher energies, and have Fermilab continue to explore the lower-energy space. This way we find the Higgs more quickly as we have two non-redundant operations working on the problem, rather than having one be completely redundant.
Also, who knows what other interesting physics we'll find at the higher LHC design energies, that we're just pushing off for years sticking where we are at now?
Can't the lead authors on the competing 1000-author papers maybe agree to pool their efforts, and settle for first and last on a 2000-author paper instead? :) Then we poor taxpayers footing the bill can at least feel like we're all getting SOMETHING for our money...
Well, it seems the point is that "always-on" isn't as reliable as you might think it is. In this case the author of the commentary expected to have continuous service, and ended up not having it.
I do agree that a netbook really isn't suited for travelling businessmen in general. However, when you consider being ultra-light, long battery life, and fully automatic backups and data sharing they would be the most to benefit if it actually worked.
I guess that is up to the consumer, but the parent was right that if having the latest and greatest OS version is important to a consumer, they're more likely to get that from Apple than any of the Android vendors.
That isn't the MOST important criteria, which is why I run Android. However, I am disappointed that in general an Android phone is almost completely de-supported a year from release. Heck - didn't somebody come up with some browser exploits for Android a month or so back and I haven't seen any news of updates for the G1 - they're starting to look like MS on their patch schedules...
Look, I like android. I own a G1. I run Cyanogenmod and all that (though it is starting to hit the boundaries of usability with v6+).
The fact is that HTC stopped supporting the G1 about a year after it was released. Everything since then required rooting the phone. In fact, HTC's design would not allow the Android to run anything newer than 1.6 - their design was imperfect which is what allowed it to be rooted.
I think that in the support-for-older-hardware category I have to give the win to Apple. They support their older hardware a LOT longer than any of the android vendors do. Even the true-blood ADP was deprecated basically at the same time as the G1 - before then it just got the updates a little sooner and didn't have to bypass vendor locks to root it (though ironically you need to put those locks in to take advantage of the newer firmwares that free up more RAM).
I'd still go with Android in the future, but I'm under no illusions that getting newer OS versions on the device a year after it is released won't require considerable hacking.
They don't need to modify any internal files. You just submit a file to a repository and get the maintainers to check it in. The file has to look innocuous to any inspection. Once they do that, you put instead a rogue version of that file with the same hash and size on your own mirror, and get somebody to use that mirror. You make sure the rogue file is signed by the official maintainers so that end-users trust your mirror. Since the hash matches you can just extract their signature and put it on your rogue file.
Now, for source file this isn't going to be very practical, since if I submit a file that is 100 lines of source followed by a 1000-line pile of random characters in a comment they're going to strip that out, defeating the attack. However, what about binary submissions.
Wait, you ask, who accepts binary submissions into an SCM? Well, check out any of the android distros - the phone manufacturers don't distribute source for some of their drivers, which means lots of binary blobs floating around. I'm sure they get checked into SCMs. All I need to do is say that I patched a blob to make some fix, and chances are somebody will accept it after testing. It is very easy to sneak a bunch of binary garbage in a binary blob - as long as you make sure that it isn't in the code path. If you're REALLY clever you might be able to put it in the code path - just look at any polymorphic virus.
Bottom line is that if your hash function allows pre-generated collisions LOTS of bad things can happen. Coming up with clever reasons why they're not likely to happen won't save you when it actually does happen.
Again, that is a lovely hypothesis, complete with proposed mechanisms/etc. However, I still haven't seen anything more than "well, that's how it happens in nature" as an explanation for why it couldn't be otherwise.
I'm sure the natural process exists for a reason - but it doesn't have to be the reason that everybody thinks that it is.
The only way to find out is to experiment.
Are the passwords hashed when they are sent? I don't think the previous post was concerned about cookie theft, but rather password theft.
How does chrome sync your bookmarks? Simple - it has your Google account username and password stored locally on the machine. I'm sure it uses a cookie to bypass authentication when it can, but when that cookie expires it has to retransmit your username and password. Now, the question is how this is done. Obviously if they use https we're fine. If they use a challenge-response approach over http then the password is safe though the cookie is vulnerable. If they send the password in a form as plain text then anybody sniffing the connection has it.
I'm too lazy to sift through wireshark data to try to find my Chrome sync traffic, but I think this is a legitimate concern.
Whoosh! :)
I was being facetious - 5-10 is WAY less than stuxnet took to get right.
I didn't even mention engineering support. If your goal is to destroy a nuclear reactor, how do you ensure that whatever you plan to have it do will destroy it? Chances are you either need to test it out on real reactor components, or gather data from people who have tested real components and have a good idea of how they perform, etc.
I imagine that when this worm hit things must have gotten pretty exciting in that bunker... Granted, I don't know what the worm actually does - if it just shuts things down then it would be no big deal. However, if I were trying to take out a facility the last thing I would have it do is an orderly shutdown...
I have no objections to this, although I doubt most employers would compensate for jury duty in such a future world.
Another option is to compel employers to pay for jury time, and have the government kick in a little extra.
Bottom line is that I'm fine if people make a little more with jury duty than their regular jobs. Then people will look forward to doing their civic duty...
Yup. I tend to agree. No guarantees that they were involved, but they could have cooperated with efforts (providing source code, helping analysts understand potential vulnerabilities, witholding patches, etc).
I'm sure that the usual NATO allies were all on board - certainly the nation where Siemens was headquartered and the US OKed the attack. Companies don't just do business with the Mossad or whatever without making sure their parent governments are OK with it.
The US triggered a massive refinery disaster in the USSR back during the cold war. This involved the full cooperation of vendors.
Symantec speculates a team size around 5-10 not including QA (whatever the heck that means).
Uh, good thing that programmers don't need QA or managers, and so on.
And yes, QA matters for an operation like this. You're probably having spies plant the bug, and they could get killed in the process. You don't risk spies on code that isn't tested.
Likewise, a fizzled attempt will likely trigger countermeasures making a future attack more difficult.
QA means getting it right the first time. That probably means creating a simulated environment and testing the software out in this environment. Sure, you don't need actual centrifuges and turbines, but you probably need software that emulates the feedback such machines would return to their controllers. I'm sure they didn't factor that into their "5-10" count.
I've worked on some IT projects where quality was serious business, and you can easily spend as much on testing as you spend on development. For a typical military-style coding effort factor in a WHOLE lot more.