Consider it the short form of "I'm sorry that I might embarrass you by proving you incorrect, but here's what the the FBI said that proves you are incorrect:"
I agree that calling it a MITM attack is a terrific summation.
The only problem with the elevator speech analogy is that it implies a certain audience. My boss would need more than 20 seconds to understand what a MITM attack is. Even then, he'd likely confuse https with privacy.
I think you can easily convince people who understand cryptography, but these are the people who mostly already understand privacy and already grok the risks that Facebook presents. You may never convince Joe Sixpack, if that was your intent.
Sorry, but I attended an FBI presentation last week, and the SA told us point-blank that Facebook was the greatest investigative aid ever. It used to take a warrant and months of hard work to figure out who someone was, what they did, who they hung out with, what kinds of things they talk about over drinks, and who supplies the dope to the party. Now it's a browser away and they don't even need a warrant.
Harvesting a million individual sites is more expensive and time consuming, and can be tracked and tampered with by the site owner. You could set up your own blog on your own server that spits out a red, white, and blue "Happy 4th of July, fellow patriots!" when viewed by an uninvited visitor, while spewing forth whatever brand of hatred you like when visited by your fellow clansmen. Breaking into this circle requires expensive undercover work. But Facebook will cooperatively deliver a full and faithful copy of whatever you dropped on their system.
By the FBI's own words, Moglen is exactly correct.
If you think you're "missing something" regarding software engineering, have a look at the SWEBOK, published by computer.org. It's a bit out of date, as it's lacking in security and quality sections, but it does have a compendium of knowledge.
As far as the actual practice of software engineering at a large company goes, my list looks like this:
1. Testing, and particularly developer-driven testing using automated unit tests. Why are you writing code if you can't prove it works? More importantly, why would your boss pay you to write code that you can't prove works? Really, if you learn nothing but Test Driven Development, you'll already be ahead of 50% of the people who call themselves programmers (including 50% of the commenters above spouting nonsense like "just keep doing what you do".) Of course, once you truly get it you'll realize that it touches all the disciplines of software engineering and design, and that a well-written test serves as your best documentation. And don't forget usability testing.
2. Design patterns. Civil engineers understand materials and shapes, and use tested and measurable components to accomplish tasks. A civil engineer doesn't need to reinvent the I-beam to build a bridge, they know the I-beam pattern exists and that that if they use them, they obtain performance of X, but have requirements of Y, and side effects of Z. Similarly, a software engineer should understand patterns serve a somewhat similar function in our domain. Pub/Sub will act this way, and it scales this way, but doesn't address retries. Note that patterns are abstract concepts, which makes them distinct from libraries or frameworks. I trust a pattern, because it's mathematically understood to behave a certain way. I don't have the same implicit trust of libraries and frameworks, because those are code implementations that may or may not be 100% correct.
4. Security. Understanding concepts like default deny vs default allow, input validation via whitelisting or blacklisting, sanitized outputs, etc., are crucial in the modern world. Check out OWASP and SANS for long, long lists of reasons why security matters to software engineers.
As an engineer, it turns out there's an awful lot you have to do that isn't directly programming, but is still important, either to you, to your software, or to your company. So the list keeps going.
5. Estimating. If you end up at a shop that isn't at least Agile (I am, and I wouldn't recommend it) you'll have to provide estimates. Experience is the primary teacher here, but you may find modeling tools like COCOMO II to be valuable.
6. Code reviews. Understand how to hold an effective peer review, one that helps improve software quality without making the coder feel like an idiot, or afraid for his next review score.
7. Methodologies, processes, metrics, regulations, standards, and governance. Waterfall, iterative, RUP, Agile, emergent design, test-driven, behavior-driven, lean, all are processes for writing software. Processes also cover things like source code management practices, defect tracking and fixing, project management, etc. At one level metrics are useless things managers want to see regarding productivity, but as an engineer you can use them to help understand code written by others. Standards and governance likewise exist primarily to make the people signing the checks feel like you're doing something for them. They may not matter in a one-man shop, but when you're in a big organization, leading teams of developers, or working with offshore teams, these take on a level of importance that you unfortunately cannot ignore.
There's a pile of other stuff, of course. Data modeling, software architecture, packaging, deployment, languages, the UML, optimization, encryption, key management and certif
What ever gave you the impression that the OoOoOlympics (TM) was ever about anything but money? The day they figured out they could get people to PAY for the privilege to host the games it stopped being about money and started being about shitloads of money. And hats. And ski trips, and family jobs, and Stupor Bowel tickets, and scholarships, and geld. And almost certainly hookers.
And in case you were thinking of tossing a bid in the ring for your fair city, consider that Montreal went $1.6 billion in debt hosting the 1976 Olympics. They didn't pay off the final stadium bill until 2006. It's obviously very profitable to host the games.
After this little incident, and last year's "Russian Hackers Remotely Destroyed Your City's Pump, So Panic Now" incident, renaming them to be Minitrue might be more appropriate.
Sorry, I confused "alternative market for banned apps" with "unofficial chinese app stores".
The two are so obviously completely different in so many ways... like... being that one of them is... umm... well, one is in Chinese.
So let me turn that around on you: what have you seen about this "alternative market" that you think makes it any more or less safe? What assurance will users have that these apps aren't malware? Is the alternative market going to digitally sign them? Is there a contract? Can I sue them if I get malware from them?
No. Either way, proven continually in the Chinese Android app marketplace. People are continually getting ripped off by apps that are stealing passwords, credit card data and other info. Apparently a high percentage of the "cracked" apps (those with copy protections or DRM restrictions removed) include an unhappy ending for the downloader. They may not get 5 million downloads, but I've read of Trojan horses with hundreds of thousands of victims. The stories have even been posted here on/.
Straight SQL is all I came here to suggest. Ten years ago I implemented a great circle calculation in a stored procedure to return the n nearest points of interest to a specified location. It simply wasn't a big deal. You just have to be a tiny bit thoughtful and apply some min/max rules to reduce the search space so you aren't brute-forcing the Traveling Salesman problem every time someone logs into the site. Internally, that's all the GIS databases do anyway. The problem simply isn't that hard.
Sixty seven years ago, Vannevar Bush envisioned the "memex", and as people became technically capable of doing so, they created it. http://www.livinginternet.com/i/ii_bush.htm. He was extremely influential in creating what eventually became DARPA and the ARPANET. To suggest that his "prediction was missed" is not correct. It was a less of a prediction and more of a vision that he and many other brilliant people worked hard to realize.
The Space Elevator may have been Clarke's idea, but he didn't create a Space Elevator Coalition to build one.
If a civil war erupted once before over Southern Secession, I doubt we'll see a repeat over California. Such a breakup would have to be mutual, and California simply has too many natural resources (oil, coasts, winter growing seasons, movie stars) for the rest of the union to want to give them up. No matter how weird they are.
Wait a minute. This isn't a "future prediction", it's the setting of Snow Crash. I knew it seemed familiar.
What's next out of these "futurists"? Rat-things? Cosa Nostra Pizza? Cops who take bribes on Visa cards?
Fortunately, that thing tends to regulate itself a bit. Most copper thieves just aren't that organized. And if there was a "Tony 'The Electric Fence' Soprano" running a stolen copper wire laundering scam, the thieves would have to know about him, know where to find him, and be given the instructions to make the drop off in a private place. While tougher rules generally don't stop professional thieves, they do slow the crimes of opportunity by removing the easy market for the stuff.
Many, many years ago my mother worked at an iron foundry. One day she transferred a call from a scrap dealer to the president, and afterward he told her the story. The scrap dealer had called to ask if the foundry really had sent these guys to sell the pig ingots back that they had just shipped the previous afternoon, and the answer was of course "no." The dealer knew exactly who to call because several of the ingots still had his chalkmarks indicating which foundry he had sold them to!
Seems these enterprising thieves broke into the back gate from the railroad tracks, saw a large number of shiny pig ingots stacked on the back dock, and thought they were valuable (probably not knowing that pig iron was going for about $20/ton.) They must have sweated all night carrying these forty pound pigs a block and a half down the railroad tracks, then up a railroad bridge embankment, to their waiting truck. The scrap dealer also told the president that these guys had broken the springs on their truck by overloading it. Since he was keeping the thieves busy outside by having them unload the ingots from their busted truck, he asked the foundry president if he should call the police for him. The president was laughing by this time and said as long as he got his iron back, they'd been punished enough. "Hell, if they hadn't stolen from us, I'd hire them! Nobody around here works that hard!"
You have to admit it's a pain to edit a dozen XPIs every time there's a new release. And I'm still not sure why they felt addons need to be tied to "application version numbers" instead of "interface IDs." That's a 20 year old lesson completely wasted on them.
The real problem is the dependency management the customers have to do.
A longer release cycle will provide organizations more time to build up dependencies on the existing software. If support increases from 1 year to 2 years, that means organizations will build up two years worth of problems. When they finally are forced to upgrade, it will be more than twice as painful.
For example, let's assume that an average of three packages need to be upgraded for each year that passes. If they sat on the same release for 2 years, they'd have to upgrade six packages. Depending on the software, that might mean coordinating a release with six different companies simultaneously, which is a lot harder than coordinating a release with three companies. And unless you're willing to break something, you can't upgrade until all six of the packages are completely upgraded.
The only saving grace is that they'll only have to run a regression test once per release.
The cure is for these companies to stay on top of their apps, making sure they're staying current with the new version of FF even if they aren't planning to roll it out. That way when the forced upgrade cycle catches up to them, it won't be as painful. And if you're diligently keeping everything current, why not ride the most recent FF version anyway?
No, that would just make them look as incompetent as they are. It wouldn't prove the idea of patenting software is stupid.
I'm wondering if IBM isn't doing this to prove the USPTO is useless.
In reality, they're probably just adding to their portfolio of fake valuables, so that when they lawyer-up they can claim "thousands" instead of "hundreds" of violations of their IP.
But that's why I consider it important. I don't think there's an argument about CO2 causing an effect, only the degree of impact. And the impact is very visible to me as I'm from Minnesota, and I can see that our winters have gotten progressively milder over my lifetime. (Yes, I know that's localized data and essentially meaningless over the globe, but it's certainly personal.) The ice caps are shrinking rapidly, according to people who measure such things, and satellite photos make such information visible to anyone.
Here's the thing: if we don't act now, and the problem is any worse than 1-2 degrees, it could be disastrous for the planet. And those are big disasters: increases in typhoons, sea level changes, tornadoes, alterations in the monsoon seasons, among many other scary situations. While I'm about as land-locked as a person can be, and have little to fear from sea level changes, the impact to the large percentage of humanity living on the coasts of the oceans could be staggering. A change in our energy behavior now could make the difference.
The other thing is we can ignore it for another 50 years, and hope that climate change isn't too bad before we run out of oil. That seems to be the current plan.
As far as "who's funding which studies", that pattern is much clearer: as expected, studies funded by industries show low impacts, and studies funded by environmental groups show high impacts. In almost every other case industrial studies downplaying environmental impacts have eventually been proven to be lies. I have no reason to think otherwise here.
Slashdot Mirror
Consider it the short form of "I'm sorry that I might embarrass you by proving you incorrect, but here's what the the FBI said that proves you are incorrect:"
I agree that calling it a MITM attack is a terrific summation.
The only problem with the elevator speech analogy is that it implies a certain audience. My boss would need more than 20 seconds to understand what a MITM attack is. Even then, he'd likely confuse https with privacy.
I think you can easily convince people who understand cryptography, but these are the people who mostly already understand privacy and already grok the risks that Facebook presents. You may never convince Joe Sixpack, if that was your intent.
Sorry, but I attended an FBI presentation last week, and the SA told us point-blank that Facebook was the greatest investigative aid ever. It used to take a warrant and months of hard work to figure out who someone was, what they did, who they hung out with, what kinds of things they talk about over drinks, and who supplies the dope to the party. Now it's a browser away and they don't even need a warrant.
Harvesting a million individual sites is more expensive and time consuming, and can be tracked and tampered with by the site owner. You could set up your own blog on your own server that spits out a red, white, and blue "Happy 4th of July, fellow patriots!" when viewed by an uninvited visitor, while spewing forth whatever brand of hatred you like when visited by your fellow clansmen. Breaking into this circle requires expensive undercover work. But Facebook will cooperatively deliver a full and faithful copy of whatever you dropped on their system.
By the FBI's own words, Moglen is exactly correct.
Enough Guinness and you're horizontal on the floor, where the orientation of the stripes is no longer among your concerns.
If you think you're "missing something" regarding software engineering, have a look at the SWEBOK, published by computer.org. It's a bit out of date, as it's lacking in security and quality sections, but it does have a compendium of knowledge.
As far as the actual practice of software engineering at a large company goes, my list looks like this:
1. Testing, and particularly developer-driven testing using automated unit tests. Why are you writing code if you can't prove it works? More importantly, why would your boss pay you to write code that you can't prove works? Really, if you learn nothing but Test Driven Development, you'll already be ahead of 50% of the people who call themselves programmers (including 50% of the commenters above spouting nonsense like "just keep doing what you do".) Of course, once you truly get it you'll realize that it touches all the disciplines of software engineering and design, and that a well-written test serves as your best documentation. And don't forget usability testing.
2. Design patterns. Civil engineers understand materials and shapes, and use tested and measurable components to accomplish tasks. A civil engineer doesn't need to reinvent the I-beam to build a bridge, they know the I-beam pattern exists and that that if they use them, they obtain performance of X, but have requirements of Y, and side effects of Z. Similarly, a software engineer should understand patterns serve a somewhat similar function in our domain. Pub/Sub will act this way, and it scales this way, but doesn't address retries. Note that patterns are abstract concepts, which makes them distinct from libraries or frameworks. I trust a pattern, because it's mathematically understood to behave a certain way. I don't have the same implicit trust of libraries and frameworks, because those are code implementations that may or may not be 100% correct.
3. Design principles. I like the SOLID principles myself, as I think they're exceptionally clear.
4. Security. Understanding concepts like default deny vs default allow, input validation via whitelisting or blacklisting, sanitized outputs, etc., are crucial in the modern world. Check out OWASP and SANS for long, long lists of reasons why security matters to software engineers.
As an engineer, it turns out there's an awful lot you have to do that isn't directly programming, but is still important, either to you, to your software, or to your company. So the list keeps going.
5. Estimating. If you end up at a shop that isn't at least Agile (I am, and I wouldn't recommend it) you'll have to provide estimates. Experience is the primary teacher here, but you may find modeling tools like COCOMO II to be valuable.
6. Code reviews. Understand how to hold an effective peer review, one that helps improve software quality without making the coder feel like an idiot, or afraid for his next review score.
7. Methodologies, processes, metrics, regulations, standards, and governance. Waterfall, iterative, RUP, Agile, emergent design, test-driven, behavior-driven, lean, all are processes for writing software. Processes also cover things like source code management practices, defect tracking and fixing, project management, etc. At one level metrics are useless things managers want to see regarding productivity, but as an engineer you can use them to help understand code written by others. Standards and governance likewise exist primarily to make the people signing the checks feel like you're doing something for them. They may not matter in a one-man shop, but when you're in a big organization, leading teams of developers, or working with offshore teams, these take on a level of importance that you unfortunately cannot ignore.
There's a pile of other stuff, of course. Data modeling, software architecture, packaging, deployment, languages, the UML, optimization, encryption, key management and certif
Here it is straight from CSI: VLT
"It looks like the Chileans ..."
[puts on sunglasses]
"zoomed and enhanced."
YEEAAAHHHHHHHHH!!!
What ever gave you the impression that the OoOoOlympics (TM) was ever about anything but money? The day they figured out they could get people to PAY for the privilege to host the games it stopped being about money and started being about shitloads of money. And hats. And ski trips, and family jobs, and Stupor Bowel tickets, and scholarships, and geld. And almost certainly hookers.
http://en.wikipedia.org/wiki/2002_Winter_Olympic_bid_scandal
And in case you were thinking of tossing a bid in the ring for your fair city, consider that Montreal went $1.6 billion in debt hosting the 1976 Olympics. They didn't pay off the final stadium bill until 2006. It's obviously very profitable to host the games.
After this little incident, and last year's "Russian Hackers Remotely Destroyed Your City's Pump, So Panic Now" incident, renaming them to be Minitrue might be more appropriate.
Sorry, I confused "alternative market for banned apps" with "unofficial chinese app stores".
The two are so obviously completely different in so many ways ... like ... being that one of them is ... umm ... well, one is in Chinese.
So let me turn that around on you: what have you seen about this "alternative market" that you think makes it any more or less safe? What assurance will users have that these apps aren't malware? Is the alternative market going to digitally sign them? Is there a contract? Can I sue them if I get malware from them?
Either way, highly unlikely.
No. Either way, proven continually in the Chinese Android app marketplace. People are continually getting ripped off by apps that are stealing passwords, credit card data and other info. Apparently a high percentage of the "cracked" apps (those with copy protections or DRM restrictions removed) include an unhappy ending for the downloader. They may not get 5 million downloads, but I've read of Trojan horses with hundreds of thousands of victims. The stories have even been posted here on /.
Thank you for not posting a link to their new logo.
Cyandroid? Andia? Trandroid? TheDroidsYou'reLookingFor?
Maybe he's German, where they use the comma to indicate the decimal separator.
So in USD, that would be $200.000K -- in other words, a very precisely rounded number.
Straight SQL is all I came here to suggest. Ten years ago I implemented a great circle calculation in a stored procedure to return the n nearest points of interest to a specified location. It simply wasn't a big deal. You just have to be a tiny bit thoughtful and apply some min/max rules to reduce the search space so you aren't brute-forcing the Traveling Salesman problem every time someone logs into the site. Internally, that's all the GIS databases do anyway. The problem simply isn't that hard.
TL;DR - Don't throw away MySQL just yet.
Sixty seven years ago, Vannevar Bush envisioned the "memex", and as people became technically capable of doing so, they created it. http://www.livinginternet.com/i/ii_bush.htm. He was extremely influential in creating what eventually became DARPA and the ARPANET. To suggest that his "prediction was missed" is not correct. It was a less of a prediction and more of a vision that he and many other brilliant people worked hard to realize.
The Space Elevator may have been Clarke's idea, but he didn't create a Space Elevator Coalition to build one.
Build one with DD-WRT. Here's a set of instructions:
http://www.smallnetbuilder.com/wireless/wireless-howto/30150-how-to-build-an-open-source-wi-fi-hotspot-with-dd-wrt
If a civil war erupted once before over Southern Secession, I doubt we'll see a repeat over California. Such a breakup would have to be mutual, and California simply has too many natural resources (oil, coasts, winter growing seasons, movie stars) for the rest of the union to want to give them up. No matter how weird they are.
Wait a minute. This isn't a "future prediction", it's the setting of Snow Crash. I knew it seemed familiar.
What's next out of these "futurists"? Rat-things? Cosa Nostra Pizza? Cops who take bribes on Visa cards?
The difference between a "futurologist" and a "psychic friend" is apparently $1.99 per minute, and you must be over 18 to call.
Fortunately, that thing tends to regulate itself a bit. Most copper thieves just aren't that organized. And if there was a "Tony 'The Electric Fence' Soprano" running a stolen copper wire laundering scam, the thieves would have to know about him, know where to find him, and be given the instructions to make the drop off in a private place. While tougher rules generally don't stop professional thieves, they do slow the crimes of opportunity by removing the easy market for the stuff.
Another scrapyard karma story:
Many, many years ago my mother worked at an iron foundry. One day she transferred a call from a scrap dealer to the president, and afterward he told her the story. The scrap dealer had called to ask if the foundry really had sent these guys to sell the pig ingots back that they had just shipped the previous afternoon, and the answer was of course "no." The dealer knew exactly who to call because several of the ingots still had his chalkmarks indicating which foundry he had sold them to!
Seems these enterprising thieves broke into the back gate from the railroad tracks, saw a large number of shiny pig ingots stacked on the back dock, and thought they were valuable (probably not knowing that pig iron was going for about $20/ton.) They must have sweated all night carrying these forty pound pigs a block and a half down the railroad tracks, then up a railroad bridge embankment, to their waiting truck. The scrap dealer also told the president that these guys had broken the springs on their truck by overloading it. Since he was keeping the thieves busy outside by having them unload the ingots from their busted truck, he asked the foundry president if he should call the police for him. The president was laughing by this time and said as long as he got his iron back, they'd been punished enough. "Hell, if they hadn't stolen from us, I'd hire them! Nobody around here works that hard!"
You have to admit it's a pain to edit a dozen XPIs every time there's a new release. And I'm still not sure why they felt addons need to be tied to "application version numbers" instead of "interface IDs." That's a 20 year old lesson completely wasted on them.
The real problem is the dependency management the customers have to do.
A longer release cycle will provide organizations more time to build up dependencies on the existing software. If support increases from 1 year to 2 years, that means organizations will build up two years worth of problems. When they finally are forced to upgrade, it will be more than twice as painful.
For example, let's assume that an average of three packages need to be upgraded for each year that passes. If they sat on the same release for 2 years, they'd have to upgrade six packages. Depending on the software, that might mean coordinating a release with six different companies simultaneously, which is a lot harder than coordinating a release with three companies. And unless you're willing to break something, you can't upgrade until all six of the packages are completely upgraded.
The only saving grace is that they'll only have to run a regression test once per release.
The cure is for these companies to stay on top of their apps, making sure they're staying current with the new version of FF even if they aren't planning to roll it out. That way when the forced upgrade cycle catches up to them, it won't be as painful. And if you're diligently keeping everything current, why not ride the most recent FF version anyway?
You're not catching me on this one. It's JVMs all the way down!
No, that would just make them look as incompetent as they are. It wouldn't prove the idea of patenting software is stupid.
I'm wondering if IBM isn't doing this to prove the USPTO is useless.
In reality, they're probably just adding to their portfolio of fake valuables, so that when they lawyer-up they can claim "thousands" instead of "hundreds" of violations of their IP.
But that's why I consider it important. I don't think there's an argument about CO2 causing an effect, only the degree of impact. And the impact is very visible to me as I'm from Minnesota, and I can see that our winters have gotten progressively milder over my lifetime. (Yes, I know that's localized data and essentially meaningless over the globe, but it's certainly personal.) The ice caps are shrinking rapidly, according to people who measure such things, and satellite photos make such information visible to anyone.
Here's the thing: if we don't act now, and the problem is any worse than 1-2 degrees, it could be disastrous for the planet. And those are big disasters: increases in typhoons, sea level changes, tornadoes, alterations in the monsoon seasons, among many other scary situations. While I'm about as land-locked as a person can be, and have little to fear from sea level changes, the impact to the large percentage of humanity living on the coasts of the oceans could be staggering. A change in our energy behavior now could make the difference.
The other thing is we can ignore it for another 50 years, and hope that climate change isn't too bad before we run out of oil. That seems to be the current plan.
As far as "who's funding which studies", that pattern is much clearer: as expected, studies funded by industries show low impacts, and studies funded by environmental groups show high impacts. In almost every other case industrial studies downplaying environmental impacts have eventually been proven to be lies. I have no reason to think otherwise here.