Wait... i'm confused. Yes, that is exactly what you wrote, but why would you mean that? I thought you were saying it wasn't stellar? Am I being stupid in thinking stellar is positive?
It sucks, but you should learn to wrangle 'equivs' (for Debian based distros).
Make a package that 'provides' something, and you can remove the other.
Note though that you really have to know what you're doing. It's easy to break stuff by tricking the package system into thinking something is there when it's not.
Interesting, so you're saying you have millions of data points behind you?
I can't be bothered to tally mine up, and I'm sure the same is true for you. That we're even having this conversation is proof enough that it's fucked enough to have an unacceptable rate of failure.
That's no fun position to be in. Like any other thing, this is a case of a few bad apples. I'm not going to comment one way or another on the effectiveness of the measures, as that's really the responsibility of the people at the top. The people in the airports are just parts of the machine like the rest of us.
Now, that said, the bad apples do deserve a good 'beating' - but we should try to limit this to the true abusers.
Our problem is that we have workstations that cannot negotiate connections despite having valid certificates. The certs install fine, just don't work.
Yes, i'm sure its our fault. understood.
That's entirely Microsoft's shoddy implementation at fault. YOU think the certificate is valid. The OS disagrees. It's not the certificate's fault the OS won't listen to your instructions to trust it.
However the browser should alert when ever there is a data stream that looks like a social security number or pushes a request for such non-merchant information.
Then change it to your subject. If you're subject is still the same, don't change it. But you still put the subject there, not the first part of the body.
For your first example, they don't. Well, if they did exactly what you wrote, then you should report them because they are doing something explicitly not allowed. They are prohibited from showing any card number digits beyond the first 6 or last 4.
Regarding the CSC/CVV2 - there is a business incentive to provide it. The more security information they can provide, the lower the fee they pay the processor to handle it. Eg, if they can provide the full track 2 data, they receive an even lower fee than if they provide CSC/CVV2 and/or AVS data. For level-2/level-3 cards, the same applies for the additional information such as the tax ID number.
The first 6 and last 4 digits of a card number are just about useless. The numbers in the middle (and the code on the back) are the important parts. Even still, it's a far cry from having the track 2 data...
I'm not sure where "throwing out the physical media" comes into this. My point was you would be stupid to do so, saving only the key, and if you did so and it burned you, then it's your own fault.
DRM doesn't come into this at all, since you wouldn't have kept a backup copy to begin with. Unless you refer to the digital copy you might keep, which I do have to say... if you can't keep the digital copy, keep the physical one PRECISELY because you can't! If you have your digital copy, then really what's the problem?
Slashdot Mirror
That's why you keep your car keys separate (or detachable).
Did you miss the "laser-based" part? Apparently you did.
Oh. Whoosh. Sorry about that!
Wait... i'm confused. Yes, that is exactly what you wrote, but why would you mean that? I thought you were saying it wasn't stellar? Am I being stupid in thinking stellar is positive?
I don't think that means what you think it means. You just committed a version of the "could care less" mistake.
OK then smartass, make that a static binary. That's one of the cons of dymanic loading.
It sucks, but you should learn to wrangle 'equivs' (for Debian based distros).
Make a package that 'provides' something, and you can remove the other.
Note though that you really have to know what you're doing. It's easy to break stuff by tricking the package system into thinking something is there when it's not.
Interesting, so you're saying you have millions of data points behind you?
I can't be bothered to tally mine up, and I'm sure the same is true for you. That we're even having this conversation is proof enough that it's fucked enough to have an unacceptable rate of failure.
That's no fun position to be in. Like any other thing, this is a case of a few bad apples. I'm not going to comment one way or another on the effectiveness of the measures, as that's really the responsibility of the people at the top. The people in the airports are just parts of the machine like the rest of us.
Now, that said, the bad apples do deserve a good 'beating' - but we should try to limit this to the true abusers.
Our problem is that we have workstations that cannot negotiate connections despite having valid certificates. The certs install fine, just don't work.
Yes, i'm sure its our fault. understood.
That's entirely Microsoft's shoddy implementation at fault. YOU think the certificate is valid. The OS disagrees. It's not the certificate's fault the OS won't listen to your instructions to trust it.
6) I trust my food store not to baby food full of melamine. Whoops.
They accidentally the whole jar?
However the browser should alert when ever there is a data stream that looks like a social security number or pushes a request for such non-merchant information.
I'd love to see you try to implement that...
Yes :)
Shall we get back on the TSA-bashing bandwagon then?
Then change it to your subject. If you're subject is still the same, don't change it. But you still put the subject there, not the first part of the body.
It's a shame starting your reply in the subject field isn't a form of assault either.
You wouldn't start an email in the subject field would you?
For your first example, they don't. Well, if they did exactly what you wrote, then you should report them because they are doing something explicitly not allowed. They are prohibited from showing any card number digits beyond the first 6 or last 4.
Regarding the CSC/CVV2 - there is a business incentive to provide it. The more security information they can provide, the lower the fee they pay the processor to handle it. Eg, if they can provide the full track 2 data, they receive an even lower fee than if they provide CSC/CVV2 and/or AVS data. For level-2/level-3 cards, the same applies for the additional information such as the tax ID number.
The first 6 and last 4 digits of a card number are just about useless. The numbers in the middle (and the code on the back) are the important parts. Even still, it's a far cry from having the track 2 data...
I'm not sure where "throwing out the physical media" comes into this. My point was you would be stupid to do so, saving only the key, and if you did so and it burned you, then it's your own fault.
DRM doesn't come into this at all, since you wouldn't have kept a backup copy to begin with. Unless you refer to the digital copy you might keep, which I do have to say... if you can't keep the digital copy, keep the physical one PRECISELY because you can't! If you have your digital copy, then really what's the problem?
Yes it can...
By removing the human component :P
DESTROY! DESTROY!
Personally I don't care. I'm still not buying Intel if I can help it.
Then you reap what you sow.
Sorry, but you should have known better. Perhaps you do, now.
Lets make it easy for you:
Ordered bits are data. It's information.
Interesting how zombies tend to be a nearly perfect metaphor for this.
Don't forget all the flu strains and such too.
Nature's trying. Give her enough time and she'll get it "right."
Yes, nothing says "pleasant to the eye" like staring into a headlamp...