"It's implemented on the CPU" is the first gigantic red flag here. The implication of this is that it's so tightly specified that it's impossible to implement efficiently (i.e. on all vendors different GPUs which do subtly different things re how the exact pixel colours come out).
You seem to be confusing "this works well on linux" with "this is the perfect solution for all platforms, and it works perfectly across all platforms".
To be honest, I love headers, and I'd love to see more languages use them. Not as a necessity to allow the compiler to see what's declared, but instead, as enforced documentation of what's a public API.
The problem is, what's efficient, or nice, is not well defined. Should you antialias lines? If so, what type of antialiasing? Is that type of AA efficient on the graphics card in use? If you don't do that, do certain programs break?
These are all questions that have been answered before by java –yes, everything breaks, because everyone needs to implement graphics subtly differently.
It had better be both damn well specified, and super under specified at the same time.
If it's not well enough specified, different OSes will do different things re (for example) antialiasing, where they decide the centre of a pixel is, etc
If it's too well specified, no OS will be able to implement it efficiently.
My suspicion is that it'll end up under-specified, and useless because of it, in the same way as java's drawing libraries are typically an endless source of bugs (common ones being that the developer assumed that no AA would happen, and then breaking on OS X or more recent windows installs, and rendering nasty looking halos around things, because the developer assumed they could just over-draw something and it would disappear).
If you're talking customer numbers, not customer serials (as used above) for your optimised case, then the binary case too can be more heavily optimised. Byte 1 encodes 2 bits for the two flags, then 6 bits for the number of bytes the customer ID takes up (as an integer, not a string). This gives you 2 bytes for your first 256 customers, 3 for your next 65280, and 4 for your next 16711680. For most companies that means you're likely to be averaging 3.5 bytes per record, suddenly we've compressed our wire format by more than 50%, and reduced the CPU overhead significantly as we no longer need to un-gzip the stream, then parse a bunch of text.
No, I would bet heavily that if you actually dug down and showed them it happening, they would go "yes, I can see the effect you are describing, but I don't believe that's how humans came to exist".
It's very much the humans coming into existence in this way that is problematic for them.
Given that the above commenter was trying to establish that JSON was not overly verbose, and even his example of how to combat the overly verboseness is overly verbose, what's wrong is that it doesn't back up the argument that JSON isn't overly verbose.
Part of the problem is that even the question is badly wrong. You would have to a complete idiot, and ignore the facts to not "believe" in evolution. We can observe evolution happening right in front of our eyes every day, by staring at bacteria, we can observe it on a larger scale by observing how different species of dogs (because they are by now different species thanks to their size differences making it impossible to interbreed some dogs) have split away from wolves.
Evolution happens. Period.
The real question is "did humans evolve from some lower primate, and eventually from some soupy goop, or was there some other starting state?"
"Oh no, they used one really bad verbose text based encoding, rather than another really bad verbose text based encoding that I happen to like because it's cool these days, both of which have decoding support in the browser. This is clearly what will stop it from ever working properly"
No, they shouldn't. The deal is already done. If they have delivered the goods and accepted the cash, they have no recourse to decide that they either want to magically undo the contract they've already agreed to, or to decide to alter the contract for more money.
Plain and simple, once the deal is done, they can not go back on it, in any way.
No, they're not. The transaction is complete. They offered a certain price for the goods, they accepted the cash, and they gave you the goods. They have no expectation of getting the money out of you now.
Reposting what I posted above, because I failed to log in.
Usually the issue is that by the time the wave arrives at you, you can't figure out which parts of it are actually information, and which parts of it are noise.
I don't understand why any one would use encryption here at all. Why would they not use challenge/response, so that the PIN never leaves the card/keypad (encrypted or not).
As I said above, why are the chip & pin machines not designed to avoid this? Surely the keypad should operate without firmware, and be responsible only for sending the key presses to the card. The card's chip can then generate a response from a hash of the challenge and the PIN, and only then send the data off the card/key pad, and into the system controlled by firmware.
Slashdot Mirror
The problem is that large proportions of the populace of programmers are idiots, and if you show them the private things, they will rely on them.
One simple file that says "this is the public interface, and it's documentation" is an extremely useful tool.
"It's implemented on the CPU" is the first gigantic red flag here. The implication of this is that it's so tightly specified that it's impossible to implement efficiently (i.e. on all vendors different GPUs which do subtly different things re how the exact pixel colours come out).
You seem to be confusing "this works well on linux" with "this is the perfect solution for all platforms, and it works perfectly across all platforms".
To be honest, I love headers, and I'd love to see more languages use them. Not as a necessity to allow the compiler to see what's declared, but instead, as enforced documentation of what's a public API.
The point being that it restricts the attack to MITM, simple phishing no longer works.
You shouldn't tell them their PIN is wrong and that if they get it wrong 2 more times, then their card is going to be blocked? Riiiiight....
The problem is, what's efficient, or nice, is not well defined. Should you antialias lines? If so, what type of antialiasing? Is that type of AA efficient on the graphics card in use? If you don't do that, do certain programs break?
These are all questions that have been answered before by java –yes, everything breaks, because everyone needs to implement graphics subtly differently.
It had better be both damn well specified, and super under specified at the same time.
If it's not well enough specified, different OSes will do different things re (for example) antialiasing, where they decide the centre of a pixel is, etc
If it's too well specified, no OS will be able to implement it efficiently.
My suspicion is that it'll end up under-specified, and useless because of it, in the same way as java's drawing libraries are typically an endless source of bugs (common ones being that the developer assumed that no AA would happen, and then breaking on OS X or more recent windows installs, and rendering nasty looking halos around things, because the developer assumed they could just over-draw something and it would disappear).
You got +5 Funny, I don't know why, this comment is damn insightful.
Ugh. Amateurs! Generate error codes, not descriptive strings! Asshats! Security isn't supposed to reward someone for reverse engineering something. Layers, man. Layers of security!
Uhhh right, because that's so much use to the customer when their security token simply says "error -382".
If you're talking customer numbers, not customer serials (as used above) for your optimised case, then the binary case too can be more heavily optimised. Byte 1 encodes 2 bits for the two flags, then 6 bits for the number of bytes the customer ID takes up (as an integer, not a string). This gives you 2 bytes for your first 256 customers, 3 for your next 65280, and 4 for your next 16711680. For most companies that means you're likely to be averaging 3.5 bytes per record, suddenly we've compressed our wire format by more than 50%, and reduced the CPU overhead significantly as we no longer need to un-gzip the stream, then parse a bunch of text.
No, I would bet heavily that if you actually dug down and showed them it happening, they would go "yes, I can see the effect you are describing, but I don't believe that's how humans came to exist".
It's very much the humans coming into existence in this way that is problematic for them.
Given that the above commenter was trying to establish that JSON was not overly verbose, and even his example of how to combat the overly verboseness is overly verbose, what's wrong is that it doesn't back up the argument that JSON isn't overly verbose.
At that point, you're simply sending really verbose CSV.
Part of the problem is that even the question is badly wrong. You would have to a complete idiot, and ignore the facts to not "believe" in evolution. We can observe evolution happening right in front of our eyes every day, by staring at bacteria, we can observe it on a larger scale by observing how different species of dogs (because they are by now different species thanks to their size differences making it impossible to interbreed some dogs) have split away from wolves.
Evolution happens. Period.
The real question is "did humans evolve from some lower primate, and eventually from some soupy goop, or was there some other starting state?"
"Oh no, they used one really bad verbose text based encoding, rather than another really bad verbose text based encoding that I happen to like because it's cool these days, both of which have decoding support in the browser. This is clearly what will stop it from ever working properly"
That's irrelevant, even if the owner had only sold one copy of his book, he would still not be able to demand it back.
Thank you - if you could +1 you, I would. Great explanation of why this can't work.
No, they shouldn't. The deal is already done. If they have delivered the goods and accepted the cash, they have no recourse to decide that they either want to magically undo the contract they've already agreed to, or to decide to alter the contract for more money.
Plain and simple, once the deal is done, they can not go back on it, in any way.
No, they're not. The transaction is complete. They offered a certain price for the goods, they accepted the cash, and they gave you the goods. They have no expectation of getting the money out of you now.
Reposting what I posted above, because I failed to log in.
Usually the issue is that by the time the wave arrives at you, you can't figure out which parts of it are actually information, and which parts of it are noise.
Actually, return rates show that it's more like 0.5% for some brands, and 2% industry average. Only OCZ surpasses 5%.
Right, because you know, the ISO standard appeared out of thin air, no one ever sat there and thought "should we use encryption or hashing for this?"
I don't understand why any one would use encryption here at all. Why would they not use challenge/response, so that the PIN never leaves the card/keypad (encrypted or not).
As I said above, why are the chip & pin machines not designed to avoid this? Surely the keypad should operate without firmware, and be responsible only for sending the key presses to the card. The card's chip can then generate a response from a hash of the challenge and the PIN, and only then send the data off the card/key pad, and into the system controlled by firmware.