But with central keys and a proprietary system, it'd be quite easy for Apple to read everything. End to End encryption shouldn't also include massive amounts of trust.
For some reason, I thought they had built protections into the system to prevent adding arbitrary keys without telling the user, but apparently I'm wrong, or if I'm right, then it isn't discussed in the white paper.
The short answer (apparently) is that upon subpoena, the government could compel Apple to add a new public key and forward a copy of all the traffic for a particular user. However, Apple cannot provide access to messages that have been sent previously, because there's no mechanism for telling existing devices to send a copy of their messages to a new device.
Actually, it's exactly like that. Go after something that's pretty much harmless in the hands of the law-biding because a very tiny fraction of the population abuses it. Gun control to a T....
Not really. Gun control actually has some basis in logic, which is that a significant percentage of gun deaths are either accidental or occur because of firearms stolen from someone who bought them legally. It provably makes it harder for criminals to get guns. The debate is over how much harder it makes it, and whether the inconvenience to everyone else is worth it.
With encryption, the bad guys (for any definition of "bad guys" you might choose) have access to encryption already, and unlike guns, once you have software, you can make an infinite number of copies of it without cost. So there can be no rational debate over whether banning encryption makes it harder for the bad guys to gain access to it, because the answer is an incontrovertible no.
I thought you were old enough to have written a check before. Your account number is on your check, which you handed to all of the clerk at the various stores you shop at. You might also notice account numbers are SEQUENTIAL. If I want to know someone's account number, I take mine and add one. If I add two, I get another valid account number. My bank account number is on my web site, so people can wire payments to me. Not secret, not even a little bit.
For a checking account, that is true, but it isn't true for (for example) a credit card account number or a savings account number.
When the banking system as a whole was set up initially, the assumption was that most of your money would be in a savings account, and that your checking account would contain only enough money to handle typical transactions. If it suddenly went empty because of fraud, the bank could cover the loss. That breaks down somewhat if you're doing everything with one account, obviously, but that's another issue entirely.
Either way, the general advise that the banks give is to treat the account number as a secret, and to not give it out unless necessary (which means writing checks only to people you trust at least to some degree). After all, once I have your account number, I can very easily get a deck of checks printed with that number, and it is unlikely that I would get caught, so long as I shopped in random places that are all far from home. But it is secret only because the system is fundamentally broken, once again treating a mere identifier as an identity.
Both of those examples were wars of secession by a group of countries/territories who wanted religious freedom that was being denied to them by their government. As such, religion was at best tangential. It could have just as easily been a fight over freedom to drink beer on Sundays for all religion mattered to the situation. What mattered was that their freedoms were being limited, and they didn't like it.
Also, although the Thirty Years War started as a war over religion, it quickly turned into a much broader conflict between warring regional superpowers that had nothing to do with religion. That's why the death toll rose into the millions.
Also, the Protestant Reformation is not generally considered to have ended until more than a hundred years after the Thirty Years War. So IMO, neither of those wars can be considered to have been fought among "modern" Christians, because the dust hadn't really settled yet.
The only way you can argue that the New Testament doesn't forbid homosexuality is by literally redefining what Paul wrote, as you pointed out yourself.
No, that's not what I said. What Paul said was in a nearly two-thousand-year-old dead language (Koine Greek). We don't know precisely what some of those words meant in that day. We can only approximate it based on how those words were translated into other languages later, both in that text and in other texts over the course of centuries. And when the same word has been translated in radically different ways in different passages from different authors, it is pretty certain that (at least) one of those translations is wrong. You can pretty flip a coin about which one, and you'll be right half of the time, but you cannot know with any certainty which half of the time.
Any Christian who makes that argument is literally ignoring the words of their own holy book...
No, any Christian who makes that argument is literally ignoring the words of really, really bad, highly inconsistent translations of their own holy book. The people who actually study the original texts in the original language don't agree with one another about what those words mean. The word Arsenokoites appears twice in the Bible, both times in Paul's writings; the word never appeared previously in any text, and only appears 80 times in all of known literature. Other texts from the time appear to imply that it actually meant prostitution, orgies, homosexual acts by straight people, sex with children, incest, rape.... Later texts even said that men could commit that sin with their wives, which pretty much rules out the translation that you're dogmatically clinging to, though it does not definitively do so, because the meaning of the word could have shifted over those five hundred years or so.
Either way, the point is that nobody has the slightest idea what the original meaning of the word was. For all we know, for the people to whom Paul was writing, it might have been local slang for "having sex with sheep". We just don't know.
As everyone with even the most peripheral ties to the tech industry knows, the average six-year-old is more tech literate than an average member of the news media. The only people less computer savvy are politicians.
As for the information they can't get, there's a lot. With end-to-end encryption as is used on services like Apple's iMessage, the data exists only on the devices at either end of the communication, and the keys exist only there. They can tell you who communicated with whom, but they can't tell you the contents of the communication.
But here's what the politicians don't seem to understand: The tech industry did all of this as a direct response to government abuse, mostly by major first-world governments like those in the U.S. and Britain, rather than by all the third-world governments that you might ordinarily imagine would be guilty of spying on their citizens. Those companies tried using encryption that could be broken upon subpoena; they tried that first, because it seemed like the best compromise between security and... well, security. But major governments abused that subpoena power massively, creating secret courts that they could use to perform data collection without public oversight. After those governments effectively took the "secure except with a subpoena" option off the table as a viable means of protecting privacy rights, the only remaining option available to the tech companies that could prevent those governments from massively overstepping their authority and abusing the rights of the public at large was to design systems in such a way that it was impossible to break into the data stream even with a court order to do so without the user becoming aware that their communication had been compromised.
This is the natural evolution of security. Bad people attack security and try to create back doors. Good people find ways to bolster the systems to prevent those bad people from doing so. Eventually, the systems become so robust that they are not vulnerable to most feasible attacks. The governments of the world had every opportunity to get these companies to build systems that could be monitored when necessary. All they had to do was act like responsible adults, and only use their subpoena power when it was absolutely necessary to save lives. Instead, they chose to abuse that power. Now, it is too late. Those in power should have shown restraint when they had the chance.
The thing is, the public has a fundamental right to have access to encryption that is as good as what the terrorists have. Anything less would be an unconscionable abrogation of the public's rights, without any real effect on terrorism. After all, it would take a decent software engineer all of a couple of days to write an end-to-end encrypted chat application in which the user must enter a passcode prior to decrypting any data stored on the device, and in which the data is always encrypted with the recipient's public key prior to transmission, so the bad guys will always have access to end-to-end encryption. The key exchange can be tricky, but trust is always a tricky issue in general, and is kind of a separate issue.
In the fight against terrorism, the trust policy is always going to be the weak point that can be exploited—government officials pretending to be potential terrorists so that they can infiltrate the organization, government officials creating honeypots that pretend to be terrorist recruiting sites so that they can prevent people from joining the real organizations by burying them in the noise, etc. Once trust is established—once terrorists have actually become part of such an organization, any hope of further interception of their communication is a hopeless cause, and anybody who says otherwise is kidding him/herself.
And before anyone brings it up, this isn't at all like gun control. Terrorists don't frequently steal their end-to-end encryption from other people; if it is not available legally, they can re-develop it themselves with only a modicum of effort. So fighting terrorism by banning encryption is more like fighting gang violence by banning the legal sale of bandanas, and makes exactly as much sense.
In much the same way that being a good Christian does not require you to stone adulterers and people who wear cotton-poly blends, Christianity as a general system of faith does not inherently declare homosexuality to be sinful. Jesus gave a new covenant, superseding the Old Testament laws, including that one. The only New Testament bits about homosexuality are in Paul's writing, and that translation is considered dubious by many biblical scholars. So although one could argue that Christians of certain specific denominations are "bad" in some sense of the word if they don't consider homosexuality to be a sin, you can't generalize that to all of Christianity.
Financial systems already have to cope with two entirely overlapping sets of numbers—taxpayer identification numbers and SSNs. Both are nine-digit numbers. One has a single hyphen after the second digit, and the other has two hyphens. So it isn't as though you can just store the nine-digit number and ignore the rest of the string. To be useful, an SSN really needs to be stored as a ten- or eleven-digit string, and must be compared using string comparisons, not numeric comparisons.
Thus, it would make more sense to make the new batch of SSNs be dddd-dd-ddd, and construct the actual digits in exactly the same way that they do now. That would give an additional billion SSNs without any significant impact on anything. In fact, there are 8 possible single-hyphen variants, and we've only used one, which leaves seven billion more. There are 28 possible pairings of two hyphens (if I counted correctly), of which we have used only one, which leaves 27 billion additional values. You can also have zero hyphens, assuming that software doesn't have any checks that pitch a fit if you do that. Add them all together, and you get a whopping 35 billion possible additional SSNs or TINs at your disposal without the need to add any more digits. And you could also have variants that drop digits, which pushes the number up even higher.
Just to clarify, it is possible to steal a digital identity, but it is not possible to steal a digital identity when used correctly, e.g. when you use your private key to encrypt a nonce, and someone else decrypts that nonce with your public key to verify that you really do possess the private key associated with that public key.
Banks are, but AFAIK, the credit bureaus aren't. They're the root of the problem. If the credit bureaus really wanted to end so-called "identity theft", they could do it very easily. It would simply require them to invest the money to perform a callback authentication to all registered phone numbers prior to issuing new credit. Boom. No more "identity theft", or at least so many orders of magnitude less that the remainder could be treated as noise.
I put that in quotes because your SSN isn't a true identity, at least by the cryptographic meaning of the term. It's an identifier. An identity is something that can be used to prove who you are. An identifier is something that stands in for who you are. A proper identity should roughly guarantee non-repudiation. An identifier does not, because it is not secret. It is not possible for someone to steal a true identity, or anything that even approaches one. It is trivial to steal an identifier; it need only be shared once, and then it is no longer secret.
Thus, "identity theft" is a misnomer. It should be called "SSN theft", or even "unauthorized SSN use". But if we call called it that, then the credit bureaus couldn't pretend that the problem is a serious problem caused by a bunch of bad people, rather than an entirely artificial problem of their own making....
The again, if everyone who found a false entry on his or her credit report sued the credit bureau for libel, the problem might just take care of itself.
User names aren't hashed, they are sometimes displayed, so they aren't secret.
That's not strictly true. It depends a lot on the nature of the site. On a banking site, for example, the username could theoretically be an account number. At the very least, the account number is likely to be your initial username when you first sign in to create an online account associated with a brick-and-mortar bank. In that case, the username actually would be secret, and wouldn't be displayed anywhere publicly (and wouldn't be displayed in full even within your account when logged in, typically).
And even on discussion forums, if the forum makes a distinction between the screen name (the visible name) and the actual login name, then the login name (often an email address) can be seen as at least somewhat secret. Such a distinction provides a lot of added security by making it considerably harder to guess someone's login credentials based solely on their public postings and password guessing, because the attacker also has to guess an email address. It isn't that the email address itself is secret, per se, so much as that the association between a given screen name and an underlying email address is secret.
Mind you, in no case is it likely to demand the same level of secrecy as a hashed password, though ostensibly you could construct a site that would give that level of secrecy by hashing both the email address and the password, and keeping only the screen name unhashed. Then, when the user logs in or requests a password change, you'd hash the email address and compare the hashes. Whether this would make sense or not depends largely on whether the email address is being stored for other purposes, such as allowing the user to subscribe to threads.
Ignoring the red flag, though, means that you continue doing what you're doing and it becomes someone else's problem.
Funny, sad, and true, all at the same time.
The thing is, the IRS has plenty of incentives to ignore those sorts of problems. After all, a lot of illegal immigrants who pay taxes do so using a fake SSN. So they end up getting forms with two different names, two different employers, two different addresses in different areas, etc., and if they went to investigate, they would just lose revenue by deporting one of those families, thus losing the income taxes that they previously paid. When's the last time the government went out of their way to cost themselves income?
You've obviously never driven on El Camino Real through Mountain View in rush hour. Let me fix that for you.
After being lost on El Camino Real for hours and hundreds of yards, the car simply lost its will to live and was looking for a safe-ish place to park for the night.
I'm okay with the H1-B program when used as intended. The problem is that for all intents and purposes, it is never used as intended, and instead has just become a way for companies to bring in labor at often 15% or more below the going market rate for the area.
It has been my contention for many years that the H1-B program should be dismantled outright, and replaced with a new program designed by people who learned from the mistakes of the previous program. This new program will, of course, become rife with abuse after five to ten years, at which point it, too, should be dismantled and replaced with a new program that avoids the mistakes of its predecessor. And so on.
In practice, any system will eventually become abused. That's why the most important thing a government program can do is change frequently, to continually stay ahead of the abusers. This will never actually eliminate the abuse, of course, but it will at least keep it at a slow rolling boil.
A hash can't do that. Actually, a hash is designed to not allow that. The distance of two sources should always be completely unrelated to the distance of the respective hashes.
Not necessarily. It is a property of a good hash for cryptographic purposes, but it isn't inherent in the definition of a hash. Strictly speaking, a hash has only two requirements: that an input maps to exactly one output every time, and that more than one input produces a single output. In many cases, you want similar inputs to hash to similar outputs, to make searching a large data set easier (for example, when searching for a matching image). That's a hash function, too; it simply wouldn't be considered a good cryptographic hash.
Anyone who cares to can watch a YouTube video, spend $20 at the local hobby shop to get the materials, and spend a couple of hours turning an image of a fingerprint into a gummi finger which will fool most sensors. However, that doesn't mean it's worthless. It only means it's worthless against someone who is willing to do that.
The problem is, the fingerprint is already on the scanner, so there's probably a way to do it with a lot less effort. We just don't know what it is yet.
First, I write a fair amount of open source software. I've released source code for tools that parse source code and emit documentation, libraries for parsing and writing OMF files (Bento containers), code for parsing BIAS Deck project files (for moving content off of a dead audio software platform), various cool shell scripts (by definition, open source, I suppose), minor bug fixes to libxml2's HTML parser.... And I used to be involved in shipping a couple of Linux ports back in the day. When I have the option to open the source of code that I write, I almost invariably do so. So don't lecture me about opening up my source code. You're preaching to the choir here. Besides, in the case of the software I'm working on at the moment, the software would actually not serve the public's interests nearly as well if it were open source for reasons that I won't go into in a public forum (and no, the reasons don't involve DRM or advertising).
Second, there's a huge difference between source code for an app that end users are supposed to use and a framework that developers are supposed to incorporate into their own products. Out of the dozens of apps that I use, I can count the number that can make or break my ability to get an app out the door on one hand. Basically, Xcode and the tools that ship as part of it. Everything else has drop-in replacements. Photoshop acting up? Switch to Pixelmator. Buggy text editor? Use another one. And so on. So the fact that those tools are closed source is of only moderate concern, with the exception of Xcode, which I very much wish were Open Source, both because it is such a critical part of the process and because it can be pretty cranky at times.
By contrast, a closed framework is another animal entirely, because it puts the very success of software that I'm writing entirely in the hands of another programmer. They rank right up there with Xcode in terms of their ability to cause harm, because they are part of your app. If something happens in six months, and one of those ad networks starts delivering ads that cause a particular version of an ad framework to crash constantly, you may or may not be able to adequately kill that app framework in a way that gets your app back to a functional state without shipping a new version of the app and waiting up to two weeks for Apple to review. And even then, the only thing you can do is to disable one of your sources of revenue.
By contrast, with an open source framework, if it starts crashing, you can report the problem upstream and simultaneously start figuring out why it is happening, potentially fixing the problem, or at least figuring out what edge case triggers the crash so that you can ask the ad network to temporarily suspend ads that would trigger the edge case. So this is a much, much, much better position to be in.
Thankfully, enough people called those folks bozos that they eventually relented. And then, many of the same people left Apple and made the exact same mistake with another company called Palm....
No, that's clearly not what the GP meant. The GP meant that the car would cut a corner, drive across the beach, and crash into the underground coral reefs. I would have thought that was obvious from context....
App developers have only limited time to devote to such things. Sure, when we integrate a brand new framework, we dig in a bit to see if there's anything suspicious, but apps have to routinely update these third-party frameworks to the latest versions to fix bugs and crashes. It just isn't practical for developers to give that level of scrutiny to every minor update. If we did, we'd never have time to do anything but update third-party frameworks.
This is, BTW, why framework developers should not be in the business of supplying precompiled binaries. The framework devs are causing added security risk for app developers, and also exposing themselves to significant liability if they make a mistake like this. And when Apple has to make a compiler change for something like app slicing or whatever, closed-source frameworks cause huge overhead for developers that wouldn't exist if all the code were being compiled by the actual developer. And when there are bugs (which there always are), closed-source frameworks make working around them a big headache. So they really are a nightmare for us.
And trust me when I say that there's nothing in your ad or analytics framework that is so amazing that it qualifies as a competitive advantage. If you think otherwise, you're only kidding yourselves. Just open the source already.
Ads. Unfortunately, most of the advertising frameworks out there are closed source. And buggy. I've spent way more time than I'd like working around bugs in closed source frameworks by hot-patching system libraries to prevent them from doing things that cause problems (leaks, crashes, etc.). But if you want to show mobile ads from those companies and get paid, your only option is to use their frameworks, and to deal with their closed-sourcedness.
Annoyingly, neither the Slashdot story nor the linked story nor the blog post linked from there contains the name of the actual framework. So someone who should have known better, whose reputation should get tarnished, doesn't get his/her/their reputation tarnished, all the while exposing potentially a quarter million developers to the risk of getting their reputations unfairly tarnished by this poorly created framework. That's seriously uncool.
Slashdot Mirror
For some reason, I thought they had built protections into the system to prevent adding arbitrary keys without telling the user, but apparently I'm wrong, or if I'm right, then it isn't discussed in the white paper.
The short answer (apparently) is that upon subpoena, the government could compel Apple to add a new public key and forward a copy of all the traffic for a particular user. However, Apple cannot provide access to messages that have been sent previously, because there's no mechanism for telling existing devices to send a copy of their messages to a new device.
Them, too.
Not really. Gun control actually has some basis in logic, which is that a significant percentage of gun deaths are either accidental or occur because of firearms stolen from someone who bought them legally. It provably makes it harder for criminals to get guns. The debate is over how much harder it makes it, and whether the inconvenience to everyone else is worth it.
With encryption, the bad guys (for any definition of "bad guys" you might choose) have access to encryption already, and unlike guns, once you have software, you can make an infinite number of copies of it without cost. So there can be no rational debate over whether banning encryption makes it harder for the bad guys to gain access to it, because the answer is an incontrovertible no.
You misread the GP. In that hypothetical scenario, the defendant is the government.
Yeah, but now there will be twice as many active users!
For a checking account, that is true, but it isn't true for (for example) a credit card account number or a savings account number.
When the banking system as a whole was set up initially, the assumption was that most of your money would be in a savings account, and that your checking account would contain only enough money to handle typical transactions. If it suddenly went empty because of fraud, the bank could cover the loss. That breaks down somewhat if you're doing everything with one account, obviously, but that's another issue entirely.
Either way, the general advise that the banks give is to treat the account number as a secret, and to not give it out unless necessary (which means writing checks only to people you trust at least to some degree). After all, once I have your account number, I can very easily get a deck of checks printed with that number, and it is unlikely that I would get caught, so long as I shopped in random places that are all far from home. But it is secret only because the system is fundamentally broken, once again treating a mere identifier as an identity.
Both of those examples were wars of secession by a group of countries/territories who wanted religious freedom that was being denied to them by their government. As such, religion was at best tangential. It could have just as easily been a fight over freedom to drink beer on Sundays for all religion mattered to the situation. What mattered was that their freedoms were being limited, and they didn't like it.
Also, although the Thirty Years War started as a war over religion, it quickly turned into a much broader conflict between warring regional superpowers that had nothing to do with religion. That's why the death toll rose into the millions.
Also, the Protestant Reformation is not generally considered to have ended until more than a hundred years after the Thirty Years War. So IMO, neither of those wars can be considered to have been fought among "modern" Christians, because the dust hadn't really settled yet.
No, that's not what I said. What Paul said was in a nearly two-thousand-year-old dead language (Koine Greek). We don't know precisely what some of those words meant in that day. We can only approximate it based on how those words were translated into other languages later, both in that text and in other texts over the course of centuries. And when the same word has been translated in radically different ways in different passages from different authors, it is pretty certain that (at least) one of those translations is wrong. You can pretty flip a coin about which one, and you'll be right half of the time, but you cannot know with any certainty which half of the time.
No, any Christian who makes that argument is literally ignoring the words of really, really bad, highly inconsistent translations of their own holy book. The people who actually study the original texts in the original language don't agree with one another about what those words mean. The word Arsenokoites appears twice in the Bible, both times in Paul's writings; the word never appeared previously in any text, and only appears 80 times in all of known literature. Other texts from the time appear to imply that it actually meant prostitution, orgies, homosexual acts by straight people, sex with children, incest, rape.... Later texts even said that men could commit that sin with their wives, which pretty much rules out the translation that you're dogmatically clinging to, though it does not definitively do so, because the meaning of the word could have shifted over those five hundred years or so.
Either way, the point is that nobody has the slightest idea what the original meaning of the word was. For all we know, for the people to whom Paul was writing, it might have been local slang for "having sex with sheep". We just don't know.
As everyone with even the most peripheral ties to the tech industry knows, the average six-year-old is more tech literate than an average member of the news media. The only people less computer savvy are politicians.
As for the information they can't get, there's a lot. With end-to-end encryption as is used on services like Apple's iMessage, the data exists only on the devices at either end of the communication, and the keys exist only there. They can tell you who communicated with whom, but they can't tell you the contents of the communication.
But here's what the politicians don't seem to understand: The tech industry did all of this as a direct response to government abuse, mostly by major first-world governments like those in the U.S. and Britain, rather than by all the third-world governments that you might ordinarily imagine would be guilty of spying on their citizens. Those companies tried using encryption that could be broken upon subpoena; they tried that first, because it seemed like the best compromise between security and... well, security. But major governments abused that subpoena power massively, creating secret courts that they could use to perform data collection without public oversight. After those governments effectively took the "secure except with a subpoena" option off the table as a viable means of protecting privacy rights, the only remaining option available to the tech companies that could prevent those governments from massively overstepping their authority and abusing the rights of the public at large was to design systems in such a way that it was impossible to break into the data stream even with a court order to do so without the user becoming aware that their communication had been compromised.
This is the natural evolution of security. Bad people attack security and try to create back doors. Good people find ways to bolster the systems to prevent those bad people from doing so. Eventually, the systems become so robust that they are not vulnerable to most feasible attacks. The governments of the world had every opportunity to get these companies to build systems that could be monitored when necessary. All they had to do was act like responsible adults, and only use their subpoena power when it was absolutely necessary to save lives. Instead, they chose to abuse that power. Now, it is too late. Those in power should have shown restraint when they had the chance.
The thing is, the public has a fundamental right to have access to encryption that is as good as what the terrorists have. Anything less would be an unconscionable abrogation of the public's rights, without any real effect on terrorism. After all, it would take a decent software engineer all of a couple of days to write an end-to-end encrypted chat application in which the user must enter a passcode prior to decrypting any data stored on the device, and in which the data is always encrypted with the recipient's public key prior to transmission, so the bad guys will always have access to end-to-end encryption. The key exchange can be tricky, but trust is always a tricky issue in general, and is kind of a separate issue.
In the fight against terrorism, the trust policy is always going to be the weak point that can be exploited—government officials pretending to be potential terrorists so that they can infiltrate the organization, government officials creating honeypots that pretend to be terrorist recruiting sites so that they can prevent people from joining the real organizations by burying them in the noise, etc. Once trust is established—once terrorists have actually become part of such an organization, any hope of further interception of their communication is a hopeless cause, and anybody who says otherwise is kidding him/herself.
And before anyone brings it up, this isn't at all like gun control. Terrorists don't frequently steal their end-to-end encryption from other people; if it is not available legally, they can re-develop it themselves with only a modicum of effort. So fighting terrorism by banning encryption is more like fighting gang violence by banning the legal sale of bandanas, and makes exactly as much sense.
In much the same way that being a good Christian does not require you to stone adulterers and people who wear cotton-poly blends, Christianity as a general system of faith does not inherently declare homosexuality to be sinful. Jesus gave a new covenant, superseding the Old Testament laws, including that one. The only New Testament bits about homosexuality are in Paul's writing, and that translation is considered dubious by many biblical scholars. So although one could argue that Christians of certain specific denominations are "bad" in some sense of the word if they don't consider homosexuality to be a sin, you can't generalize that to all of Christianity.
Financial systems already have to cope with two entirely overlapping sets of numbers—taxpayer identification numbers and SSNs. Both are nine-digit numbers. One has a single hyphen after the second digit, and the other has two hyphens. So it isn't as though you can just store the nine-digit number and ignore the rest of the string. To be useful, an SSN really needs to be stored as a ten- or eleven-digit string, and must be compared using string comparisons, not numeric comparisons.
Thus, it would make more sense to make the new batch of SSNs be dddd-dd-ddd, and construct the actual digits in exactly the same way that they do now. That would give an additional billion SSNs without any significant impact on anything. In fact, there are 8 possible single-hyphen variants, and we've only used one, which leaves seven billion more. There are 28 possible pairings of two hyphens (if I counted correctly), of which we have used only one, which leaves 27 billion additional values. You can also have zero hyphens, assuming that software doesn't have any checks that pitch a fit if you do that. Add them all together, and you get a whopping 35 billion possible additional SSNs or TINs at your disposal without the need to add any more digits. And you could also have variants that drop digits, which pushes the number up even higher.
Just to clarify, it is possible to steal a digital identity, but it is not possible to steal a digital identity when used correctly, e.g. when you use your private key to encrypt a nonce, and someone else decrypts that nonce with your public key to verify that you really do possess the private key associated with that public key.
Banks are, but AFAIK, the credit bureaus aren't. They're the root of the problem. If the credit bureaus really wanted to end so-called "identity theft", they could do it very easily. It would simply require them to invest the money to perform a callback authentication to all registered phone numbers prior to issuing new credit. Boom. No more "identity theft", or at least so many orders of magnitude less that the remainder could be treated as noise.
I put that in quotes because your SSN isn't a true identity, at least by the cryptographic meaning of the term. It's an identifier. An identity is something that can be used to prove who you are. An identifier is something that stands in for who you are. A proper identity should roughly guarantee non-repudiation. An identifier does not, because it is not secret. It is not possible for someone to steal a true identity, or anything that even approaches one. It is trivial to steal an identifier; it need only be shared once, and then it is no longer secret.
Thus, "identity theft" is a misnomer. It should be called "SSN theft", or even "unauthorized SSN use". But if we call called it that, then the credit bureaus couldn't pretend that the problem is a serious problem caused by a bunch of bad people, rather than an entirely artificial problem of their own making....
The again, if everyone who found a false entry on his or her credit report sued the credit bureau for libel, the problem might just take care of itself.
This is what databases are for.
select new_passport_number from passport_map where old_passport_number = '...';
Run in a loop until you don't get a new value. Add old and new country codes in there for good measure.
That's not strictly true. It depends a lot on the nature of the site. On a banking site, for example, the username could theoretically be an account number. At the very least, the account number is likely to be your initial username when you first sign in to create an online account associated with a brick-and-mortar bank. In that case, the username actually would be secret, and wouldn't be displayed anywhere publicly (and wouldn't be displayed in full even within your account when logged in, typically).
And even on discussion forums, if the forum makes a distinction between the screen name (the visible name) and the actual login name, then the login name (often an email address) can be seen as at least somewhat secret. Such a distinction provides a lot of added security by making it considerably harder to guess someone's login credentials based solely on their public postings and password guessing, because the attacker also has to guess an email address. It isn't that the email address itself is secret, per se, so much as that the association between a given screen name and an underlying email address is secret.
Mind you, in no case is it likely to demand the same level of secrecy as a hashed password, though ostensibly you could construct a site that would give that level of secrecy by hashing both the email address and the password, and keeping only the screen name unhashed. Then, when the user logs in or requests a password change, you'd hash the email address and compare the hashes. Whether this would make sense or not depends largely on whether the email address is being stored for other purposes, such as allowing the user to subscribe to threads.
Funny, sad, and true, all at the same time.
The thing is, the IRS has plenty of incentives to ignore those sorts of problems. After all, a lot of illegal immigrants who pay taxes do so using a fake SSN. So they end up getting forms with two different names, two different employers, two different addresses in different areas, etc., and if they went to investigate, they would just lose revenue by deporting one of those families, thus losing the income taxes that they previously paid. When's the last time the government went out of their way to cost themselves income?
You've obviously never driven on El Camino Real through Mountain View in rush hour. Let me fix that for you.
I'm okay with the H1-B program when used as intended. The problem is that for all intents and purposes, it is never used as intended, and instead has just become a way for companies to bring in labor at often 15% or more below the going market rate for the area.
It has been my contention for many years that the H1-B program should be dismantled outright, and replaced with a new program designed by people who learned from the mistakes of the previous program. This new program will, of course, become rife with abuse after five to ten years, at which point it, too, should be dismantled and replaced with a new program that avoids the mistakes of its predecessor. And so on.
In practice, any system will eventually become abused. That's why the most important thing a government program can do is change frequently, to continually stay ahead of the abusers. This will never actually eliminate the abuse, of course, but it will at least keep it at a slow rolling boil.
Not necessarily. It is a property of a good hash for cryptographic purposes, but it isn't inherent in the definition of a hash. Strictly speaking, a hash has only two requirements: that an input maps to exactly one output every time, and that more than one input produces a single output. In many cases, you want similar inputs to hash to similar outputs, to make searching a large data set easier (for example, when searching for a matching image). That's a hash function, too; it simply wouldn't be considered a good cryptographic hash.
The problem is, the fingerprint is already on the scanner, so there's probably a way to do it with a lot less effort. We just don't know what it is yet.
First, I write a fair amount of open source software. I've released source code for tools that parse source code and emit documentation, libraries for parsing and writing OMF files (Bento containers), code for parsing BIAS Deck project files (for moving content off of a dead audio software platform), various cool shell scripts (by definition, open source, I suppose), minor bug fixes to libxml2's HTML parser.... And I used to be involved in shipping a couple of Linux ports back in the day. When I have the option to open the source of code that I write, I almost invariably do so. So don't lecture me about opening up my source code. You're preaching to the choir here. Besides, in the case of the software I'm working on at the moment, the software would actually not serve the public's interests nearly as well if it were open source for reasons that I won't go into in a public forum (and no, the reasons don't involve DRM or advertising).
Second, there's a huge difference between source code for an app that end users are supposed to use and a framework that developers are supposed to incorporate into their own products. Out of the dozens of apps that I use, I can count the number that can make or break my ability to get an app out the door on one hand. Basically, Xcode and the tools that ship as part of it. Everything else has drop-in replacements. Photoshop acting up? Switch to Pixelmator. Buggy text editor? Use another one. And so on. So the fact that those tools are closed source is of only moderate concern, with the exception of Xcode, which I very much wish were Open Source, both because it is such a critical part of the process and because it can be pretty cranky at times.
By contrast, a closed framework is another animal entirely, because it puts the very success of software that I'm writing entirely in the hands of another programmer. They rank right up there with Xcode in terms of their ability to cause harm, because they are part of your app. If something happens in six months, and one of those ad networks starts delivering ads that cause a particular version of an ad framework to crash constantly, you may or may not be able to adequately kill that app framework in a way that gets your app back to a functional state without shipping a new version of the app and waiting up to two weeks for Apple to review. And even then, the only thing you can do is to disable one of your sources of revenue.
By contrast, with an open source framework, if it starts crashing, you can report the problem upstream and simultaneously start figuring out why it is happening, potentially fixing the problem, or at least figuring out what edge case triggers the crash so that you can ask the ad network to temporarily suspend ads that would trigger the edge case. So this is a much, much, much better position to be in.
Thankfully, enough people called those folks bozos that they eventually relented. And then, many of the same people left Apple and made the exact same mistake with another company called Palm....
No, that's clearly not what the GP meant. The GP meant that the car would cut a corner, drive across the beach, and crash into the underground coral reefs. I would have thought that was obvious from context....
App developers have only limited time to devote to such things. Sure, when we integrate a brand new framework, we dig in a bit to see if there's anything suspicious, but apps have to routinely update these third-party frameworks to the latest versions to fix bugs and crashes. It just isn't practical for developers to give that level of scrutiny to every minor update. If we did, we'd never have time to do anything but update third-party frameworks.
This is, BTW, why framework developers should not be in the business of supplying precompiled binaries. The framework devs are causing added security risk for app developers, and also exposing themselves to significant liability if they make a mistake like this. And when Apple has to make a compiler change for something like app slicing or whatever, closed-source frameworks cause huge overhead for developers that wouldn't exist if all the code were being compiled by the actual developer. And when there are bugs (which there always are), closed-source frameworks make working around them a big headache. So they really are a nightmare for us.
And trust me when I say that there's nothing in your ad or analytics framework that is so amazing that it qualifies as a competitive advantage. If you think otherwise, you're only kidding yourselves. Just open the source already.
But I digress.
Ads. Unfortunately, most of the advertising frameworks out there are closed source. And buggy. I've spent way more time than I'd like working around bugs in closed source frameworks by hot-patching system libraries to prevent them from doing things that cause problems (leaks, crashes, etc.). But if you want to show mobile ads from those companies and get paid, your only option is to use their frameworks, and to deal with their closed-sourcedness.
Annoyingly, neither the Slashdot story nor the linked story nor the blog post linked from there contains the name of the actual framework. So someone who should have known better, whose reputation should get tarnished, doesn't get his/her/their reputation tarnished, all the while exposing potentially a quarter million developers to the risk of getting their reputations unfairly tarnished by this poorly created framework. That's seriously uncool.