the fact remains that deserves to make money off of artistic design
This is an impression the media industry often gives. The fact of the matter is that they don't deserve to make money. They don't deserve to be rich. What they are allowed to do is try to make money of the fruits of their labour. The market will decide whether they actually can make money. Any attempt to guarantee them an income is an inequitable as refusing them the ability to try and turn a profit (for example by freely allowing copying of their goods without compensation).
The information bandwidth of a time-domain channel at a given bitrate is the same as the bandwidth of a frequency-domain channel at the same bitrate. IF you're saturating one channel, then doing a fourier or inverse fourier transform will have no effect.
In practice, many messages (such as English text, photographic images, recorded sound) have a convenient representation which is highly redundant. Their true information content is much lower than the theoretical maximum bandwidth of the channel used to transmit them, in that particular encoding.
The reason why converting to the frequency domain works so well for some applications, is that it is currently easier for us to separate the 'signal' from the 'padding' in the frequency domain, then lower the channel bitrate accordingly to just above the signal bandwidth. This can be done with many real-world signals, and is in theory lossless.
In practice far bigger savings in bandwidth can be sometimes made by lowering the channel bandwidth to below that of the signal. Often, features of the signal which make little subjective difference to a human observer, have disproportionately high information content. By accepting a small degrading of the signal, a huge saving in bandwidth can be made.
This does not apply in general though. Signals which naturally have very high entropy (as in already close to the maximum bandwidth of the transmission channel), or that have already been compressed by some other means, or that simply has a structure which doesn't change energy distribution in a suitable way when mapping between domains, will benefit less or not at all from such mapping.
so adding the ? TRUE : FALSE will eliminate the warning.
If you're using COM interfaces it gets worse than that. The VARIANT_BOOL data type is defined as a 16-bit word taking the values False (0) and True (-1). As long as you test these against false there's not usually a problem, but if you test equal to true rather than is true, or if you negate the variable then weird things can happen. VB's Not operator blindly does a bitwise rather than logical negation even on Booleans, so if you take a Boolean variable (badly) returned from a COM object written in C++ it's entirely possible for both the following statements to get executed:
If var Then DoThis If Not var Then DoThat
Solution: always return COM booleans from C++ using the idiom (var ? VARIANT_TRUE : VARIANT_FALSE)
Leaving the system online and intact is the best way to root cause a bug.
Actually, there is a very large class of bug for which that is not true - and a large subset of that is where the bug is somewhat repeatable. Sometimes the effort of grovelling around in crash debris is just not worth the effort. There have been many times when restarting, installing extra logging, then watching the crash happen has provided far more information in 5 minutes than grovelling for hours could have.
(And as a suggestion, change the ID to the computer's MAC address. These things change a lot less frequently
Having read some of they other points that were made in response to this, they are good points. What I don't think has been mentioned is a potentially crippling aspect of hardware signature based licensing.
Imagine that you're a company running some mission critical process (it could be a particular piece of server software, or it could just be a developer's machine and you have a release/bugfix deadline tomorrow which *must* be met) on a particular machine. Of course the OS and possibly other software is keyed to the hardware configuration. Half-way through the night/weekend your ethernet card lets out its magic smoke.
Without hardware keying, hardly any company is going to be seriously affected by this. Any company worth its salt will have a few extra cards and other spares lying around. It probably wouldn't take more than a couple of hours to fix, and if you're on the ball you could be running again in under 20 minutes.
With this licensing scheme though, you replace the faulty hardware only to find out the OS/software won't run, and being out of hours you can't get a replacement for possibly a couple of days. The software vendor has just single handedly made your own internal support's 24/7 provisions completely useless.
Well, if we discover alien life then there's no need to research cures for cancer - the aliens will already have that technology and give it us for free;-)
Sure, the code would be vetted thoroughly before it could ever make it into the kernel, but....
But what? In this instance their motivation is almost certainly to allow a widely available OS to be certified to a sufficient security level that it can actually be used in the same situations where certain US agencies might normally buy in NT, AIX or such.
If they *really* wanted to plant a back door, in no way would they want their name so obviously traceable to the actual patches they submitted - they'd do it 'anonymously' and you'd never know. How do you know they haven't already done this? Or that GCHQ, or Mossad, or the Russians haven't? You have no way of knowing, but we just have to trust that any attempts at sabotage would be obvious in the source.
The real question is, why is this story posted under Microsoft at all? Clearly Verisign made the mistake.
When MS's code-signing architecture was introduced, many respected members of the security research community criticised the fact that you simply cannot determine trust for everything a random piece of code will do up front.
MS's argument was always that people would restrict their trust to vendors with a reputation to uphold, and that VS would make sure that the name you see really is the name of the vendor.
This falls down in so many ways - rogue employees gaining unauthorised access to signing keys, spoofing the signing process (as in this case), interactions between trusted code modules that genuinely hadn't been forseen by their respective authors.
Now we have direct proof that a VS certificate claiming MS authorship does not necessarily prove so many of the things MS claimed it proved a few years ago, and which the security of their platform depends critically upon.
MS may not be directly to blame in this instance, but they are only being pushed backwards into the grave they themselves dug when they insisted on a single, relatively meaningless, security barrier protecting the whole machine.
Guys, Microsoft is not nearly as evil as you think it is.
And don't presume to know how evil 'we' think MS is. Personally I think they're just responding to the economic realities they find themselves in. I also think those economic realities should be modified to make some of their more unsavory responses less tempting. But that's just my own personal opinion.
They state that, under the DMCA, it would be illegal for the RIAA to reverse engineer their encoding scheme
Then they completely fail to understand the DMCA. The reason why it's illegal to defeat their encoding schemes is, not as stated in another comment down to the triviality or otherwise of the method, but because the RIAA are stinking rich. Conversely they can do whatever they like to us because we're not.
I considered something like this a while back - basically take a graphics tablet and pen-type stylus and hand-write away at it. Then produce a statistic model for acceleration as you write each letterform. Then you turn *that* into a T1 font that not only superficially resembles your own handwriting style, but also contains "random variation" giving it a more natural feel too.
You not only have to vary the form each time a glyph is invoked, but also keep track of context between glyphs. The amount of source input necessary is probably considerable to get a good model, and the preprocessing non-trivial. But I always thought it would be a really cool thing to do even if I can't immediately see any useful applications.
The main problem I saw was that most devices attempt to cache font renderings so you can't actually get different shapes on subsequent invocations of the same glyph. If you can afford the speed hit of disabling your font cache (and your engine supports this - the font engine is usually subject to weird and proprietary optimisations and not easily fiddled with - the idea could fly though.
For that purpose, I agree with a previous poster about packing 2 nucleotides per byte. It's an optimization that must be accepted as a standard before we can start doing on-demand heavy processing of genetic results.
There being four possible nucleotides (unless you're looking at something real exotic) surely you can get 4 per byte? Sticking to a base64 ascii encoding you can still get 3 nucleotides, so a single codon, per character, which is possibly a more elegant optimization.
Anyway, this shouldn't be necessary and goes against the XML philosophy. Although humans on the whole aren't meant to read XML directly, computers should be doing that, it should always remain *possibly* to do so, and I think this would muddy the human-eye view somewhat. It is accepted (by the people setting the standards) that this results in a larger raw stream, but that the correct way of dealing with that is to layer XML over storage-level and transport-level compression schemes to recover some of the entropy wastage. See REC-xml, section 1.1, and points 3 and 5 of XML in 10 points.
Heavy processing won't be done directly on markup - it'll be done on the in-memory representation after the markup is loaded, which can be assumed to be more compact than the markup if required (or less compact if there is a neat time/space tradeoff in the processing.)
Why, here 5 employees are suing for $5 Billion - Isn't this completely over the top? $50,000 each would be more like it.
Firstly, it's supposed to be punitive as well as compensative. The problem with big companies is it gets *very* hard to make them notice a slap on the wrist. Secondly, the article says it's class action with hundreds of plaintiffs, or at least potential plaintiffs, at which point they're only getting $millions each. That sort of level of payout seems to happen quite regularly in similar discrimination/unfair dismissal cases over that side o't pond.
Re:Hope no one here will be next NASA admin
on
Going Up?
·
· Score: 2
How you can forget that Gravity decays at the square of the distance? Do you know what is angular momentum? And how can you dare to think about something pushing this elevator up in vacuum, by itself. Hey, as anyone forget Newton's Third Law? Sorry to be so flamously bitter, but do they still teach it on school?
The third one? That'd be the one that proves reaction rockets are impossible, right?
"As a method of sending a missile to the higher, and even to the highest parts of the earth's atmospheric envelope, Professor Goddard's rocket is a practicable and therefore promising device. It is when one considers the multiple-charge rocket as a traveler to the moon that one begins to doubt... for after the rocket quits our air and really starts on its journey, its flight would be neither accelerated nor maintained by the explosion of the charges it then might have left.
"Professor Goddard, with his "chair" in Clark College and countenancing of the Smithsonian Institution, does not know the relation of action to reaction, and of the need to have something better than a vacuum against which to react... Of course he only seems to lack the knowledge ladled out daily in high schools."
-- New York Times Editorial, 1921
Re:What if you get stuck
on
Going Up?
·
· Score: 1
CA's issue certificates based on one criteria: money.
You give them money, they give you a certificate that says whatever you want it to say... If you want your certificate to say that you're "First Secure Bank Inc.", that's what your certificate will say...
While that is true and does have implications, the mapping you're interested in is not key<->person, but key<->DNS domain. The person<->DNS domain mapping you get from reading national press, TV etc. And CAs generally will try and check details out before issuing certs - the commodity they're selling is trust, and successful attacks against their issuing procedure would send their stock price plummetting.
Just because a cert is signed by a CA does not make it secure
Absolutely, and this applies to *any* system. You must always consider the total system, not individual protocols, if security is important. Personally I'd be more worried about hackers stealing the server's private key (the CA cert proves with a high degree of confidence that it's the legitimate owner's key - it *doesn't* prove that they're the only person with access to it) or viruses/trojans modifying the users CA root key list than CAs issuing bogus certs.
That's an interesting problem, but I think it applies to closed-source systems too, and possibly worse. At least in the open source world you get a better audit trail of exactly what changes have been made, when and by who. (Well, the authenticity of this is sometimes questionable, but wide and open distribution mediates against subversion to a certain extent.) Diffs are generally available and easier to check for possible compromises than whole systems. There's also an argument that because home-tinkering presents a faster moving target to attackers, their incentive (and our risk) is reduced. Don't rely on it, but it could be true:-)
Many groups already do use signed distribution - it's Debian policy for example for all developers or maintainers to sign anything they put out.
And many groups also maintain at least one previous stable release, with a policy to restrict updates to bug fixes only (or have very good reasons for completely new code). Some even restrict bug fixes to only the most severe bugs, or security-only fixes.
People assumed that because pirahna was open sourced, someone would have noticed the obvious password flaw within hours or just a few days after it was released. But NO, it took longer than that.
Of course it did, that's the point. Security isn't something you achieve overnight, the status of any particular system is very much the result of consensus building which takes time. It's down to how many eyeballs have looked at the system, how deep they've looked at it, and how long they've looked at it.
Opening up the source results, eventually, in a more secure system because those people who do so can look deeper, and also because the skills to analyse source code are more widespread than the skills required to analyse a running binary, so hopefully more people will do so. But anyone who takes a newly released system and immediately relies on it for security has to be insane.
Do not rely only on peer review. If you want to be sure about what you are using, especially in environments needing ultimate security, do your own damn auditing and testing or pay someone to do it.
And while doing your own audit is good advice, the most valuable result will be a new data point to add to the global consensus. Relying on your own analysis isn't much better than relying on no analysis at all, but if 100 people have looked at the system over 5 years or so and not found it wanting, then we start to feel some level of confidence in it.
Of course this is if you want to do security properly, but for most people, for most applications, this level of care is just not necessary.
Not really - the article clearly says this has been going on since the start of last year (the military buying Iridium out will hopefully allow this to continue a bit longer.)
But 50 billion Watts? Imagine if we could directly harness some of that energy!
i am pretty sure he means like 1 meter square from a top view of a human.
The original mentioned distinguishing bodies in graves (presumeably still open graves that is). I believe it's quite rare to bury people standing upright, so.5m by 2m is probably about right on average.
My impression was that it's about what is going to be the central repository / standards body for XML schemas.
Ah, schema repositories. I'm not convinced I see a great deal of difference between this aspect of the XML initiative, and the STEP initiative (which hasn't finalised on a truly useful and useable solution in 30 years). And I have a great deal of difficulty not believing both to be seriously misguided. At some point it all appears to break down and you end up with everyone with their own private schema which isn't appropriate for anyone else, so you either only talk to your friends, or you're expected to understand the semantics of far too many other schemas. Which is exactly what both camps claim to be trying to avoid.
AFAIAC they can fight over who gets to keep the central database as much as they like - it's just not going to be relevant to the vast majority. The useful bits are XML itself (giving generalised tree manipulation and data interchange, as long as you already agree on the semantics) and XML Schemas which used sensibly is a fairly neutral way of describing type information. Forget the rest of BizTalk.
Slashdot Mirror
Real Men don't speak Quiche!
This is an impression the media industry often gives. The fact of the matter is that they don't deserve to make money. They don't deserve to be rich. What they are allowed to do is try to make money of the fruits of their labour. The market will decide whether they actually can make money. Any attempt to guarantee them an income is an inequitable as refusing them the ability to try and turn a profit (for example by freely allowing copying of their goods without compensation).
For which message, exactly?
The information bandwidth of a time-domain channel at a given bitrate is the same as the bandwidth of a frequency-domain channel at the same bitrate. IF you're saturating one channel, then doing a fourier or inverse fourier transform will have no effect.
In practice, many messages (such as English text, photographic images, recorded sound) have a convenient representation which is highly redundant. Their true information content is much lower than the theoretical maximum bandwidth of the channel used to transmit them, in that particular encoding.
The reason why converting to the frequency domain works so well for some applications, is that it is currently easier for us to separate the 'signal' from the 'padding' in the frequency domain, then lower the channel bitrate accordingly to just above the signal bandwidth. This can be done with many real-world signals, and is in theory lossless.
In practice far bigger savings in bandwidth can be sometimes made by lowering the channel bandwidth to below that of the signal. Often, features of the signal which make little subjective difference to a human observer, have disproportionately high information content. By accepting a small degrading of the signal, a huge saving in bandwidth can be made.
This does not apply in general though. Signals which naturally have very high entropy (as in already close to the maximum bandwidth of the transmission channel), or that have already been compressed by some other means, or that simply has a structure which doesn't change energy distribution in a suitable way when mapping between domains, will benefit less or not at all from such mapping.
Because if the cat then turns out to be dead, it's YOUR fault for collapsing the wavefunction.
If you're using COM interfaces it gets worse than that. The VARIANT_BOOL data type is defined as a 16-bit word taking the values False (0) and True (-1). As long as you test these against false there's not usually a problem, but if you test equal to true rather than is true, or if you negate the variable then weird things can happen. VB's Not operator blindly does a bitwise rather than logical negation even on Booleans, so if you take a Boolean variable (badly) returned from a COM object written in C++ it's entirely possible for both the following statements to get executed:
If var Then DoThis
If Not var Then DoThat
Solution: always return COM booleans from C++ using the idiom (var ? VARIANT_TRUE : VARIANT_FALSE)
Actually, there is a very large class of bug for which that is not true - and a large subset of that is where the bug is somewhat repeatable. Sometimes the effort of grovelling around in crash debris is just not worth the effort. There have been many times when restarting, installing extra logging, then watching the crash happen has provided far more information in 5 minutes than grovelling for hours could have.
Having read some of they other points that were made in response to this, they are good points. What I don't think has been mentioned is a potentially crippling aspect of hardware signature based licensing.
Imagine that you're a company running some mission critical process (it could be a particular piece of server software, or it could just be a developer's machine and you have a release/bugfix deadline tomorrow which *must* be met) on a particular machine. Of course the OS and possibly other software is keyed to the hardware configuration. Half-way through the night/weekend your ethernet card lets out its magic smoke.
Without hardware keying, hardly any company is going to be seriously affected by this. Any company worth its salt will have a few extra cards and other spares lying around. It probably wouldn't take more than a couple of hours to fix, and if you're on the ball you could be running again in under 20 minutes.
With this licensing scheme though, you replace the faulty hardware only to find out the OS/software won't run, and being out of hours you can't get a replacement for possibly a couple of days. The software vendor has just single handedly made your own internal support's 24/7 provisions completely useless.
Well, if we discover alien life then there's no need to research cures for cancer - the aliens will already have that technology and give it us for free ;-)
But what? In this instance their motivation is almost certainly to allow a widely available OS to be certified to a sufficient security level that it can actually be used in the same situations where certain US agencies might normally buy in NT, AIX or such.
If they *really* wanted to plant a back door, in no way would they want their name so obviously traceable to the actual patches they submitted - they'd do it 'anonymously' and you'd never know. How do you know they haven't already done this? Or that GCHQ, or Mossad, or the Russians haven't? You have no way of knowing, but we just have to trust that any attempts at sabotage would be obvious in the source.
When MS's code-signing architecture was introduced, many respected members of the security research community criticised the fact that you simply cannot determine trust for everything a random piece of code will do up front.
MS's argument was always that people would restrict their trust to vendors with a reputation to uphold, and that VS would make sure that the name you see really is the name of the vendor.
This falls down in so many ways - rogue employees gaining unauthorised access to signing keys, spoofing the signing process (as in this case), interactions between trusted code modules that genuinely hadn't been forseen by their respective authors.
Now we have direct proof that a VS certificate claiming MS authorship does not necessarily prove so many of the things MS claimed it proved a few years ago, and which the security of their platform depends critically upon.
MS may not be directly to blame in this instance, but they are only being pushed backwards into the grave they themselves dug when they insisted on a single, relatively meaningless, security barrier protecting the whole machine.
And don't presume to know how evil 'we' think MS is. Personally I think they're just responding to the economic realities they find themselves in. I also think those economic realities should be modified to make some of their more unsavory responses less tempting. But that's just my own personal opinion.
Then they completely fail to understand the DMCA. The reason why it's illegal to defeat their encoding schemes is, not as stated in another comment down to the triviality or otherwise of the method, but because the RIAA are stinking rich. Conversely they can do whatever they like to us because we're not.
I considered something like this a while back - basically take a graphics tablet and pen-type stylus and hand-write away at it. Then produce a statistic model for acceleration as you write each letterform. Then you turn *that* into a T1 font that not only superficially resembles your own handwriting style, but also contains "random variation" giving it a more natural feel too.
You not only have to vary the form each time a glyph is invoked, but also keep track of context between glyphs. The amount of source input necessary is probably considerable to get a good model, and the preprocessing non-trivial. But I always thought it would be a really cool thing to do even if I can't immediately see any useful applications.
The main problem I saw was that most devices attempt to cache font renderings so you can't actually get different shapes on subsequent invocations of the same glyph. If you can afford the speed hit of disabling your font cache (and your engine supports this - the font engine is usually subject to weird and proprietary optimisations and not easily fiddled with - the idea could fly though.
The EFF were already handling it, and there's only so many acronyms you can fit in a courthouse...
There being four possible nucleotides (unless you're looking at something real exotic) surely you can get 4 per byte? Sticking to a base64 ascii encoding you can still get 3 nucleotides, so a single codon, per character, which is possibly a more elegant optimization.
Anyway, this shouldn't be necessary and goes against the XML philosophy. Although humans on the whole aren't meant to read XML directly, computers should be doing that, it should always remain *possibly* to do so, and I think this would muddy the human-eye view somewhat. It is accepted (by the people setting the standards) that this results in a larger raw stream, but that the correct way of dealing with that is to layer XML over storage-level and transport-level compression schemes to recover some of the entropy wastage. See REC-xml, section 1.1, and points 3 and 5 of XML in 10 points.
Heavy processing won't be done directly on markup - it'll be done on the in-memory representation after the markup is loaded, which can be assumed to be more compact than the markup if required (or less compact if there is a neat time/space tradeoff in the processing.)
I trust it's still possible to compile with no display drivers at all and use a pure serial-line console still?
Firstly, it's supposed to be punitive as well as compensative. The problem with big companies is it gets *very* hard to make them notice a slap on the wrist. Secondly, the article says it's class action with hundreds of plaintiffs, or at least potential plaintiffs, at which point they're only getting $millions each. That sort of level of payout seems to happen quite regularly in similar discrimination/unfair dismissal cases over that side o't pond.
The third one? That'd be the one that proves reaction rockets are impossible, right?
"As a method of sending a missile to the higher, and even to the highest parts of the earth's atmospheric envelope, Professor Goddard's rocket is a practicable and therefore promising device. It is when one considers the multiple-charge rocket as a traveler to the moon that one begins to doubt ... for after the rocket quits our air and really starts on its journey, its flight would be neither accelerated nor maintained by the explosion of the charges it then might have left.
"Professor Goddard, with his "chair" in Clark College and countenancing of the Smithsonian Institution, does not know the relation of action to reaction, and of the need to have something better than a vacuum against which to react ... Of course he only seems to lack the knowledge ladled out daily in high schools."
Contrary to popular rumour, that's not him in the current User Friendly storyline.
While that is true and does have implications, the mapping you're interested in is not key<->person, but key<->DNS domain. The person<->DNS domain mapping you get from reading national press, TV etc. And CAs generally will try and check details out before issuing certs - the commodity they're selling is trust, and successful attacks against their issuing procedure would send their stock price plummetting.
Absolutely, and this applies to *any* system. You must always consider the total system, not individual protocols, if security is important. Personally I'd be more worried about hackers stealing the server's private key (the CA cert proves with a high degree of confidence that it's the legitimate owner's key - it *doesn't* prove that they're the only person with access to it) or viruses/trojans modifying the users CA root key list than CAs issuing bogus certs.
That's an interesting problem, but I think it applies to closed-source systems too, and possibly worse. At least in the open source world you get a better audit trail of exactly what changes have been made, when and by who. (Well, the authenticity of this is sometimes questionable, but wide and open distribution mediates against subversion to a certain extent.) Diffs are generally available and easier to check for possible compromises than whole systems. There's also an argument that because home-tinkering presents a faster moving target to attackers, their incentive (and our risk) is reduced. Don't rely on it, but it could be true :-)
Many groups already do use signed distribution - it's Debian policy for example for all developers or maintainers to sign anything they put out.
And many groups also maintain at least one previous stable release, with a policy to restrict updates to bug fixes only (or have very good reasons for completely new code). Some even restrict bug fixes to only the most severe bugs, or security-only fixes.
Of course it did, that's the point. Security isn't something you achieve overnight, the status of any particular system is very much the result of consensus building which takes time. It's down to how many eyeballs have looked at the system, how deep they've looked at it, and how long they've looked at it.
Opening up the source results, eventually, in a more secure system because those people who do so can look deeper, and also because the skills to analyse source code are more widespread than the skills required to analyse a running binary, so hopefully more people will do so. But anyone who takes a newly released system and immediately relies on it for security has to be insane.
And while doing your own audit is good advice, the most valuable result will be a new data point to add to the global consensus. Relying on your own analysis isn't much better than relying on no analysis at all, but if 100 people have looked at the system over 5 years or so and not found it wanting, then we start to feel some level of confidence in it.
Of course this is if you want to do security properly, but for most people, for most applications, this level of care is just not necessary.
It is the British billion which is 10^12. The US billion is only 10^9, also known (rarely) as a milliard in the British system.
Not really - the article clearly says this has been going on since the start of last year (the military buying Iridium out will hopefully allow this to continue a bit longer.)
But 50 billion Watts? Imagine if we could directly harness some of that energy!
The original mentioned distinguishing bodies in graves (presumeably still open graves that is). I believe it's quite rare to bury people standing upright, so .5m by 2m is probably about right on average.
Ah, schema repositories. I'm not convinced I see a great deal of difference between this aspect of the XML initiative, and the STEP initiative (which hasn't finalised on a truly useful and useable solution in 30 years). And I have a great deal of difficulty not believing both to be seriously misguided. At some point it all appears to break down and you end up with everyone with their own private schema which isn't appropriate for anyone else, so you either only talk to your friends, or you're expected to understand the semantics of far too many other schemas. Which is exactly what both camps claim to be trying to avoid.
AFAIAC they can fight over who gets to keep the central database as much as they like - it's just not going to be relevant to the vast majority. The useful bits are XML itself (giving generalised tree manipulation and data interchange, as long as you already agree on the semantics) and XML Schemas which used sensibly is a fairly neutral way of describing type information. Forget the rest of BizTalk.