So, we already have the FBI/NSA/CIA/etc using national security letters (or maybe even just plain requests) to get your location data from your cellphone because "you've shared" your location with a 3rd party (e.g. - Google maps). Therefore, that data is no longer "yours" and instead belongs to the business and is largely free to be shared with whomever else they want at their discretion.
How long before a similar logic is applied to your "always on" microphone tracking every word you say? I guess we'll just have to trust these giant corporations to protect the privacy of their users rather than comply with the desires of big government......
Orwell was right about Big Brother but we've chosen to do it to ourselves (through our cellphones).
"I would argue that an API itself is not a main design component of well-written code..."
And I would strongly disagree. API design is one of the hardest and most valuable things software engineers do: determining the best places and ways to expose appropriate functionality so that it is most useful to others (including yourself).
Look at the design of C++'s standard library APIs (part of it being the former STL). Then compare that to some half-ass collections interface (e.g. - early versions of collections in Java). You are claiming that there is nothing worthy of legal protection in the design of those far superior C++ interfaces. That they are merely some necessary functional bits to invoke the (truly valuable) code that sits behind them.
I'm saying, yes, they are functional, but they are very much more as well. They represent the design decisions of the best *WAY* to facilitate, for example, manipulating in-memory data structures. To easily allow subsequences of one collection to be used while operating on another collection, perhaps of even a fundamentally different type. And so on. There is a ton of value in the design of those APIs. I would argue much more than in any specific code that implements the backing functions themselves. I'm not sure if that value is what you meant by "artistic expression," but good API design absolutely is an art that is hugely valuable and worthy of legal protection.
"One could reasonably argue that a header file collects the declarations from source code, and that the real creative work is the source code itself."
This kind of argues that the way you organize your code has no value. Or, that extracting a main design component of your code -- its organization -- renders that design no longer protectable (but it would have been if you didn't create a header?).
I see no reason to believe that -- quite the opposite in fact. In particular, I see no reason why to believe that lines within some function are more worthy of legal protection than the way you designed invoking that code in the first place. The API of something is often considerably more important and valuable than any particular implementation of it.
Very well stated! Personally, I find it incredible that so many people think all the design effort that goes into developing APIs (e.g. - class hierarchies, etc.) is essentially worthless and not a form of expression worthy of legal protection.
Google argues that all the design work that people put into figuring out the best APIs for their software systems cannot be protected by copyright. That all that design activity is basically worthless and not worthy of legal protection. I really have no clue how this became the predominant belief amongst software people. Convenience? Stealing someone else's API design is easier than figuring one out yourself, I guess.
Look at the design of the C++ language and its standard library. Think about the huge amounts of effort that Bjarne Stroustrup (and others) put into making the language and all of its API pieces fit together in the best way in their view. Now, imagine that Bjarne's team instead did all that design work only for their own company's use and never intended it for general consumption or use outside their company.
The arguments put forward by Google, and many others, are that if all those complicated, interconnected APIs somehow leaked out onto the internet (e.g. - a disgruntled employee surreptitiously posted them somewhere without permission), then everyone else would be legally free to copy them verbatim and reimplement the backing code without a single bit of permission nor consideration going back to Bjarne nor his company. They are "just" APIs that aren't copyrightable and almost surely not subject to patent protection. Google's approach values all that API design work as entirely worthless and not intellectual property in the least.
That's ridiculous. API design is a HUGE part of software design and development. I'd argue that it is often more important and valuable than any particular backing implementation of the API.
Ok, now imagine a bit different C++ scenario. Stroustrup really likes his C++ language and wants to publish about it, including his specific API design. Does the mere fact that he voluntarily revealed his API to the public (without any license but with a copyright claim), now allow everyone to run off and copy it verbatim again without permission nor consideration back to him? Again, that does seem to be Google's argument and it seems bonkers to me.
Arguing, as the EFF does, that open and free APIs are a good thing that facilitate competition, wide adoption, superior implementations, etc. is one thing. But arguing that all APIs are inherently open and cannot be protected as intellectual property -- that anyone can legally come along and copy verbatim the huge, complicated class hierarchy and interfaces that you designed for your software without your permission nor consideration back to you -- is an entirely different proposition. Authors should absolutely retain intellectual property rights to their specific APIs. They can license them or put them in the public domain as they see fit or not.
Now, the obvious criticism of my stance is that what is to prevent someone from putting and enforcing a copyright on something absurdly simple like C's strlen() function or something similar? Would we have the equivalent of patent trolls trying to extract money from anyone who codes? My answer to that is it would be up to the US Copyright Office and the courts to determine what is fair-use and what is simply too trivial to copyright. For example, a book author's copyright does not give them the right to go and sue anyone who happens to use a sentence that appears in their book, but it does allow them to sue people who reproduce significant sections of their book that go beyond fair-use. The same sort of logic would apply here too.
"... the API is just a functional (non-creative) description of the correct way to interact with the code."
Google argues that all the design work that people put into figuring out the best APIs for their systems cannot be protected by copyright. That all that design activity is "not creative," in your words, basically worthless and not worthy of legal protection. I really have no clue how this became the predominant belief amongst software people. Convenience? Stealing someone else's API design is easier than figuring one out yourself, I guess.
Look at the design of the C++ language and its standard library. Think about the huge amounts of effort that Bjarne Stroustrup (and others) put into making the language and all of its API pieces fit together in the best way in their view. Now, imagine that he instead did all that design work only for his own company's use and never intended it for general consumption or use outside his company.
The arguments put forward by Google, and many others, are that if all those complicated, interconnected APIs somehow leaked out onto the internet (e.g. - a disgruntled employee surreptitiously posted them somewhere without permission), then everyone else would be legally free to copy them verbatim and reimplement the backing code without a single bit of permission nor consideration going back to Bjarne nor his company. They are APIs that aren't copyrightable and almost surely not subject to patent protection. Google's approach values all that API design work as entirely worthless and not intellectual property in the least.
That's ridiculous. API design is a HUGE part of software design and development. I'd argue that it is often more important and valuable than any particular backing implementation of the API.
Ok, now imagine a bit different C++ scenario. Stroustrup really likes his C++ language and wants to publish about it, including his specific API design. Does the mere fact that he voluntarily revealed his API to the public (without any license but with a copyright claim), now allow everyone to run off and copy it verbatim again without permission nor consideration back to him? Again, that does seem to be Google's argument and it seems bonkers to me.
Arguing, as the EFF does, that open and free APIs are a good thing that facilitate competition, wide adoption, superior implementations, etc. is one thing. But arguing that all APIs are inherently open and cannot be protected as intellectual property -- that anyone can legally come along and copy verbatim the huge, complicated class hierarchy and interfaces that you designed for your software without your permission nor consideration -- is an entirely different proposition. Authors should absolutely retain the intellectual property rights to their specific APIs. They can license them or put them in the public domain as they see fit.
Now, the obvious criticism of my stance is that what is to prevent someone from putting and enforcing a copyright on something absurdly simple like C's strlen() function or something similar? Would we have the equivalent of patent trolls trying to extract money from anyone who codes? My answer to that is it would be up to the US Copyright Office and the courts to determine what is fair-use and what is simply too trivial to copyright. For example, a book author's copyright does not give them the right to go and sue anyone who happens to use a sentence that happens to appear in their book, but it does allow them to sue people who reproduce significant sections of their book that go beyond fair-use.
Yes, if attackers can successfully disseminate software that looks legitimate (e.g. - signed by Apple certificates), then that could allow them to install "keyloggers" or similar that could allow them to skirt around most any security codes. They'd just have to wait until the user enters their password again to unlock whatever secured files there are and then they could leak the contents or the password could later on be used to access the data as needed.
Still, that's a far more difficult hack than simply plugging into the phone and being able to easily brute force defeat any security there.
If you secure the data using AES-128 or AES-256 and the owner uses a decent password, then the only way to get at that data today is through some form of keylogging that subsequently captures the owner accessing their data again.
The keyspace for several common symmetric encryption schemes (e.g. - AES-256) is on the order of 2^256. So, brute force attacks aren't even possible on them because there isn't enough energy in the universe to try all combinations before the heat death of the universe. You need to find some kind of flaw to drastically reduce the search space first.
So, Apple has a unique ability to subvert older generations of their iPhone through software signed by them. Then, yeah, the govt. absolutely does have the right to invoke Apple's special capabilities to conduct a lawful search warrant. All of this points to the wisdom of designing such systems so that even Apple can't break them. Then in the future they can claim they have no special capabilities not available to the govt already. This case is a legacy cost for doing half-assed security in the past. Oh well, lesson learned.
I definitely agree with that, but if just changing the OS allows a 3rd party to decrypt the data, then the security is still horribly broken. For the data to be secure, Apple, the govt., whomever, should be able to access the full contents of the phone, know all the algorithms involved, etc., and still not be able to decrypt the data. If the user used too short of a password that allows it to be brute forced, then that's their fault.
It sounds like what you are driving at is that the data itself it not well secured really at all. If you can get a copy of the data and successfully brute force attack it, then that's user error for not having a long enough random-ish password to encrypt the data. For the data to be truly secure, Apple, the govt. whomever should be able to fully access the entire contents of the phone, know what algorithms are being used and still not be able to decrypt the data without knowing the encryption password and brute forcing it should be prohibitively expensive.
If Apple can simply write some software to get around the iPhone's security mechanisms in this case or any of the others, then THEIR SECURITY MECHANISMS ARE BROKEN.
The govt. is paying them to test their own security, which they have claimed they purposely designed so even they can't break it. Either they lied about that, which wouldn't surprise me at all, or they will get paid to test their own security. How is getting paid for something you should already be doing anyway a horrible intrusion onto your liberty?
And, yes, if Apple *LIED* about designing their security so that even they couldn't break it, then definitely *SCREW* Apple.
If it is that easy to externally modify the OS on the phone without user authorization to basically bypass the security of the data on the phone, then their claims about security are shite in the first place.
The security of the iPhone *should* be one of their top priorities and they *should* already have whole teams of people working on this internally. If the govt. wants to fund further security audits, then that is a 100% win-win. They will get directly paid for things they should have already been doing anyway. Literally, the govt. will be funding future security improvements to the iPhone.
If the courts are forcing them to labor without just compensation, then that is a different matter.
"Perhaps Apple doesn't want to divert their resources off of the products and product lines that are important to them as a company." Yeah, the iPhone is such an ancillary product for Apple. I agree!/s
"Perhaps Apple doesn't want the liability if they mistakenly delete all the data the FBI wants." Oh, I'm sure that's a real concern for a multi-billion dollar company...
"Perhaps Apple doesn't want to set a legal precedent that companies will result in ever increasing demands to break their products in the way the government desires." AFAIK, the govt. has not mandated any particular kind of exploit. They just want the info off of this phone. Great! Work to crack it on the govt's dime and if they are successful, then they've identified security holes to be patched in future versions. It's win-win all around.
"Perhaps Apple is taking a principled stand." Highly unlikely. They are just trying to protect their brand.
"What makes you think Apple cannot crack their own hardware/software?"
I'm taking them at their word that they have purposely designed the security of the iPhone so that even they can't break them. If that's not true, then screw Apple and force them to perform whatever capabilities they have reserved to themselves. Why should they have superior capabilities to crack our phones than the government, especially when national security or warrants are in play?
"What the FBI wants is an iOS version with a set of vulnerabilities purposely built in so they can more easily brute force the phone in question."
That may be what they want in the long run, but that is certainly not what the court has ordered nor what US law currently mandates. It also shouldn't help them in this particular case at all.
"Even we forgave all of Greece's debts. They would still be in the negative."
Wrong. They had a primary surplus last year and could easily reestablish it now. They only need money to pay interest and rollover their existing mountain of debt that periodically comes to maturity.
Put it this way: you are spending less than your monthly expenses (primary surplus), but you have a HUGE loan outstanding and you need to pay it off next month when it's due. The eurozone is demanding all this retribution just so that Greece can rollover its debt (i.e. - pay it off with new debt establishing a new payoff date). Meanwhile they collect interest the whole time on the outstanding debt. Not too bad a deal for Europe so long as Greece doesn't default.
"The reason they haven't gone bankrupt is because they CAN NOT AFFORD IT. They are that fucked up!!"
Wrong again. If they cancelled their debt, then they wouldn't need to borrow another euro for anything. But they'd be kicked out of the eurozone. Well, technically their banks would be insolvent and the ECB wouldn't give them any more euros. Six of one, a half dozen of the other.
What people fail to understand is that the Greeks aren't living beyond their means any longer. They had a primary surplus last year. The size of their debt has barely increased since mid-2013:
Greece is being forced to turn over its sovereignty simply to rollover existing debt, even though the creditors know it is impossible for Greece to pay down its debt and they've known this for years.
It's disgusting. Economically they'd have been far better off going for Grexit within ten years then continuing in this charade. Also, Syriza and Tsipras wouldn't have had to make a mockery of their democracy too.
"The law and Constitution (as interpreted and implemented by our system of government) are the constraints -- not specific technological capability."
Complete BS.
History has proven that the primary thing that kept the 4th amendment alive for as long as it lived was the technological inability of the govt. to snoop on most aspects of its citizens lives. Now that technological progress and the digitization of our lives has made it technically possible to capture and examine grand swathes of citizens' lives, lo and behold, suddenly all those previously sacrosanct legal constraints of the past suddenly start getting REAL squishy. Suddenly, Orwellian "full capture" approaches are claimed to be NECESSARY for the govt. to properly protect the HOMELAND against Oceania. Or is it Eastasia these days? I always get it mixed up.
Worse, the military-industrial types and their security pawns in Congress actively chip away at whatever fig leafs of legal constraints still exist on govt. snooping as we've seen over the last decade and a half.
Then these same folks have the audacity to be shocked, surprised and upset when citizens and companies object to them shredding their formerly fundamental rights. They smear anyone who actively takes steps to restore a more proper balance as criminals, terrorists and traitors.
As the OP said, they can go fuck themselves. You aren't putting this genie back in the bottle.
Then how do you cleanly handle a function that needs to acquire N resources where any one of the acquisitions can fail -- and it needs to clean itself up on failure (and possibly on success)?
The only non-goto answer I've seen so far is to have ever deeper nesting of if's (with a return buried in its depths if the resources should be held on success), followed by a bunch of unwinding else's that contain and separate the error handling in else's and far away from the error detection (with a different return path when the resources are held on success).
Meanwhile, the goto version does exactly the opposite -- it doesn't have ever deeper nesting of the common successful path, it uses guard clauses to abort further execution upon error detection, error dispatching (and any in context handling if necessary) is easily done and you can jump to exactly the right section of cleanup code and it is easy to have a single exit point for the function after all the cleanup code at the bottom of the function.
Slashdot Mirror
So, we already have the FBI/NSA/CIA/etc using national security letters (or maybe even just plain requests) to get your location data from your cellphone because "you've shared" your location with a 3rd party (e.g. - Google maps). Therefore, that data is no longer "yours" and instead belongs to the business and is largely free to be shared with whomever else they want at their discretion.
How long before a similar logic is applied to your "always on" microphone tracking every word you say? I guess we'll just have to trust these giant corporations to protect the privacy of their users rather than comply with the desires of big government ......
Orwell was right about Big Brother but we've chosen to do it to ourselves (through our cellphones).
"I would argue that an API itself is not a main design component of well-written code ..."
And I would strongly disagree. API design is one of the hardest and most valuable things software engineers do: determining the best places and ways to expose appropriate functionality so that it is most useful to others (including yourself).
Look at the design of C++'s standard library APIs (part of it being the former STL). Then compare that to some half-ass collections interface (e.g. - early versions of collections in Java). You are claiming that there is nothing worthy of legal protection in the design of those far superior C++ interfaces. That they are merely some necessary functional bits to invoke the (truly valuable) code that sits behind them.
I'm saying, yes, they are functional, but they are very much more as well. They represent the design decisions of the best *WAY* to facilitate, for example, manipulating in-memory data structures. To easily allow subsequences of one collection to be used while operating on another collection, perhaps of even a fundamentally different type. And so on. There is a ton of value in the design of those APIs. I would argue much more than in any specific code that implements the backing functions themselves. I'm not sure if that value is what you meant by "artistic expression," but good API design absolutely is an art that is hugely valuable and worthy of legal protection.
Considering API design a "mere collection of facts" is bonkers. It is one of the most, possibly the most, important elements of software design.
"One could reasonably argue that a header file collects the declarations from source code, and that the real creative work is the source code itself."
This kind of argues that the way you organize your code has no value. Or, that extracting a main design component of your code -- its organization -- renders that design no longer protectable (but it would have been if you didn't create a header?).
I see no reason to believe that -- quite the opposite in fact. In particular, I see no reason why to believe that lines within some function are more worthy of legal protection than the way you designed invoking that code in the first place. The API of something is often considerably more important and valuable than any particular implementation of it.
Very well stated! Personally, I find it incredible that so many people think all the design effort that goes into developing APIs (e.g. - class hierarchies, etc.) is essentially worthless and not a form of expression worthy of legal protection.
Google argues that all the design work that people put into figuring out the best APIs for their software systems cannot be protected by copyright. That all that design activity is basically worthless and not worthy of legal protection. I really have no clue how this became the predominant belief amongst software people. Convenience? Stealing someone else's API design is easier than figuring one out yourself, I guess.
Look at the design of the C++ language and its standard library. Think about the huge amounts of effort that Bjarne Stroustrup (and others) put into making the language and all of its API pieces fit together in the best way in their view. Now, imagine that Bjarne's team instead did all that design work only for their own company's use and never intended it for general consumption or use outside their company.
The arguments put forward by Google, and many others, are that if all those complicated, interconnected APIs somehow leaked out onto the internet (e.g. - a disgruntled employee surreptitiously posted them somewhere without permission), then everyone else would be legally free to copy them verbatim and reimplement the backing code without a single bit of permission nor consideration going back to Bjarne nor his company. They are "just" APIs that aren't copyrightable and almost surely not subject to patent protection. Google's approach values all that API design work as entirely worthless and not intellectual property in the least.
That's ridiculous. API design is a HUGE part of software design and development. I'd argue that it is often more important and valuable than any particular backing implementation of the API.
Ok, now imagine a bit different C++ scenario. Stroustrup really likes his C++ language and wants to publish about it, including his specific API design. Does the mere fact that he voluntarily revealed his API to the public (without any license but with a copyright claim), now allow everyone to run off and copy it verbatim again without permission nor consideration back to him? Again, that does seem to be Google's argument and it seems bonkers to me.
Arguing, as the EFF does, that open and free APIs are a good thing that facilitate competition, wide adoption, superior implementations, etc. is one thing. But arguing that all APIs are inherently open and cannot be protected as intellectual property -- that anyone can legally come along and copy verbatim the huge, complicated class hierarchy and interfaces that you designed for your software without your permission nor consideration back to you -- is an entirely different proposition. Authors should absolutely retain intellectual property rights to their specific APIs. They can license them or put them in the public domain as they see fit or not.
Now, the obvious criticism of my stance is that what is to prevent someone from putting and enforcing a copyright on something absurdly simple like C's strlen() function or something similar? Would we have the equivalent of patent trolls trying to extract money from anyone who codes? My answer to that is it would be up to the US Copyright Office and the courts to determine what is fair-use and what is simply too trivial to copyright. For example, a book author's copyright does not give them the right to go and sue anyone who happens to use a sentence that appears in their book, but it does allow them to sue people who reproduce significant sections of their book that go beyond fair-use. The same sort of logic would apply here too.
"... the API is just a functional (non-creative) description of the correct way to interact with the code."
Google argues that all the design work that people put into figuring out the best APIs for their systems cannot be protected by copyright. That all that design activity is "not creative," in your words, basically worthless and not worthy of legal protection. I really have no clue how this became the predominant belief amongst software people. Convenience? Stealing someone else's API design is easier than figuring one out yourself, I guess.
Look at the design of the C++ language and its standard library. Think about the huge amounts of effort that Bjarne Stroustrup (and others) put into making the language and all of its API pieces fit together in the best way in their view. Now, imagine that he instead did all that design work only for his own company's use and never intended it for general consumption or use outside his company.
The arguments put forward by Google, and many others, are that if all those complicated, interconnected APIs somehow leaked out onto the internet (e.g. - a disgruntled employee surreptitiously posted them somewhere without permission), then everyone else would be legally free to copy them verbatim and reimplement the backing code without a single bit of permission nor consideration going back to Bjarne nor his company. They are APIs that aren't copyrightable and almost surely not subject to patent protection. Google's approach values all that API design work as entirely worthless and not intellectual property in the least.
That's ridiculous. API design is a HUGE part of software design and development. I'd argue that it is often more important and valuable than any particular backing implementation of the API.
Ok, now imagine a bit different C++ scenario. Stroustrup really likes his C++ language and wants to publish about it, including his specific API design. Does the mere fact that he voluntarily revealed his API to the public (without any license but with a copyright claim), now allow everyone to run off and copy it verbatim again without permission nor consideration back to him? Again, that does seem to be Google's argument and it seems bonkers to me.
Arguing, as the EFF does, that open and free APIs are a good thing that facilitate competition, wide adoption, superior implementations, etc. is one thing. But arguing that all APIs are inherently open and cannot be protected as intellectual property -- that anyone can legally come along and copy verbatim the huge, complicated class hierarchy and interfaces that you designed for your software without your permission nor consideration -- is an entirely different proposition. Authors should absolutely retain the intellectual property rights to their specific APIs. They can license them or put them in the public domain as they see fit.
Now, the obvious criticism of my stance is that what is to prevent someone from putting and enforcing a copyright on something absurdly simple like C's strlen() function or something similar? Would we have the equivalent of patent trolls trying to extract money from anyone who codes? My answer to that is it would be up to the US Copyright Office and the courts to determine what is fair-use and what is simply too trivial to copyright. For example, a book author's copyright does not give them the right to go and sue anyone who happens to use a sentence that happens to appear in their book, but it does allow them to sue people who reproduce significant sections of their book that go beyond fair-use.
This was a blatant troll on a forum ...
^^^^^^ THIS!!!
I mean, he made /.'s front page. That's pretty darn good!
Yes, if attackers can successfully disseminate software that looks legitimate (e.g. - signed by Apple certificates), then that could allow them to install "keyloggers" or similar that could allow them to skirt around most any security codes. They'd just have to wait until the user enters their password again to unlock whatever secured files there are and then they could leak the contents or the password could later on be used to access the data as needed.
Still, that's a far more difficult hack than simply plugging into the phone and being able to easily brute force defeat any security there.
If you secure the data using AES-128 or AES-256 and the owner uses a decent password, then the only way to get at that data today is through some form of keylogging that subsequently captures the owner accessing their data again.
And, yes, passwords typically don't have 256 or even 128 bits of entropy in them, but, again, that's the user's problem.
The keyspace for several common symmetric encryption schemes (e.g. - AES-256) is on the order of 2^256. So, brute force attacks aren't even possible on them because there isn't enough energy in the universe to try all combinations before the heat death of the universe. You need to find some kind of flaw to drastically reduce the search space first.
http://www.eetimes.com/documen...
So, Apple has a unique ability to subvert older generations of their iPhone through software signed by them. Then, yeah, the govt. absolutely does have the right to invoke Apple's special capabilities to conduct a lawful search warrant. All of this points to the wisdom of designing such systems so that even Apple can't break them. Then in the future they can claim they have no special capabilities not available to the govt already. This case is a legacy cost for doing half-assed security in the past. Oh well, lesson learned.
I definitely agree with that, but if just changing the OS allows a 3rd party to decrypt the data, then the security is still horribly broken. For the data to be secure, Apple, the govt., whomever, should be able to access the full contents of the phone, know all the algorithms involved, etc., and still not be able to decrypt the data. If the user used too short of a password that allows it to be brute forced, then that's their fault.
It sounds like what you are driving at is that the data itself it not well secured really at all. If you can get a copy of the data and successfully brute force attack it, then that's user error for not having a long enough random-ish password to encrypt the data. For the data to be truly secure, Apple, the govt. whomever should be able to fully access the entire contents of the phone, know what algorithms are being used and still not be able to decrypt the data without knowing the encryption password and brute forcing it should be prohibitively expensive.
If Apple can simply write some software to get around the iPhone's security mechanisms in this case or any of the others, then THEIR SECURITY MECHANISMS ARE BROKEN.
The govt. is paying them to test their own security, which they have claimed they purposely designed so even they can't break it. Either they lied about that, which wouldn't surprise me at all, or they will get paid to test their own security. How is getting paid for something you should already be doing anyway a horrible intrusion onto your liberty?
And, yes, if Apple *LIED* about designing their security so that even they couldn't break it, then definitely *SCREW* Apple.
If it is that easy to externally modify the OS on the phone without user authorization to basically bypass the security of the data on the phone, then their claims about security are shite in the first place.
The security of the iPhone *should* be one of their top priorities and they *should* already have whole teams of people working on this internally. If the govt. wants to fund further security audits, then that is a 100% win-win. They will get directly paid for things they should have already been doing anyway. Literally, the govt. will be funding future security improvements to the iPhone.
If the courts are forcing them to labor without just compensation, then that is a different matter.
"Perhaps Apple doesn't want to divert their resources off of the products and product lines that are important to them as a company." Yeah, the iPhone is such an ancillary product for Apple. I agree! /s
"Perhaps Apple doesn't want the liability if they mistakenly delete all the data the FBI wants." Oh, I'm sure that's a real concern for a multi-billion dollar company ...
"Perhaps Apple doesn't want to set a legal precedent that companies will result in ever increasing demands to break their products in the way the government desires." AFAIK, the govt. has not mandated any particular kind of exploit. They just want the info off of this phone. Great! Work to crack it on the govt's dime and if they are successful, then they've identified security holes to be patched in future versions. It's win-win all around.
"Perhaps Apple is taking a principled stand." Highly unlikely. They are just trying to protect their brand.
"What makes you think Apple cannot crack their own hardware/software?"
I'm taking them at their word that they have purposely designed the security of the iPhone so that even they can't break them. If that's not true, then screw Apple and force them to perform whatever capabilities they have reserved to themselves. Why should they have superior capabilities to crack our phones than the government, especially when national security or warrants are in play?
"What the FBI wants is an iOS version with a set of vulnerabilities purposely built in so they can more easily brute force the phone in question."
That may be what they want in the long run, but that is certainly not what the court has ordered nor what US law currently mandates. It also shouldn't help them in this particular case at all.
"Even we forgave all of Greece's debts. They would still be in the negative."
Wrong. They had a primary surplus last year and could easily reestablish it now. They only need money to pay interest and rollover their existing mountain of debt that periodically comes to maturity.
Put it this way: you are spending less than your monthly expenses (primary surplus), but you have a HUGE loan outstanding and you need to pay it off next month when it's due. The eurozone is demanding all this retribution just so that Greece can rollover its debt (i.e. - pay it off with new debt establishing a new payoff date). Meanwhile they collect interest the whole time on the outstanding debt. Not too bad a deal for Europe so long as Greece doesn't default.
"The reason they haven't gone bankrupt is because they CAN NOT AFFORD IT. They are that fucked up!!"
Wrong again. If they cancelled their debt, then they wouldn't need to borrow another euro for anything. But they'd be kicked out of the eurozone. Well, technically their banks would be insolvent and the ECB wouldn't give them any more euros. Six of one, a half dozen of the other.
What people fail to understand is that the Greeks aren't living beyond their means any longer. They had a primary surplus last year. The size of their debt has barely increased since mid-2013:
http://www.tradingeconomics.co...
Greece is being forced to turn over its sovereignty simply to rollover existing debt, even though the creditors know it is impossible for Greece to pay down its debt and they've known this for years.
It's disgusting. Economically they'd have been far better off going for Grexit within ten years then continuing in this charade. Also, Syriza and Tsipras wouldn't have had to make a mockery of their democracy too.
"The law and Constitution (as interpreted and implemented by our system of government) are the constraints -- not specific technological capability."
Complete BS.
History has proven that the primary thing that kept the 4th amendment alive for as long as it lived was the technological inability of the govt. to snoop on most aspects of its citizens lives. Now that technological progress and the digitization of our lives has made it technically possible to capture and examine grand swathes of citizens' lives, lo and behold, suddenly all those previously sacrosanct legal constraints of the past suddenly start getting REAL squishy. Suddenly, Orwellian "full capture" approaches are claimed to be NECESSARY for the govt. to properly protect the HOMELAND against Oceania. Or is it Eastasia these days? I always get it mixed up.
Worse, the military-industrial types and their security pawns in Congress actively chip away at whatever fig leafs of legal constraints still exist on govt. snooping as we've seen over the last decade and a half.
Then these same folks have the audacity to be shocked, surprised and upset when citizens and companies object to them shredding their formerly fundamental rights. They smear anyone who actively takes steps to restore a more proper balance as criminals, terrorists and traitors.
As the OP said, they can go fuck themselves. You aren't putting this genie back in the bottle.
We likely wouldn't even realize we were under attack until it was far too late to do anything.
Then how do you cleanly handle a function that needs to acquire N resources where any one of the acquisitions can fail -- and it needs to clean itself up on failure (and possibly on success)?
The only non-goto answer I've seen so far is to have ever deeper nesting of if's (with a return buried in its depths if the resources should be held on success), followed by a bunch of unwinding else's that contain and separate the error handling in else's and far away from the error detection (with a different return path when the resources are held on success).
Such coding contains a bunch of anti-patterns: ArrowAntiPattern and rejects the use of GuardClauses and HandleErrorsInContext.
Meanwhile, the goto version does exactly the opposite -- it doesn't have ever deeper nesting of the common successful path, it uses guard clauses to abort further execution upon error detection, error dispatching (and any in context handling if necessary) is easily done and you can jump to exactly the right section of cleanup code and it is easy to have a single exit point for the function after all the cleanup code at the bottom of the function.