(I suggest you use paragraph breaks -- it really makes your post easier to read.)
I think there's another key factor that you've overlooked: The damage done by the tsunami was huge, while the damage done by the reactor's failure was pretty small. But the reactor is something they can do something about, while there's simply no way to stop a future tsunami. An excessively-strong reaction to the tiny bit of the event which can be addressed is a natural, if irrational, response to the larger but completely unmanageable risk of future tsunami damage.
Fundamental mistakes are common, but they generally get the bureaucratic crap like this right, at least when putting out requests for bids. It's the stuff they try to do themselves that really gets messed up. Come to think of it, you should really be happy they're outsourcing this -- it significantly increases the chance that it will be done right, and I'm not just saying that because Google won. MS would do it better than the DoI, too, though not, IMO, as well as Google.
At least you understand why this idea poses special challenges that can't be glossed over.
And so do the people at DoI, at the NSA who (I expect) did or consulted on the FISMA certification, and at Google. Given my experience with federal agencies, I'd be really shocked if the issue had been glossed over. It's far more likely that the RFQ included 300 pages of tedious, excessively detailed, verbose and jargon-laden specifications that overstated most of the requirements while missing a couple of crucial points -- but smart vendors (like Google) cover the missed portions anyway.
So basically, an entire group of people should be banned from doing something merely because some people in that group may do things that some people do not agree with?
Yes.
IMO, if there's a problem with this policy, it's that it has to be officially articulated at all. It should be obvious to any teacher that it's unprofessional to have social interactions with their students.
I dispute the problem of outsourcing the storage of your gold to a vault you don't control.
I think it's more like outsourcing your lead. The DoI doesn't handle a lot of really sensitive -- aka classified -- data, and what classified data it does handle couldn't be put in Docs, I'm sure. I've consulted a little with DoD agencies (before joining Google), plus I got some training in the handling of classified material when I was in the Air Force, and I can't see any way that any amount of certification could make outsourcing handling of classified data comply with the requirements.
Also, it wouldn't surprise me if there are provisions for the DoI to make regular backups -- in fact, I seem to recall that's a normal part of Google Apps' enterprise editions. So even in the unlikely event that Google lost all of its copies, the DoI would still have the data. In fact that might be more important for the DoI than for other enterprise customers, because normal customers' data is replicated across multiple data centers, to ensure its availability even in the event of a catastrophe. But if the DoI data must be segregated, it may not have that same replication.
On the security front (by which I mean protection against access unauthorized by the owner of the data center), I think it's pretty clear that Google has a far better track record than the Department of the Interior.
On the accountability side, I'm sure the contract holds Google very accountable, not to mention the fact that if the news of a loss of DoI data due to Google's negligence or malfeasance were to become public, it would have huge negative repercussions on Google, entirely aside from whatever the government would do to them.
(Disclaimer: I'm a Google engineer, one that works on security at Google, but I don't work on Docs or know anything about this deal. I didn't even know that the FISMA certification only applied to a segregated system.)
I can't even remember what the it was called, that is how truly relative it was, not relative then, forgotten about now. oh yeah, POSIX. Anyone even remember it?
Well, from what I understand is that it's manuvering capability was sufficient, the problem was a mirage like affect created by atmospheric distortion on the water, making objects appear above the horizon and far away, making the iceberg literally invisible on the silhouette of the night.
I think the bigger problem was the captain's decision to run flat out, at night, in an attempt to surprise the press by arriving ahead of schedule. Had he taken reasonable precautions and slowed down a little there would have been more time to react.
Open source is a software development method. The benefits of public development is THE justification for releasing source code and permitting others to do likewise.
Nonsense. Public development is only one of the possible reasons for releasing source under an OSS license.
What if you use GPL v 3 software and make it as your own internally. The owner wants to sell the company. What then? Sorry the GPL v3 counts that as a redistribution.
Which means that you have to give the source code to the buyer. So what?
They would have to release their crown jewels to competitors.
Why in the world would they have to do that? The GPL certainly wouldn't obligate them to.
What if it is a private organization and wants to go public. Oops can't disolve and reform as a public company because that also counts as redistribution under Sarbines Oxley
It's Sarbanes Oxley, not Sarbines Oxley.
The public company would have to receive source along with the binary. So what? That would be expected anyway.
Auditors would have a field day.
Doing what?
It seems to me that all of your arguments stem from the same fundamental misunderstanding of the GPL. The GPL does notrequire you to distribute source to the whole world, only to whoever you distribute the binary to. It also requires you to allow the recipient to redistribute at will (under the same terms), but it does not require the recipient to redistribute -- if the recipient has a vested interest in keeping it to themselves, they can do so!
BSD is much nicer. Remember GNU is friendly to its users but not to its owners.
Neither license puts any restrictions at all on the owners of the software. If you own the copyright, you are free to license or not as you will, and having previously licensed it one way does not prevent you from doing something else with it later.
Personally, I think the whole open source gig is fading away. The next generation of programmers have been raised to live and program in flashy iDink walled gardens and have neither the interest or the inclination in releasing or collaborating on code.
This happened 30 years ago, except then it was the DOS and then Windows world. The F/LOSS movement largely came from a later generation of programmers who realized that walling everything up sucks and impedes progress. And, although it was before my time, I understand there was a similar dynamic a couple of decades before that. Seems like just another turn of the wheel -- assuming you're even right, which I doubt.
That's great, too bad Android itself is such a closed platform.
FUD. Android is 100% open source. Google has some apps which are closed, and there are many apps in the store which are closed, but Android is 100% open. Including Honeycomb.
Distributing source was not the objection I heard. It was more along the lines of the license itself.
That doesn't make any sense. The license distribution of source and giving permission to re-distributed. That's the essence of "license itself".
.. anyway, if you use it are you exploiting it? You kind of sound like ANY use of OSS is exploitation.
"Exploiting" isn't a word that has any meaning in this context. You can use GPLv2 and GPLv3 software in any way you like, consistent with the terms of the license. In the case of v2, that basically boils down to "if you distribute binaries, you also have to distribute source, and whoever gets the source from you is likewise free to redistributed it under the same terms." In the case of v3, there are some additional restrictions around patent licensing hardware embedding, and there's an optional clause (actually a different version of the license with an additional clause) that software authors can choose to add that restricts use of the software in SaaS contexts.
Like it or not, but the fact that GPL is prohibited in many app stores is probably what discourages authors of FLOSS from using it as their license. Some authors may also feel that they don't want to use it even if it works fine for them now since they don't know what will happen in the future, as contributions are accepted from other authors it becomes much harder to change license. It's not 1991 anymore.
What app stores other than Apple's have terms incompatible with the GPL? Google Play doesn't. Amazon Appstore doesn't. Nook Store doesn't.
(BTW, the problem with Apple's terms isn't that they ban the GPL, it's that they require that apps be licensed on a per user basis, with no sub-licensing or re-distribution permitted, even if the licensing cost is zero. The GPL requires that everyone have redistribution rights, which is incompatible with per-user licensing. Google doesn't constraint the app developer's licensing choices, and AFAICT the other Android stores have followed suit.)
it's not a German problem, it's everyone's problem. it can happen anywhere.
That in no way contradicts the notion that it's an inherent character flaw in the German people. It just supports the notion that the flaw is much more widespread, even universal.
... and then tell me "there's no difference" between Democrats and Republicans.
Of course there's a difference: They want to take away different freedoms, and they want to spend huge amounts of tax dollars on different pet projects. The people who say there's no difference are just addressing the fact that both parties are authoritarian, big-government, tax-and-spend parties (or maybe borrow-and-spend, but that just defers the taxes). They're not wrong, and neither are you. There are differences, just no differences that matter.
The safest assumption in any security calculation is to assume that the attacker does know a substantial amount about your processes and systems, including your system for choosing passwords.
Yup. I do this. My strong, easy-to-type, password unlocks a local password locker. I have a couple of similar (similar generation approach, I mean) passwords which, along with second factor tokens, protect my Google accounts, and I use them for authenticating to web sites wherever possible.
"Note that Google Docs has been vetted by the US government and can be used for non-classified government information"
So, in other words, information that everyone in the world has a right to see?
No. It's been a couple of decades since I was in the Air Force and learned about the various levels of information security applied by the federal government, and it may have changed some since then, but classified material requires all sorts of security controls that (I would expect) make it basically impossible to outsource to any third party. There is a large amount of sensitive but unclassified information, however, with various designations such as "for official use only", etc., which must be kept confidential and managed securely, but which can actually be processed on ordinary computers, kept in ordinary filing cabinets, doesn't require detailed access logs, etc. The vast majority of all of the information managed by the federal government, including the military, falls into this broad category, even though very little of it is published, and much of it would not be disclosed in response to a Freedom of Information Act request. For example, personnel records.
The specific "vetting" I mentioned was testing for compliance with FISMA, per some specified standards (which I don't know). I do security at Google, but I don't do anything related to Docs/Apps, and I have worked a lot with federal security standards in my career, but it's all been around security module and smart card technology, so I have only the vaguest idea of exactly what the FISMA certification means. As I understand it, it means that federal agencies can use Google Docs/Apps for their routine work, including for data that is considered sensitive, but not secret.
Truth be told the passwords we actively encourage are no stronger than what he used.
If you want a really strong password, use a sentence of random words. Password length matters far more than password content - this is a simply provable fact - too bad hardly anybody in security realizes it.
That XKCD strip is consistently misunderstood. Random words aren't more secure than a sequence of random letters, numbers and symbols. For example, a random sequence of seven letters (mixed case), symbols (assume 10 of them) and numbers has the same amount of entropy as the four dictionary words Munroe mentions. Eight characters is signficantly stronger and four words. "Length matters more than content" is an oversimplification to the point of meaninglessness. Arguably, Munroe's example is shorter, since it's a sequence of four randomly-chosen symbols, rather than seven or eight. It's just that the symbols are chosen from a larger set (2048 vs 72).
The point of the strip is that, for most people, the sequence of words provides a strong password that is easier to remember. If remembering your password is your problem, then a sequence of random words is a good solution (but don't fall for the temptation to pick a favorite sentence). However, Munroe's example is almost four times as many letters to type -- call it three times as many keystrokes after accounting for the need to hit the shift key a few times in a random character sequence. Even worse, the fact is that many (lame) authentication systems won't accept very long passwords. In many ways multi-word passwords are impractical.
Personally I optimize for ease of typing, not ease of memorization. I use my most important passwords sufficiently frequently that remembering them is no problem, but being able to type them quickly and accurately can be. I use a random password generator to generate a random 10-character sequence, then I permute it for ease of typing. Permuting in a fairly predictable way (grouping shifted characters and arranging to alternate touch-typing hands between pairs of characters) reduces the entropy a little, which is why I generate 10 characters rather than eight or nine.
(I suggest you use paragraph breaks -- it really makes your post easier to read.)
I think there's another key factor that you've overlooked: The damage done by the tsunami was huge, while the damage done by the reactor's failure was pretty small. But the reactor is something they can do something about, while there's simply no way to stop a future tsunami. An excessively-strong reaction to the tiny bit of the event which can be addressed is a natural, if irrational, response to the larger but completely unmanageable risk of future tsunami damage.
It didnt, people adapted in 24 hours, life went on. Learning a new UI is not hard at all, it's just inconvenient.
For simple tasks like word processing and spreadsheet manipulation, this is true. Image editing is far more complex.
Fundamental mistakes are common, but they generally get the bureaucratic crap like this right, at least when putting out requests for bids. It's the stuff they try to do themselves that really gets messed up. Come to think of it, you should really be happy they're outsourcing this -- it significantly increases the chance that it will be done right, and I'm not just saying that because Google won. MS would do it better than the DoI, too, though not, IMO, as well as Google.
That would still -- at most -- indicate which machine was downloading. Not who was doing it.
At least you understand why this idea poses special challenges that can't be glossed over.
And so do the people at DoI, at the NSA who (I expect) did or consulted on the FISMA certification, and at Google. Given my experience with federal agencies, I'd be really shocked if the issue had been glossed over. It's far more likely that the RFQ included 300 pages of tedious, excessively detailed, verbose and jargon-laden specifications that overstated most of the requirements while missing a couple of crucial points -- but smart vendors (like Google) cover the missed portions anyway.
So basically, an entire group of people should be banned from doing something merely because some people in that group may do things that some people do not agree with?
Yes.
IMO, if there's a problem with this policy, it's that it has to be officially articulated at all. It should be obvious to any teacher that it's unprofessional to have social interactions with their students.
I dispute the problem of outsourcing the storage of your gold to a vault you don't control.
I think it's more like outsourcing your lead. The DoI doesn't handle a lot of really sensitive -- aka classified -- data, and what classified data it does handle couldn't be put in Docs, I'm sure. I've consulted a little with DoD agencies (before joining Google), plus I got some training in the handling of classified material when I was in the Air Force, and I can't see any way that any amount of certification could make outsourcing handling of classified data comply with the requirements.
Also, it wouldn't surprise me if there are provisions for the DoI to make regular backups -- in fact, I seem to recall that's a normal part of Google Apps' enterprise editions. So even in the unlikely event that Google lost all of its copies, the DoI would still have the data. In fact that might be more important for the DoI than for other enterprise customers, because normal customers' data is replicated across multiple data centers, to ensure its availability even in the event of a catastrophe. But if the DoI data must be segregated, it may not have that same replication.
Security. Accountability...
On the security front (by which I mean protection against access unauthorized by the owner of the data center), I think it's pretty clear that Google has a far better track record than the Department of the Interior.
On the accountability side, I'm sure the contract holds Google very accountable, not to mention the fact that if the news of a loss of DoI data due to Google's negligence or malfeasance were to become public, it would have huge negative repercussions on Google, entirely aside from whatever the government would do to them.
(Disclaimer: I'm a Google engineer, one that works on security at Google, but I don't work on Docs or know anything about this deal. I didn't even know that the FISMA certification only applied to a segregated system.)
I can't even remember what the it was called, that is how truly relative it was, not relative then, forgotten about now. oh yeah, POSIX. Anyone even remember it?
Does anyone remember POSIX? Are you kidding?
The RFQ was for collaboration software. LibreOffice doesn't provide real-time collaboration features.
Well, from what I understand is that it's manuvering capability was sufficient, the problem was a mirage like affect created by atmospheric distortion on the water, making objects appear above the horizon and far away, making the iceberg literally invisible on the silhouette of the night.
I think the bigger problem was the captain's decision to run flat out, at night, in an attempt to surprise the press by arriving ahead of schedule. Had he taken reasonable precautions and slowed down a little there would have been more time to react.
Open source is a software development method. The benefits of public development is THE justification for releasing source code and permitting others to do likewise.
Nonsense. Public development is only one of the possible reasons for releasing source under an OSS license.
What if you use GPL v 3 software and make it as your own internally. The owner wants to sell the company. What then? Sorry the GPL v3 counts that as a redistribution.
Which means that you have to give the source code to the buyer. So what?
They would have to release their crown jewels to competitors.
Why in the world would they have to do that? The GPL certainly wouldn't obligate them to.
What if it is a private organization and wants to go public. Oops can't disolve and reform as a public company because that also counts as redistribution under Sarbines Oxley
It's Sarbanes Oxley, not Sarbines Oxley.
The public company would have to receive source along with the binary. So what? That would be expected anyway.
Auditors would have a field day.
Doing what?
It seems to me that all of your arguments stem from the same fundamental misunderstanding of the GPL. The GPL does notrequire you to distribute source to the whole world, only to whoever you distribute the binary to. It also requires you to allow the recipient to redistribute at will (under the same terms), but it does not require the recipient to redistribute -- if the recipient has a vested interest in keeping it to themselves, they can do so!
BSD is much nicer. Remember GNU is friendly to its users but not to its owners.
Neither license puts any restrictions at all on the owners of the software. If you own the copyright, you are free to license or not as you will, and having previously licensed it one way does not prevent you from doing something else with it later.
Personally, I think the whole open source gig is fading away. The next generation of programmers have been raised to live and program in flashy iDink walled gardens and have neither the interest or the inclination in releasing or collaborating on code.
This happened 30 years ago, except then it was the DOS and then Windows world. The F/LOSS movement largely came from a later generation of programmers who realized that walling everything up sucks and impedes progress. And, although it was before my time, I understand there was a similar dynamic a couple of decades before that. Seems like just another turn of the wheel -- assuming you're even right, which I doubt.
That's great, too bad Android itself is such a closed platform.
FUD. Android is 100% open source. Google has some apps which are closed, and there are many apps in the store which are closed, but Android is 100% open. Including Honeycomb.
Distributing source was not the objection I heard. It was more along the lines of the license itself.
That doesn't make any sense. The license distribution of source and giving permission to re-distributed. That's the essence of "license itself".
.. anyway, if you use it are you exploiting it? You kind of sound like ANY use of OSS is exploitation.
"Exploiting" isn't a word that has any meaning in this context. You can use GPLv2 and GPLv3 software in any way you like, consistent with the terms of the license. In the case of v2, that basically boils down to "if you distribute binaries, you also have to distribute source, and whoever gets the source from you is likewise free to redistributed it under the same terms." In the case of v3, there are some additional restrictions around patent licensing hardware embedding, and there's an optional clause (actually a different version of the license with an additional clause) that software authors can choose to add that restricts use of the software in SaaS contexts.
Like it or not, but the fact that GPL is prohibited in many app stores is probably what discourages authors of FLOSS from using it as their license. Some authors may also feel that they don't want to use it even if it works fine for them now since they don't know what will happen in the future, as contributions are accepted from other authors it becomes much harder to change license. It's not 1991 anymore.
What app stores other than Apple's have terms incompatible with the GPL? Google Play doesn't. Amazon Appstore doesn't. Nook Store doesn't.
(BTW, the problem with Apple's terms isn't that they ban the GPL, it's that they require that apps be licensed on a per user basis, with no sub-licensing or re-distribution permitted, even if the licensing cost is zero. The GPL requires that everyone have redistribution rights, which is incompatible with per-user licensing. Google doesn't constraint the app developer's licensing choices, and AFAICT the other Android stores have followed suit.)
Who'd a thunk it?
it's not a German problem, it's everyone's problem. it can happen anywhere.
That in no way contradicts the notion that it's an inherent character flaw in the German people. It just supports the notion that the flaw is much more widespread, even universal.
... and then tell me "there's no difference" between Democrats and Republicans.
Of course there's a difference: They want to take away different freedoms, and they want to spend huge amounts of tax dollars on different pet projects. The people who say there's no difference are just addressing the fact that both parties are authoritarian, big-government, tax-and-spend parties (or maybe borrow-and-spend, but that just defers the taxes). They're not wrong, and neither are you. There are differences, just no differences that matter.
Wow, modded to -1 for providing a pretty reasonable -- and informative -- counterargument.
The safest assumption in any security calculation is to assume that the attacker does know a substantial amount about your processes and systems, including your system for choosing passwords.
Yup. I do this. My strong, easy-to-type, password unlocks a local password locker. I have a couple of similar (similar generation approach, I mean) passwords which, along with second factor tokens, protect my Google accounts, and I use them for authenticating to web sites wherever possible.
"Note that Google Docs has been vetted by the US government and can be used for non-classified government information"
So, in other words, information that everyone in the world has a right to see?
No. It's been a couple of decades since I was in the Air Force and learned about the various levels of information security applied by the federal government, and it may have changed some since then, but classified material requires all sorts of security controls that (I would expect) make it basically impossible to outsource to any third party. There is a large amount of sensitive but unclassified information, however, with various designations such as "for official use only", etc., which must be kept confidential and managed securely, but which can actually be processed on ordinary computers, kept in ordinary filing cabinets, doesn't require detailed access logs, etc. The vast majority of all of the information managed by the federal government, including the military, falls into this broad category, even though very little of it is published, and much of it would not be disclosed in response to a Freedom of Information Act request. For example, personnel records.
The specific "vetting" I mentioned was testing for compliance with FISMA, per some specified standards (which I don't know). I do security at Google, but I don't do anything related to Docs/Apps, and I have worked a lot with federal security standards in my career, but it's all been around security module and smart card technology, so I have only the vaguest idea of exactly what the FISMA certification means. As I understand it, it means that federal agencies can use Google Docs/Apps for their routine work, including for data that is considered sensitive, but not secret.
http://xkcd.com/936/
Truth be told the passwords we actively encourage are no stronger than what he used. If you want a really strong password, use a sentence of random words. Password length matters far more than password content - this is a simply provable fact - too bad hardly anybody in security realizes it.
That XKCD strip is consistently misunderstood. Random words aren't more secure than a sequence of random letters, numbers and symbols. For example, a random sequence of seven letters (mixed case), symbols (assume 10 of them) and numbers has the same amount of entropy as the four dictionary words Munroe mentions. Eight characters is signficantly stronger and four words. "Length matters more than content" is an oversimplification to the point of meaninglessness. Arguably, Munroe's example is shorter, since it's a sequence of four randomly-chosen symbols, rather than seven or eight. It's just that the symbols are chosen from a larger set (2048 vs 72).
The point of the strip is that, for most people, the sequence of words provides a strong password that is easier to remember. If remembering your password is your problem, then a sequence of random words is a good solution (but don't fall for the temptation to pick a favorite sentence). However, Munroe's example is almost four times as many letters to type -- call it three times as many keystrokes after accounting for the need to hit the shift key a few times in a random character sequence. Even worse, the fact is that many (lame) authentication systems won't accept very long passwords. In many ways multi-word passwords are impractical.
Personally I optimize for ease of typing, not ease of memorization. I use my most important passwords sufficiently frequently that remembering them is no problem, but being able to type them quickly and accurately can be. I use a random password generator to generate a random 10-character sequence, then I permute it for ease of typing. Permuting in a fairly predictable way (grouping shifted characters and arranging to alternate touch-typing hands between pairs of characters) reduces the entropy a little, which is why I generate 10 characters rather than eight or nine.