Indeed, the problem originated with LusTrust. However, LusTrust had identified the problem, and released a fixed version (1.4.1) by beginning of June 2012, ironically enough the very week when BCEE deployed the faulty version (... which they still haven replaced by the fixed version).
Then, one month later, CCP deployed the same faulty 1.4 version (although the bugfixed 1.4.1 was available for several weeks by then...), but at least they fixed it 9 months later.
Alas, not for a bank... not for the Spuerkeess, the self-styled "safest" bank in the world... So safe you can't get at your own money, because the web banking is down since one year!
They should just charge a $5 fee and mail it to you if you don't want it destroyed.
Back in the eighties, they did. Well minus the charge. If you had a dangerous item (knife, drafting compass,...), you handed it in at the security checkpoint, it would go into a box in the cargo hold (together with similar items of other passengers), and you got it back on arrival.
Counting all the administrative overhead, the "testing", etc., this may well seem plausible.
It took one large Luxembourgish bank nine months to change SUPPORTED_OS = MAC into SUPPORTED_OS = Linux32 in a configuration file in a jar named LuxTrust_Gemalto_CryptoTI_Adapter_LIN32_1.4.jar (yes, they did indeed accidentally put the Mac config file into the Linux jar... it's that stupid...)
Another bank is celebrating the first year anniversary of this same bug right now as we speak:-) (unfixed yet, of course)
Reason for the slowness (in both cases): when fixing such a mixup, according to their procedures, the entire test suite (... which incidentally, didn't catch this bug in the first place...) needs to be re-run, and this takes weeks, and so they shy away from the expense.
So we end up in the paradoxical situation where the presence doesn't reduce the number of bugs seen in production, but actually increases it. Rather than catching bugs early, the test suite instead perpetuates existing bugs...
Let's call a spade a spade. It's 100% a problem due to opaque binary formats. Had the document been written in (clean) HTML or plain text, it would have stayed usable without problems.
Don't worry, it will get sturdier as the design, and the printers will improve.
3D printing gunpowder and a shell?
A chemistry printer, maybe? You pour nitrogen components, oxygen components, carbon, etc. inside, and it "prints" the right molecules, a little bit like DNA synthesizer does.
So this clown of a police commissioner says his greatest fear is of criminals blowing themselves up with it. Are you serious?
No, but he thinks this is the most effective way to scare people away from downloading and printing it...
Like in the old days with the illegal money changers in East European countries. Police were not telling the tourists: "it's illegal to change money on the street, you might go to jail for it", but "most of these money changers are fraudsters, and will just rip you off".
Are you not just a little bit more worried of people with a grudge against police using it against them, or even innocent people?
Sure he is, but do you really think that telling people that will stop them from downloading it?
I hope you would have to actually shoot someone for it to be fatal.
Nope, it sucks so much that 1 times out of three it explodes in the shooters hand when fired. So it could well be fatal even when fired into a sand bag... fatal to the shooter himself, that is.
Of course, over time, the design will improve, and 3d printers will improve too, so eventually it will be just like any other gun: fatal only to the intended target, but still undetectable and difficult to regulate!
Oh, and you can buy that kind of information already, from his credit card company or bank (who make a very nice profit selling those details anyway) for considerably more cheaply and easily than poisoning the entire internet.
Scary. Fortunately, in my country we have banking secrecy laws. Ooops, had. Most people are concerned about the tax man, but these shenanigans are actually a much bigger threat when banking secrecy goes away.
I think it depends which info exactly is in that mail. Sure firstname and lastname are hardly confidential. But often these confirmations also contain credit card numbers, social security numbers (if the site asked for it), and other stuff you may not be confortable sharing with the world at large.
HTTPS means that you have a securely encrypted connection with the remote server. Not that the people who own the remote server are going to keep your privacy sacred.
But it does mean that nobody on the path can listen in on the connection. Which is defeated if then the same info is sent back over an unencrypted channel.
No smpt doesn't support encryption between servers.
Actually it does. But obviously both servers (sender and receiver) must be configurered to use it (which most aren't, unfortunately). And sender must be configured to check receiver's certificate (which even less are).
It's not a protocol issue, but a configuration issue.
And knowing this, it is indeed unwise to include such confidential info in an e-mail.
Slashdot Mirror
SOLIDS rarely explode
Yes, even the TSA knows this. There's a reason they ban large quantities of fluids, but don't object to much larger quantities of solids.
It's like mushrooms. All mushrooms are edible. But some only once...
... and how quickly the sulfur does its thing. Hey, it's the material that matches are made of!
Seems like the problem originated from LuxTrust?
Indeed, the problem originated with LusTrust. However, LusTrust had identified the problem, and released a fixed version (1.4.1) by beginning of June 2012, ironically enough the very week when BCEE deployed the faulty version (... which they still haven replaced by the fixed version).
Then, one month later, CCP deployed the same faulty 1.4 version (although the bugfixed 1.4.1 was available for several weeks by then...), but at least they fixed it 9 months later.
BCEE's site is still broken though.
Luxembourg in a nutshell: Slow, but thorough...
The girls would love it...
Alas, not for a bank... not for the Spuerkeess, the self-styled "safest" bank in the world... So safe you can't get at your own money, because the web banking is down since one year!
And then what about their radio broadcasts, which are worldwide.
They should just charge a $5 fee and mail it to you if you don't want it destroyed.
Back in the eighties, they did. Well minus the charge. If you had a dangerous item (knife, drafting compass, ...), you handed it in at the security checkpoint, it would go into a box in the cargo hold (together with similar items of other passengers), and you got it back on arrival.
It took one large Luxembourgish bank nine months to change SUPPORTED_OS = MAC into SUPPORTED_OS = Linux32 in a configuration file in a jar named LuxTrust_Gemalto_CryptoTI_Adapter_LIN32_1.4.jar (yes, they did indeed accidentally put the Mac config file into the Linux jar... it's that stupid...)
Another bank is celebrating the first year anniversary of this same bug right now as we speak :-) (unfixed yet, of course)
Reason for the slowness (in both cases): when fixing such a mixup, according to their procedures, the entire test suite (... which incidentally, didn't catch this bug in the first place...) needs to be re-run, and this takes weeks, and so they shy away from the expense.
So we end up in the paradoxical situation where the presence doesn't reduce the number of bugs seen in production, but actually increases it. Rather than catching bugs early, the test suite instead perpetuates existing bugs...
BBC doesn't want to [...] automatically determine which time zone any particular visitor to the site happens to be in
How do they handle this for their TV broadcasts?
"I'm not blaming Microsoft,' said Cerf,
Let's call a spade a spade. It's 100% a problem due to opaque binary formats. Had the document been written in (clean) HTML or plain text, it would have stayed usable without problems.
So who funds this special work group? I don't want my taxes to fund any such nonsense. Shut it down!
I'm sure he meant the guy who killed him the first time around.
Never do an important update on a Friday, ... or it might spoil your weekend!
Well, as long as you can be sure that it is indeed a cow...
A flimsy trigger and barrel
Don't worry, it will get sturdier as the design, and the printers will improve.
3D printing gunpowder and a shell?
A chemistry printer, maybe? You pour nitrogen components, oxygen components, carbon, etc. inside, and it "prints" the right molecules, a little bit like DNA synthesizer does.
Seriously - if you want a gun, there's both cheaper and more readily available sources. You can even manufacture your own without a printer.
So this clown of a police commissioner says his greatest fear is of criminals blowing themselves up with it. Are you serious?
No, but he thinks this is the most effective way to scare people away from downloading and printing it...
Like in the old days with the illegal money changers in East European countries. Police were not telling the tourists: "it's illegal to change money on the street, you might go to jail for it", but "most of these money changers are fraudsters, and will just rip you off".
Are you not just a little bit more worried of people with a grudge against police using it against them, or even innocent people?
Sure he is, but do you really think that telling people that will stop them from downloading it?
3d-printing of guns: the quickest way to create legislation regulating the sale of bullets.
Except that you can manufacture your own bullets too, and many people already do so as a hobby.
I hope you would have to actually shoot someone for it to be fatal.
Nope, it sucks so much that 1 times out of three it explodes in the shooters hand when fired. So it could well be fatal even when fired into a sand bag... fatal to the shooter himself, that is.
Of course, over time, the design will improve, and 3d printers will improve too, so eventually it will be just like any other gun: fatal only to the intended target, but still undetectable and difficult to regulate!
Oh, and you can buy that kind of information already, from his credit card company or bank (who make a very nice profit selling those details anyway) for considerably more cheaply and easily than poisoning the entire internet.
Scary. Fortunately, in my country we have banking secrecy laws. Ooops, had. Most people are concerned about the tax man, but these shenanigans are actually a much bigger threat when banking secrecy goes away.
I think it depends which info exactly is in that mail. Sure firstname and lastname are hardly confidential. But often these confirmations also contain credit card numbers, social security numbers (if the site asked for it), and other stuff you may not be confortable sharing with the world at large.
not some bounced tracker through a third-party mailer outfit
Good luck with that! If even the pirate party can't get this right, how will business ever get it?
is thus not going to be caught by a man in the middle attack.
... which is nicely defeated if the man-in-the-middle can just grab it on the way back. So yes, the complaint is relevant.
HTTPS means that you have a securely encrypted connection with the remote server. Not that the people who own the remote server are going to keep your privacy sacred.
But it does mean that nobody on the path can listen in on the connection. Which is defeated if then the same info is sent back over an unencrypted channel.
No smpt doesn't support encryption between servers.
Actually it does. But obviously both servers (sender and receiver) must be configurered to use it (which most aren't, unfortunately). And sender must be configured to check receiver's certificate (which even less are).
It's not a protocol issue, but a configuration issue.
And knowing this, it is indeed unwise to include such confidential info in an e-mail.