On one hand, if the (looks like 000 gauge) conductors connecting the rails are being stolen, that could post a problem. On the other hand, since there are 4 paddles on each side of each car (as the 3rd rail can be on either side, depending on which side the platform is on at the next station), each car maintains contact with both rails as it transitions from one to the next. Likewise for the wheels, making the ground connection for each car. Coupled with the fact that cars share power, a 10 car train will be in contact with 4 or 5 rail pairs at any given moment, a majority of the bonding conductors would have to be missing or severely damaged to cause even a minor power issue. Cars are sized such that when the front of the train is crossing a rail threshold, the rear of the train is in the middle of a rail, so good contact is guaranteed at all times unless the first or last car is severely damaged and missing at least two paddles on the 3rd rail side. Even then, the likelihood of damage is minuscule.
We certainly are talking about the iCloud password, if you were paying attention to the thread, so 90% of what tou wrote was pointless. The other 10% is flat-out wrong.
As for there being no record of the password, there is certainty a hash to compare against for login purposes, otherwise how would Apple's systems know if you entered the correct password? Freakin' magic? No. There is a record to compare against and, if Apple retains the old hashes, rather than overwriting them, they can roll back to the previous one, which the iPhone is attempting to use for its iCloud backups.
Take it from someone who does this for a living, there is certainly a record of some value that can be determimistically generated from the password entered by the user. These things aren't magic.
I'm pretty sure you're right. I mean, I and the AC I was replying to can't possibly have thought of that before the bright minds at the FBI, right? The issue, then, is that they think we're all dumb enough to not see through the bullshit. Here's the thing, though: they're smart, and they've all been kids, which means they were smart kids; kids call other smart kids dumb all the time and, having been smart kids, they'll have experienced that. And, being smart people, they know how infuriating (and motivating) it is for a smart person to be called dumb. Unless they want to be on the wrong side of a revolution, they may want to check themselves; there are a lot of smart people following this, most of whom have to be just about done being played for fools. This thread contains only a handful of us.
I wonder... does Apple actually overwrite the existing credential record when a password is changed, or do they create a new record and mark the old one as invalid? If they do the latter, they can roll back to the old password and allow the backup to take place. The FBI should, perhaps, ask about this.
You hear that, FBI? I know you're following these stories and reading these comments. Follow up.
Yes, and amortized over the lifetime of the company, that cost is much, much lower than the cost of the bandwidth to stream 720p and higher to devices which, for the most part, can't display it. In fact, you don't have to amortize it quite that far out; maybe a couple months or so.
The same way apple could? You mean via a signed update binary? Sure, they could, if they has Apple's signing key, which is precisely the situation in which Apple would want to update the key.
Please, for the love of God, stay away from any security-related work.
That wasn't an oversight, it was never a point under argument to begin with. Of course they don't care if the information exists elsewhere if they can decrypt your phone; my point was, if the only place the information exists of your lhone, they must admit the ability to do so in order for it to be admissable in court. If you keep potentially incriminating information behind strong encryption, they can't successfully carry out parallel construction.
You sure about that? It seems to me that Apple would bebe smart enough to have a contingency plan in case their signing key were ever compromised. If what you say, iOS devices just jumped to the top of my "do not buy, destroy current stock" list for being irrepairably insecure in the enevitable event that the signing key is leaked, stolen, randomly guessed, reversed, or otherwise compromised.
It delays Apple's ability to roll out a fix by requiring them to wait for a 3rd party to sign their work. I'm not sure how much more clear I can make that.
As for why an additional 3rd party signature actually makes this less secure: a knowledgeable attacker would already have access to the other key before going after the key Apple keeps locally. Then, it becomes a race; can the attacker get their exploit distributed before the 3rd party signer signs Apple's fix? By taking the 3rd party out of the equation, you take away the attacker's potential advantage; only Apple needs to sign the fix and Apple can do that quite quickly.
The issue is, if the data exists elsewhere, they don't need access to my phone to get it. It's called performing an actual investigation and it's their job. You're right, though, it does happen regularly; just not with strong encryption.
I think it would be just as plausible to propose that a "knowledgeable attacker" would already have access to Apple's key—which would be even more of a problem if Apple's key were the only key
I'm going to assume you didn't read my entire post, as I actually address why that is not the case.
Technically, it's Apple's lawyers and the DOJ's lawyers; and they're the ones who would be facing sanctions and disbarment, leaving Apple and the DOJ to find new lawyers.
And yes, I meant "pose a problem", not "post a problem". My fault for not proofreading.
On one hand, if the (looks like 000 gauge) conductors connecting the rails are being stolen, that could post a problem. On the other hand, since there are 4 paddles on each side of each car (as the 3rd rail can be on either side, depending on which side the platform is on at the next station), each car maintains contact with both rails as it transitions from one to the next. Likewise for the wheels, making the ground connection for each car. Coupled with the fact that cars share power, a 10 car train will be in contact with 4 or 5 rail pairs at any given moment, a majority of the bonding conductors would have to be missing or severely damaged to cause even a minor power issue. Cars are sized such that when the front of the train is crossing a rail threshold, the rear of the train is in the middle of a rail, so good contact is guaranteed at all times unless the first or last car is severely damaged and missing at least two paddles on the 3rd rail side. Even then, the likelihood of damage is minuscule.
It is almost certainly a supply problem.
I see you haven't been to the bay area in a while.
We certainly are talking about the iCloud password, if you were paying attention to the thread, so 90% of what tou wrote was pointless. The other 10% is flat-out wrong.
As for there being no record of the password, there is certainty a hash to compare against for login purposes, otherwise how would Apple's systems know if you entered the correct password? Freakin' magic? No. There is a record to compare against and, if Apple retains the old hashes, rather than overwriting them, they can roll back to the previous one, which the iPhone is attempting to use for its iCloud backups.
Take it from someone who does this for a living, there is certainly a record of some value that can be determimistically generated from the password entered by the user. These things aren't magic.
I'm pretty sure you're right. I mean, I and the AC I was replying to can't possibly have thought of that before the bright minds at the FBI, right? The issue, then, is that they think we're all dumb enough to not see through the bullshit. Here's the thing, though: they're smart, and they've all been kids, which means they were smart kids; kids call other smart kids dumb all the time and, having been smart kids, they'll have experienced that. And, being smart people, they know how infuriating (and motivating) it is for a smart person to be called dumb. Unless they want to be on the wrong side of a revolution, they may want to check themselves; there are a lot of smart people following this, most of whom have to be just about done being played for fools. This thread contains only a handful of us.
I wonder... does Apple actually overwrite the existing credential record when a password is changed, or do they create a new record and mark the old one as invalid? If they do the latter, they can roll back to the old password and allow the backup to take place. The FBI should, perhaps, ask about this.
You hear that, FBI? I know you're following these stories and reading these comments. Follow up.
Damn, I literally just posted in this thread; this was the next post I read after. I'd mod you Insightful if I could.
You can dial #BNG# (#264#) to check your Binge On status, #BON# (#266#) to turn it on, or #BOF# (#263#) to turn it off.
I repeat: Dial #263# to turn it off.
Yes, and amortized over the lifetime of the company, that cost is much, much lower than the cost of the bandwidth to stream 720p and higher to devices which, for the most part, can't display it. In fact, you don't have to amortize it quite that far out; maybe a couple months or so.
Ahh, he got cut down to owning literally nothing but the furniture? Yeah, in that case I'd have done the same.
Sprint or Verizon?
I wonder if his face misses his nose worse than he does at this point.
The same way apple could? You mean via a signed update binary? Sure, they could, if they has Apple's signing key, which is precisely the situation in which Apple would want to update the key.
Please, for the love of God, stay away from any security-related work.
Anyone else want to jump in and say this before they read the rest of the thread? At least this one was smart enough to do it anonymously.
That wasn't an oversight, it was never a point under argument to begin with. Of course they don't care if the information exists elsewhere if they can decrypt your phone; my point was, if the only place the information exists of your lhone, they must admit the ability to do so in order for it to be admissable in court. If you keep potentially incriminating information behind strong encryption, they can't successfully carry out parallel construction.
You sure about that? It seems to me that Apple would bebe smart enough to have a contingency plan in case their signing key were ever compromised. If what you say, iOS devices just jumped to the top of my "do not buy, destroy current stock" list for being irrepairably insecure in the enevitable event that the signing key is leaked, stolen, randomly guessed, reversed, or otherwise compromised.
Naw, Apple ain't that dumb.
As for why an additional 3rd party signature actually makes this less secure: a knowledgeable attacker would already have access to the other key before going after the key Apple keeps locally. Then, it becomes a race; can the attacker get their exploit distributed before the 3rd party signer signs Apple's fix? By taking the 3rd party out of the equation, you take away the attacker's potential advantage; only Apple needs to sign the fix and Apple can do that quite quickly.
The issue is, if the data exists elsewhere, they don't need access to my phone to get it. It's called performing an actual investigation and it's their job. You're right, though, it does happen regularly; just not with strong encryption.
I think it would be just as plausible to propose that a "knowledgeable attacker" would already have access to Apple's key—which would be even more of a problem if Apple's key were the only key
I'm going to assume you didn't read my entire post, as I actually address why that is not the case.
You clearly made the same mistake the other poster made and failed to read my entire comment before posting.
I address that in the part of my comment you didn't quote.
This is business as usual on Slashdot...
Sorry for the misunderstanding, the sarcastic tone didn't come through in your text.
Technically, it's Apple's lawyers and the DOJ's lawyers; and they're the ones who would be facing sanctions and disbarment, leaving Apple and the DOJ to find new lawyers.
So we should use XOR along with XEITHER?