The problem is that the malware has access to the decrypted password when the browser fills in the password field. I can encrypt the underlying password store using a totally unbreakable ever algorithm with a 1-gigabit key stored in a physically-secure completely-untamperable-with hardware device, and the malware can completely ignore all that and snarf the cleartext password when the browser fills in the form field. So how does all that security offer any benefit?
It's like bragging about the bullet-proof unbreakable windows you put in the reinforced window frames with the vibration-detecting alarm system to alert you if anybody tries even touching the windows, while leaving the front door unlocked and open. Sure you've made it so the thief can't get in the window. None of that does you any good when the thief's just going to walk through the front door, bypassing the windows completely. You get far more benefit by skipping all the window-dressing and, you know, closing and locking your front door using the basic lock it came with.
Passwords have to be stored in a decryptable form, because the browser needs them decrypted to fill in the password fields or to respond to HTTP authentication responses. That means that any malware with access to the browser can get those passwords in decrypted form too. A master password doesn't help, the malware can just get the passwords after I've entered the master password to decrypt them for use (assuming it can't just get the master password when I enter it). The only thing encrypted password storage really protects against is someone with access to the physical storage media but not the running system, or essentially stolen mobile devices (phones or laptops). On those you probably shouldn't be storing passwords at all, because any reversible encryption is too easy to crack using off-line attacks with modern hardware.
It's similar to my objection to the old "don't write down your passwords" thing: the risk of a remote attack against easy-to-remember passwords is much higher than the risk of an attacker physically getting into the locked drawer of my desk in the locked area of the secured and patrolled building my office is in, and if the attacker has gotten into the locked drawer in my desk I've got much bigger security worries and the attacker has much juicier targets he can go after.
Even if all of it's on Android, I notice that it isn't available through the official app stores. So if you install your mobile software by going to Google Play or Amazon's app store or the like, you're probably not going to get hit. These guys set up their own unofficial app "stores" and web sites, luring you into going outside normal channels to get their stuff. And of course you get bit when you do that.
My attitude is that for most apps, if it's not available through Google's store I should be suspicious of it. Other large stores like Amazon's I'll use once I've confirmed from the app's own site that it's supposed to be available that way. Direct installation from the software's site... only if I know the site and the project behind it well and know this is their official source. Anything I'm just finding through an ad somewhere else I do not know well enough to trust a direct install. And buying by clicking on a link in a mobile browser? Yeah, just not happening.
The concerns are legitimate, but they're created by the developers. The first thing to do is stop designing the UI like it has to be pixel-perfect and stop doing absolute positioning. Your graphics elements, you'll probably need a couple different sizes but each one will be for a range of screen sizes. You don't care about making the graphics elements the exact size to the pixel, just roughly comfortably sized for the screen you have. Then think of the screen in terms of 4 edges and 8 anchor points (4 corners, 4 mid-points). Lay your UI out relative to those 8 anchor points, and let things float depending on screen size. For a media player, for instance, lay your control buttons out centered on the top or bottom of the screen and let the whitespace to the left and right vary depending on how big the screen is. Each size of button will fit a range of screens, you only care about size when the screen gets narrow or wide enough that you need to switch to the next smaller or larger set of icons to keep the control bar fitting without being too tiny or being wider than the screen. Yes, this is harder than laying everything out in terms of absolute positions. This is what your developers are being paid to do. If they haven't learned how, fire them and hire competent replacements.
Well, even something as simple as a Tetris game should have a couple of threads. One to handle input events, another to handle the dropping of the next tile and reorienting it in response to messages from the input thread. The browser should dump all network IO off into separate threads using a thread pool to avoid swamping the phone on pages with hundreds of separate elements. A voice calling program would have one thread handling voice input, one handling voice output and one handling input events from the screen. You're unlikely to run into the situations I deal with at work where a "simple" program is one that only handles a few dozen simultaneous threads, but only the simplest apps wouldn't benefit from a couple or three threads to segment the workload.
On the other hand, in that selling-early calculation you omit the part where I get that larger down-payment back. If I sell early, I may not gain the interest savings on the balance of the time but if I added $50K to the down-payment I have $50K more equity that I get back from the sale because that's $50K of financing I don't have to pay off out of the proceeds of the sale. That effectively reduces the risk in that scenario.
And yes, the driving force behind it is that people remember how you acted. If you backstab them they'll remember and won't trust you in the future, and then if you want their help you're going to have to do something more to climb out of that trust hole you've dug yourself into. That'll cost you more than cooperating with them in the first place would have, so anyone smart who wants to maximize their gains will avoid digging that hole.
Another thing that throws the classic risk calculation off is that, when it comes to cooperation, future value is almost always greater than current value. That's because of network effects: if I get a reputation now as someone willing to help, in the future I can get help from more than just the people I've directly helped. Likewise if I get a reputation for being uncooperative I'll lose not just the cooperation of the people I directly refused to help but of people I haven't met yet who know my rep. I can get away with it if I can duck out and go somewhere where people don't know my reputation, but if my reputation will follow me then being short-sighted can quickly dig me a hole I can't get out of.
I can do more with your help than I can on my own. But to get your help, I'm going to have to cooperate with you and offer you my help in return. So it's not really a choice between selfishness and cooperation. It's a choice between selfishness and stupidity. Do I be stupid, reject your help and limit myself to only what I can accomplish without help? Or do I be selfish, cooperate with you and reap the gains of having your help?
It's the same thing as you see with a mortgage. If you're greedy you forgo the immediate benefits and make a large down-payment because long-term you'll gain a lot more in reduced interest payments. If you're stupid or desperate you'll make the minimum down-payment and keep the money in your pocket right now, but pay several times what you "saved" in increased interest payments.
Software that's single-threaded, no it doesn't benefit from more cores. But modern heavily-multi-threaded software can benefit. More cores means more threads can execute simultaneously, and if the workload's heavily parallelized you can get it done quicker. No, you can't get a supercar engine from 8 lawnmower engines. But if I have a truckload of boxes to move into a warehouse, it'll go twice as fast with 8 normal guys who can carry 1 box per trip each than with 1 really strong guy who can carry 4 boxes per trip. And when you consider that with CPUs the really strong guy isn't 4x as strong as the normal guys, he's more like maybe 50% stronger, the performance improvement for the 8 guys is even better. Assuming of course that you've got individual boxes to move. If they're all packed up inside a shipping container and you have to move the entire shipping container, then yeah you need 1 guy with a crane rather than 8 guys by hand. Modern software, though, is leaning towards breaking things down into small chunks that can be dealt with in parallel, so octacore CPUs are going to help and Qualcomm's living in the 90s.
I recently worked for a company that had to completely rework a piece of their product line because one developer decided he liked a GPL'd library better than a more-free-for-commercial-use library.
And this is why when I'm deciding what third-party libraries we can use in software, the first question is "What's the intended use of this software?". Some licenses are perfectly acceptable if it's internal-use-only or developer tools that wouldn't be for software we're distributing to others.
Probably. This isn't the first time this has happened. They aren't the first company to fail to audit code their suppliers provided. At some point you have to stop and say "OK, by this point everybody ought to know what they need to do. It's been in the news enough that nobody can claim it's not well-known. So from here on out, no more excuses. No more passing the buck. You know what you need to do, do it or accept the consequences.". If you don't, the failures won't be addressed.
Shouldn't any company including any third-party code in their products already have a process in place to make sure that code's all properly licensed and they're in compliance? This isn't about GPL or FOSS code. If one of your suppliers includes proprietary code in the firmware they supply to you that isn't properly licensed or you aren't following the license terms don't you have the same problem?
Their "strategy" has been to position themselves as a high-end boutique brand. China (and most of the world) wants a solid affordably-priced workhorse. And in Asia Samsung almost certainly has a higher brand recognition than Apple just because they're relatively local (Korean vs. North American) and have been around a lot longer. To win, Apple would need to stop being Apple.
Raw facts are easy to report. I suspect most people get that from more direct sources rather than conventional news outlets. What the news outlets need to do is start doing the legwork, the analysis, the digging that goes beyond the raw facts.
Example: here in San Diego there's a flap over the mayor being accused of sexual harassment. What makes me raise an eyebrow is the line-up on the accusing side (the city attorney the mayor embarrassed by chewing her and her department out over her prosecution of the BofA "sidewalk chalk vandal" case, the opponent who lost to the mayor in the last election) and the distinct lack of charges/complaints filed by actual victims. What I'd love to see is what newspapers and news reporters used to dig up: who are the actual victims (in general terms, if not naming actual names), what they accuse the mayor of actually doing, who convinced them to make the accusations, are there any other witnesses to the behavior and what do they say about it, what does the mayor say about specific incidents when pressed on them. You know, all the interesting information behind the story. But none of that makes the papers or the TV news reports. Is it any wonder then that I don't have much use for the conventional news outlets? They're good for the weather report and not much else.
Both of those require a specific warrant and justification of the need for the intercept. Neither gives unlimited access to things other than the mail or phone calls. Having my password, by comparison, gives them unlimited access to everything on that account whether it's related to their investigation or not.
Neither of those give the police unlimited ability to impersonate me. Having my password, by comparison, allows the police to change anything on my account and add new things if they want, and every record and audit trail will show that I did those things.
NB: the second is why sysadmins don't log in as root and don't request user passwords. Logging in as their ordinary user and then su'ing to root leaves a record in the audit log of which sysadmin was doing what as root. And if we need to access your account as you, su'ing to root and then to your account leaves a record of which sysadmin was responsible for the access.
No. The Feds are requesting the private keys from the server operators themselves, not from the CA. A self-signed certificate's no guarantee the site operator hasn't coughed up the private half to the surveillance people. I'm not any more worried about this, though, since as demonstrated with XMission the government doesn't need to eavesdrop on communications when they can get access directly at the server end of things. As long as the Feds can threaten the site operator with unspecified nasty things if they don't cooperate or if they even say a word about what's going on, I have to assume any site I don't control myself is potentially compromised and any data sent to it's potentially visible to the various agencies involved or to the private contractors those agencies are using to do the grunt work. In many cases that doesn't matter much since the nature of the site's such that I won't put anything sensitive or compromising on it in the first place.
It's not so much a question of the companies respecting it as that they're on notice about it. It's like a no-trespassing sign on a fence. It may be easy to hop over the fence, and it doesn't actually stop anyone who intends to trespass. They can't, however, claim they didn't realize they were trespassing if they have to climb over a fence that at every point along it would've had at least one no-trespassing sign visible to them. That makes it much easier to deal with them when they get caught trespassing. That doesn't mean much for an individual, but when a large security breach occurs and information they collected gets stolen it means a lot if there's a class-action suit filed. Or if the breach affects European users who can invoke more stringent laws.
I think the objection here is to paying that high subsidy to provide service to the vacation homes of people rich enough to maintain 2 homes, who should reasonably be able to foot the bill themselves. IMO the subsidy ought to only be paid on lines serving a primary residence, ie. no vacation homes and the like.
That's fine, Dropbox, but I do have some non-technical requirements:
Storage may not be remote. Period. I have legal and business requirements that prohibit placing the data anywhere that I don't have complete control over access to it at all times. If it's on someone else's servers, I can't guarantee that.
Storage must not be remotely accessible over the network. I don't want J. Random Blackhat poking at my storage server trying to break in. All security breaks, but if the attackers can't reach it through the network then they can't attack it. See above for legal and business requirements about access.
I must be able to make backups which are under my control. See above for legal and business requirements for access. Backups contain the data, so they fall under those requirements. Those backups also need to be available to me at any time, not dependent on someone else's systems, and they need to be portable to alternative systems so I'm not locked into a single vendor.
As I see it, the first and second make syncing data between devices impossible. Whether it's push or pull, one end of the connection must always be unreachable by the other. And the access requirements pretty well rule out using anything in the cloud, even to transfer data. The only way it would work is using public-key encryption so what was stored in the cloud was an encrypted opaque blob, and that poses a lot of technical problems trying to efficiently modify and access only portions of that encrypted blob.
I suppose something like Dropbox would work for published content where I intend it to be accessed by the general public, but 90% of my stuff falls into the heading of "do not want to or am not allowed to make this stuff publicly accessible".
NB: that's also why, while I'll cheerfully use GMail for nonsensitive personal e-mail, anything business-related or sensitive goes through my own mail server where I know who can get access to it.
The problem here is management not wanting to take responsibility for their changes. The only way I know of to fix this is to force the issue. You need a process in place that requires sign-offs for schedule changes due to new requests. Then every time these requests come in you prepare a time estimate and send out the new request and current work-in-progress with a request for management and business to assign a priority to the new work so you can determine which existing work will be impacted and can get sign-offs for those delays. Then make it clear to the people requesting the new work that it will not go into the schedule until it's been prioritized and management and business agree to any impact. The selling point to management is that this is to insure that once work has been promised by a given deadline you won't miss the deadline because of new projects without management and business knowing about it and agreeing on which projects are more important. This goes against Agile in that the whole point of the process is to prevent the development team from adjusting to new requests as they come in. Eventually you will, but you're adding "stiffness" and delay to the process to deliberately act as a stumbling block to new work and force management and business to get together first so when they come to development for an estimate they've already agreed on priorities and development can proceed to revise the schedule without anyone being surprised at delays.
Yes. At work we have a long-outstanding issue open about performance. I nailed down where the bottleneck was, and put in the library module needed to fix it. Tests using the new module were showing a minimum order-of-magnitude speedup compared to the old (minimum because the test cases were biased to be as favorable to the old method as possible). Yet we've been directed to postpone actually switching to the new module (I suspect politics).
The major problem is that on-staff developers are usually discouraged from going on bug-hunts. Management would rather have them developing new features, so they won't allocate time towards finding bugs. When what the company policy towards finding bugs is conflicts with how your manager assigns you tasks, guess which one wins. Worse, most of the time an employee who ignores his to-do list to go find problems ends up penalized either explicitly (by bad reviews) or implicitly (negative impact from people being annoyed that he made work for them). Outsiders in these bounty programs don't have to worry about a manager assigning them 100% to new features and 0% to finding vulnerabilities and they don't have to worry about the impact of bad reviews or negative comments by managers about the extra work they created for everybody.
The problem with trying to figure out how to design and create a popular game is that, as with movies, there's no magic formula for what makes a popular game/movie. In fact, about the only guarantee is that following a formula, any formula, drastically reduces your chances for creating something popular. It's very hard to package up and teach creativity and originality.
Well, you can use AGPL'd software without needing to agree to the terms. What it doesn't allow is for you to let other people use it. Which has precedent in copyright law: if I buy a copy of the score for a piece of music I can play it in my home without needing a license, but I can't go and perform it publicly without getting an additional license to do so and usually paying a royalty for each performance.
That depends. For a Web app, who is the end user, the author/operator of the Web app or the person using the Web app? And I view the AGPL as addressing the issue of public performance. Web apps don't involve copying in the way conventional software distribution does, but copyright gives me as the copyright holder control over more than just that. As the copyright holder I also have the sole right to publicly perform (or authorize the public performance of) my works. If you want to read my book aloud to an audience, you need a license from me no less than if you want to hand each person a copy. And a Web app looks very much like a public performance of the underlying software. It's not merely the author/operator of the Web app seeing it do it's job, it's users of the Web app as well. So if you're running a piece of software I wrote in public and letting your entire audience interact with my software, how is that not akin to a public performance for which you'd need a license from me that I can set terms for?
This is why the AGPL came about. Freedom zero involves your use of the software you received. Web apps involve someone else's use of the software you received. And the fundamental motivation for the GPL family is to insure that software licensed under GPL terms stays under GPL terms. The AGPL just makes it explicit that if you give other people access to software I wrote and licensed under GPL terms, you must pass along the rights you got. You can't simply refuse to give them the access you got to it. The standard GPL and LGPL would've given you a loophole, the AGPL allows me to close that loophole and protect the rights I intend all users of the software to have to it.
Slashdot Mirror
The problem is that the malware has access to the decrypted password when the browser fills in the password field. I can encrypt the underlying password store using a totally unbreakable ever algorithm with a 1-gigabit key stored in a physically-secure completely-untamperable-with hardware device, and the malware can completely ignore all that and snarf the cleartext password when the browser fills in the form field. So how does all that security offer any benefit?
It's like bragging about the bullet-proof unbreakable windows you put in the reinforced window frames with the vibration-detecting alarm system to alert you if anybody tries even touching the windows, while leaving the front door unlocked and open. Sure you've made it so the thief can't get in the window. None of that does you any good when the thief's just going to walk through the front door, bypassing the windows completely. You get far more benefit by skipping all the window-dressing and, you know, closing and locking your front door using the basic lock it came with.
Passwords have to be stored in a decryptable form, because the browser needs them decrypted to fill in the password fields or to respond to HTTP authentication responses. That means that any malware with access to the browser can get those passwords in decrypted form too. A master password doesn't help, the malware can just get the passwords after I've entered the master password to decrypt them for use (assuming it can't just get the master password when I enter it). The only thing encrypted password storage really protects against is someone with access to the physical storage media but not the running system, or essentially stolen mobile devices (phones or laptops). On those you probably shouldn't be storing passwords at all, because any reversible encryption is too easy to crack using off-line attacks with modern hardware.
It's similar to my objection to the old "don't write down your passwords" thing: the risk of a remote attack against easy-to-remember passwords is much higher than the risk of an attacker physically getting into the locked drawer of my desk in the locked area of the secured and patrolled building my office is in, and if the attacker has gotten into the locked drawer in my desk I've got much bigger security worries and the attacker has much juicier targets he can go after.
Even if all of it's on Android, I notice that it isn't available through the official app stores. So if you install your mobile software by going to Google Play or Amazon's app store or the like, you're probably not going to get hit. These guys set up their own unofficial app "stores" and web sites, luring you into going outside normal channels to get their stuff. And of course you get bit when you do that.
My attitude is that for most apps, if it's not available through Google's store I should be suspicious of it. Other large stores like Amazon's I'll use once I've confirmed from the app's own site that it's supposed to be available that way. Direct installation from the software's site... only if I know the site and the project behind it well and know this is their official source. Anything I'm just finding through an ad somewhere else I do not know well enough to trust a direct install. And buying by clicking on a link in a mobile browser? Yeah, just not happening.
The concerns are legitimate, but they're created by the developers. The first thing to do is stop designing the UI like it has to be pixel-perfect and stop doing absolute positioning. Your graphics elements, you'll probably need a couple different sizes but each one will be for a range of screen sizes. You don't care about making the graphics elements the exact size to the pixel, just roughly comfortably sized for the screen you have. Then think of the screen in terms of 4 edges and 8 anchor points (4 corners, 4 mid-points). Lay your UI out relative to those 8 anchor points, and let things float depending on screen size. For a media player, for instance, lay your control buttons out centered on the top or bottom of the screen and let the whitespace to the left and right vary depending on how big the screen is. Each size of button will fit a range of screens, you only care about size when the screen gets narrow or wide enough that you need to switch to the next smaller or larger set of icons to keep the control bar fitting without being too tiny or being wider than the screen. Yes, this is harder than laying everything out in terms of absolute positions. This is what your developers are being paid to do. If they haven't learned how, fire them and hire competent replacements.
Well, even something as simple as a Tetris game should have a couple of threads. One to handle input events, another to handle the dropping of the next tile and reorienting it in response to messages from the input thread. The browser should dump all network IO off into separate threads using a thread pool to avoid swamping the phone on pages with hundreds of separate elements. A voice calling program would have one thread handling voice input, one handling voice output and one handling input events from the screen. You're unlikely to run into the situations I deal with at work where a "simple" program is one that only handles a few dozen simultaneous threads, but only the simplest apps wouldn't benefit from a couple or three threads to segment the workload.
On the other hand, in that selling-early calculation you omit the part where I get that larger down-payment back. If I sell early, I may not gain the interest savings on the balance of the time but if I added $50K to the down-payment I have $50K more equity that I get back from the sale because that's $50K of financing I don't have to pay off out of the proceeds of the sale. That effectively reduces the risk in that scenario.
And yes, the driving force behind it is that people remember how you acted. If you backstab them they'll remember and won't trust you in the future, and then if you want their help you're going to have to do something more to climb out of that trust hole you've dug yourself into. That'll cost you more than cooperating with them in the first place would have, so anyone smart who wants to maximize their gains will avoid digging that hole.
Another thing that throws the classic risk calculation off is that, when it comes to cooperation, future value is almost always greater than current value. That's because of network effects: if I get a reputation now as someone willing to help, in the future I can get help from more than just the people I've directly helped. Likewise if I get a reputation for being uncooperative I'll lose not just the cooperation of the people I directly refused to help but of people I haven't met yet who know my rep. I can get away with it if I can duck out and go somewhere where people don't know my reputation, but if my reputation will follow me then being short-sighted can quickly dig me a hole I can't get out of.
I can do more with your help than I can on my own. But to get your help, I'm going to have to cooperate with you and offer you my help in return. So it's not really a choice between selfishness and cooperation. It's a choice between selfishness and stupidity. Do I be stupid, reject your help and limit myself to only what I can accomplish without help? Or do I be selfish, cooperate with you and reap the gains of having your help?
It's the same thing as you see with a mortgage. If you're greedy you forgo the immediate benefits and make a large down-payment because long-term you'll gain a lot more in reduced interest payments. If you're stupid or desperate you'll make the minimum down-payment and keep the money in your pocket right now, but pay several times what you "saved" in increased interest payments.
Software that's single-threaded, no it doesn't benefit from more cores. But modern heavily-multi-threaded software can benefit. More cores means more threads can execute simultaneously, and if the workload's heavily parallelized you can get it done quicker. No, you can't get a supercar engine from 8 lawnmower engines. But if I have a truckload of boxes to move into a warehouse, it'll go twice as fast with 8 normal guys who can carry 1 box per trip each than with 1 really strong guy who can carry 4 boxes per trip. And when you consider that with CPUs the really strong guy isn't 4x as strong as the normal guys, he's more like maybe 50% stronger, the performance improvement for the 8 guys is even better. Assuming of course that you've got individual boxes to move. If they're all packed up inside a shipping container and you have to move the entire shipping container, then yeah you need 1 guy with a crane rather than 8 guys by hand. Modern software, though, is leaning towards breaking things down into small chunks that can be dealt with in parallel, so octacore CPUs are going to help and Qualcomm's living in the 90s.
And this is why when I'm deciding what third-party libraries we can use in software, the first question is "What's the intended use of this software?". Some licenses are perfectly acceptable if it's internal-use-only or developer tools that wouldn't be for software we're distributing to others.
Probably. This isn't the first time this has happened. They aren't the first company to fail to audit code their suppliers provided. At some point you have to stop and say "OK, by this point everybody ought to know what they need to do. It's been in the news enough that nobody can claim it's not well-known. So from here on out, no more excuses. No more passing the buck. You know what you need to do, do it or accept the consequences.". If you don't, the failures won't be addressed.
Shouldn't any company including any third-party code in their products already have a process in place to make sure that code's all properly licensed and they're in compliance? This isn't about GPL or FOSS code. If one of your suppliers includes proprietary code in the firmware they supply to you that isn't properly licensed or you aren't following the license terms don't you have the same problem?
Their "strategy" has been to position themselves as a high-end boutique brand. China (and most of the world) wants a solid affordably-priced workhorse. And in Asia Samsung almost certainly has a higher brand recognition than Apple just because they're relatively local (Korean vs. North American) and have been around a lot longer. To win, Apple would need to stop being Apple.
Raw facts are easy to report. I suspect most people get that from more direct sources rather than conventional news outlets. What the news outlets need to do is start doing the legwork, the analysis, the digging that goes beyond the raw facts.
Example: here in San Diego there's a flap over the mayor being accused of sexual harassment. What makes me raise an eyebrow is the line-up on the accusing side (the city attorney the mayor embarrassed by chewing her and her department out over her prosecution of the BofA "sidewalk chalk vandal" case, the opponent who lost to the mayor in the last election) and the distinct lack of charges/complaints filed by actual victims. What I'd love to see is what newspapers and news reporters used to dig up: who are the actual victims (in general terms, if not naming actual names), what they accuse the mayor of actually doing, who convinced them to make the accusations, are there any other witnesses to the behavior and what do they say about it, what does the mayor say about specific incidents when pressed on them. You know, all the interesting information behind the story. But none of that makes the papers or the TV news reports. Is it any wonder then that I don't have much use for the conventional news outlets? They're good for the weather report and not much else.
NB: the second is why sysadmins don't log in as root and don't request user passwords. Logging in as their ordinary user and then su'ing to root leaves a record in the audit log of which sysadmin was doing what as root. And if we need to access your account as you, su'ing to root and then to your account leaves a record of which sysadmin was responsible for the access.
No. The Feds are requesting the private keys from the server operators themselves, not from the CA. A self-signed certificate's no guarantee the site operator hasn't coughed up the private half to the surveillance people. I'm not any more worried about this, though, since as demonstrated with XMission the government doesn't need to eavesdrop on communications when they can get access directly at the server end of things. As long as the Feds can threaten the site operator with unspecified nasty things if they don't cooperate or if they even say a word about what's going on, I have to assume any site I don't control myself is potentially compromised and any data sent to it's potentially visible to the various agencies involved or to the private contractors those agencies are using to do the grunt work. In many cases that doesn't matter much since the nature of the site's such that I won't put anything sensitive or compromising on it in the first place.
1) Facebook can't throw you in prison if they don't like the information you've given them.
2) You can stop giving Facebook your information if you decide you no longer trust them with it.
It's not so much a question of the companies respecting it as that they're on notice about it. It's like a no-trespassing sign on a fence. It may be easy to hop over the fence, and it doesn't actually stop anyone who intends to trespass. They can't, however, claim they didn't realize they were trespassing if they have to climb over a fence that at every point along it would've had at least one no-trespassing sign visible to them. That makes it much easier to deal with them when they get caught trespassing. That doesn't mean much for an individual, but when a large security breach occurs and information they collected gets stolen it means a lot if there's a class-action suit filed. Or if the breach affects European users who can invoke more stringent laws.
I think the objection here is to paying that high subsidy to provide service to the vacation homes of people rich enough to maintain 2 homes, who should reasonably be able to foot the bill themselves. IMO the subsidy ought to only be paid on lines serving a primary residence, ie. no vacation homes and the like.
That's fine, Dropbox, but I do have some non-technical requirements:
As I see it, the first and second make syncing data between devices impossible. Whether it's push or pull, one end of the connection must always be unreachable by the other. And the access requirements pretty well rule out using anything in the cloud, even to transfer data. The only way it would work is using public-key encryption so what was stored in the cloud was an encrypted opaque blob, and that poses a lot of technical problems trying to efficiently modify and access only portions of that encrypted blob.
I suppose something like Dropbox would work for published content where I intend it to be accessed by the general public, but 90% of my stuff falls into the heading of "do not want to or am not allowed to make this stuff publicly accessible".
NB: that's also why, while I'll cheerfully use GMail for nonsensitive personal e-mail, anything business-related or sensitive goes through my own mail server where I know who can get access to it.
The problem here is management not wanting to take responsibility for their changes. The only way I know of to fix this is to force the issue. You need a process in place that requires sign-offs for schedule changes due to new requests. Then every time these requests come in you prepare a time estimate and send out the new request and current work-in-progress with a request for management and business to assign a priority to the new work so you can determine which existing work will be impacted and can get sign-offs for those delays. Then make it clear to the people requesting the new work that it will not go into the schedule until it's been prioritized and management and business agree to any impact. The selling point to management is that this is to insure that once work has been promised by a given deadline you won't miss the deadline because of new projects without management and business knowing about it and agreeing on which projects are more important. This goes against Agile in that the whole point of the process is to prevent the development team from adjusting to new requests as they come in. Eventually you will, but you're adding "stiffness" and delay to the process to deliberately act as a stumbling block to new work and force management and business to get together first so when they come to development for an estimate they've already agreed on priorities and development can proceed to revise the schedule without anyone being surprised at delays.
Yes. At work we have a long-outstanding issue open about performance. I nailed down where the bottleneck was, and put in the library module needed to fix it. Tests using the new module were showing a minimum order-of-magnitude speedup compared to the old (minimum because the test cases were biased to be as favorable to the old method as possible). Yet we've been directed to postpone actually switching to the new module (I suspect politics).
The major problem is that on-staff developers are usually discouraged from going on bug-hunts. Management would rather have them developing new features, so they won't allocate time towards finding bugs. When what the company policy towards finding bugs is conflicts with how your manager assigns you tasks, guess which one wins. Worse, most of the time an employee who ignores his to-do list to go find problems ends up penalized either explicitly (by bad reviews) or implicitly (negative impact from people being annoyed that he made work for them). Outsiders in these bounty programs don't have to worry about a manager assigning them 100% to new features and 0% to finding vulnerabilities and they don't have to worry about the impact of bad reviews or negative comments by managers about the extra work they created for everybody.
The problem with trying to figure out how to design and create a popular game is that, as with movies, there's no magic formula for what makes a popular game/movie. In fact, about the only guarantee is that following a formula, any formula, drastically reduces your chances for creating something popular. It's very hard to package up and teach creativity and originality.
Well, you can use AGPL'd software without needing to agree to the terms. What it doesn't allow is for you to let other people use it. Which has precedent in copyright law: if I buy a copy of the score for a piece of music I can play it in my home without needing a license, but I can't go and perform it publicly without getting an additional license to do so and usually paying a royalty for each performance.
That depends. For a Web app, who is the end user, the author/operator of the Web app or the person using the Web app? And I view the AGPL as addressing the issue of public performance. Web apps don't involve copying in the way conventional software distribution does, but copyright gives me as the copyright holder control over more than just that. As the copyright holder I also have the sole right to publicly perform (or authorize the public performance of) my works. If you want to read my book aloud to an audience, you need a license from me no less than if you want to hand each person a copy. And a Web app looks very much like a public performance of the underlying software. It's not merely the author/operator of the Web app seeing it do it's job, it's users of the Web app as well. So if you're running a piece of software I wrote in public and letting your entire audience interact with my software, how is that not akin to a public performance for which you'd need a license from me that I can set terms for?
This is why the AGPL came about. Freedom zero involves your use of the software you received. Web apps involve someone else's use of the software you received. And the fundamental motivation for the GPL family is to insure that software licensed under GPL terms stays under GPL terms. The AGPL just makes it explicit that if you give other people access to software I wrote and licensed under GPL terms, you must pass along the rights you got. You can't simply refuse to give them the access you got to it. The standard GPL and LGPL would've given you a loophole, the AGPL allows me to close that loophole and protect the rights I intend all users of the software to have to it.