SOAP has actually gone well out of its way to allow server admins to filter requests. It makes use of the "Mandatory Header" aspects of the HTTP protocol such that every soap request must come with an HTTP header specifying which function is being called. Since it's in the header, a server doesn't need to know SOAP to filter, it justs needs to know HTTP, and the server can simply turn away anything that doesn't provide such a header.
I agree there is still a major lack of support for this type of filtering, and even the standard leaves something to be desired in this respect, but the SOAP designers definitely did think that this was a big enough problem to provide facilities for future closing of these holes.
It's a bit of a pain to administer, but it definitely *can* be done.
The trouble is that even a knowledge of history doesn't really provide these answers. There are as many Muslims who complain that America doesn't do enough to help other groups (particularly those of different ethnic backgrounds) as there are who argue America should stop interfering in their affairs. Our haphazard foreign policy, unable to find an acceptable balance between these two choices, certainly explains the mistrust often felt towards America and only serves to feed the extremists, but somehow implying that there *is* some kind of easy answer if we read our history books strikes me as a vast oversimplification.
All anyone needs to know is your random-number generator and your noise-selecting process, and then they just look through your images, extracting potentially keys, subtracting the derived pad from the noise in other images, and running that through a simple analyzer to figure out if it's meaningful.
Sending co-dependent data (a key and encoded data) is a common mistake in amateur steganography and the easiest way to compromise the system.
Further, steganography is no substitute for cryptography; if you don't want people reading your data you should use both! If you want to exchange data with someone else, use public-key cryptography and publicly post separate public keys using steganography, or hide the steps involved in a more traditional secure key exchange algorithm the same way.
Many of the "shortcomings" of C++ noted in this spec have already been overcome through the use of features which the author claims are too complicated to be useful. Templates and operator overloading make dynamically sized, first class array types fairly straightforward to implement, and the standard library even provides one. Many programmers have been using various forms of garbage collection for years using the same features. And the vague assertion that C++ is bad at string proessing is completely absurd; C++ not only provides basic string classes (which are easily user-extendable to allow for any locale or character set), but also offers all the features necessary to code your own string library which is as efficient as the hardware allows. There is no perfect string implementation- all have strengths and weaknesses and the ability to pick the right one for the job at hand is crucial. The whole criticism of C++ seems to have ignored that fact that while C++ *is* a fairly large language, the vast majority of the spec is talking about the standard library- a library which can be completely ignored or completely reimplemented by the user.
Certainly there are features that I think would make sense in C++, try-catch-finally and (if a convincing case were made for their usefulness) nonaliased typdef-style constructs, but throwing out the features that have been scrupulously analyzed, optimized, refined, and finally only included when they were deemed absolutely necessary is just absurd.
Multiple inheritance can cause huge maintainability problems, but used judiciously it makes it much easier to customize class interfaces and reduces code duplication. In many cases a design can increase a magnitude in complexity if multiple inheritance is not available.
Templates and stack-based objects are not strictly necessary in many cases in C++, but they provide the primary mechanisms to write high-level, well structured, and maintainable code that runs at near-optimal efficiency. With these features you can write extremely robust and flexibly interfaces that compile down to only a few instructions. Removing them would mean requiring writing any code which needs to run efficiently in the old monolithic C style which has proven so expensive to debug, maintain, and extend. And if you can come up with a type safe zero overhead way to write container classes with no code duplication at all, it's probably more complex than the (admittedly new and not-well-understood, but inherently straightforward) template system in C++.
Operator overloading is the only way to write user-defined types with interfaces similar to those of built-in types. To disallow this feature would be to put up a wall between what the language provides and what libraries can offer.
Overall, I just don't see anything which even comes close to outweighing the huge costs and problems that come with moving to a new language. C++ was a major step forward from C; D is at best a step sideways.
Slashdot Mirror
SOAP has actually gone well out of its way to allow server admins to filter requests. It makes use of the "Mandatory Header" aspects of the HTTP protocol such that every soap request must come with an HTTP header specifying which function is being called. Since it's in the header, a server doesn't need to know SOAP to filter, it justs needs to know HTTP, and the server can simply turn away anything that doesn't provide such a header.
I agree there is still a major lack of support for this type of filtering, and even the standard leaves something to be desired in this respect, but the SOAP designers definitely did think that this was a big enough problem to provide facilities for future closing of these holes.
It's a bit of a pain to administer, but it definitely *can* be done.
The trouble is that even a knowledge of history doesn't really provide these answers. There are as many Muslims who complain that America doesn't do enough to help other groups (particularly those of different ethnic backgrounds) as there are who argue America should stop interfering in their affairs. Our haphazard foreign policy, unable to find an acceptable balance between these two choices, certainly explains the mistrust often felt towards America and only serves to feed the extremists, but somehow implying that there *is* some kind of easy answer if we read our history books strikes me as a vast oversimplification.
You are certainly making things easy on people.
All anyone needs to know is your random-number generator and your noise-selecting process, and then they just look through your images, extracting potentially keys, subtracting the derived pad from the noise in other images, and running that through a simple analyzer to figure out if it's meaningful.
Sending co-dependent data (a key and encoded data) is a common mistake in amateur steganography and the easiest way to compromise the system.
Further, steganography is no substitute for cryptography; if you don't want people reading your data you should use both! If you want to exchange data with someone else, use public-key cryptography and publicly post separate public keys using steganography, or hide the steps involved in a more traditional secure key exchange algorithm the same way.
As usual, there are no easy answers.
Many of the "shortcomings" of C++ noted in this spec have already been overcome through the use of features which the author claims are too complicated to be useful. Templates and operator overloading make dynamically sized, first class array types fairly straightforward to implement, and the standard library even provides one. Many programmers have been using various forms of garbage collection for years using the same features. And the vague assertion that C++ is bad at string proessing is completely absurd; C++ not only provides basic string classes (which are easily user-extendable to allow for any locale or character set), but also offers all the features necessary to code your own string library which is as efficient as the hardware allows. There is no perfect string implementation- all have strengths and weaknesses and the ability to pick the right one for the job at hand is crucial. The whole criticism of C++ seems to have ignored that fact that while C++ *is* a fairly large language, the vast majority of the spec is talking about the standard library- a library which can be completely ignored or completely reimplemented by the user.
Certainly there are features that I think would make sense in C++, try-catch-finally and (if a convincing case were made for their usefulness) nonaliased typdef-style constructs, but throwing out the features that have been scrupulously analyzed, optimized, refined, and finally only included when they were deemed absolutely necessary is just absurd.
Multiple inheritance can cause huge maintainability problems, but used judiciously it makes it much easier to customize class interfaces and reduces code duplication. In many cases a design can increase a magnitude in complexity if multiple inheritance is not available.
Templates and stack-based objects are not strictly necessary in many cases in C++, but they provide the primary mechanisms to write high-level, well structured, and maintainable code that runs at near-optimal efficiency. With these features you can write extremely robust and flexibly interfaces that compile down to only a few instructions. Removing them would mean requiring writing any code which needs to run efficiently in the old monolithic C style which has proven so expensive to debug, maintain, and extend. And if you can come up with a type safe zero overhead way to write container classes with no code duplication at all, it's probably more complex than the (admittedly new and not-well-understood, but inherently straightforward) template system in C++.
Operator overloading is the only way to write user-defined types with interfaces similar to those of built-in types. To disallow this feature would be to put up a wall between what the language provides and what libraries can offer.
Overall, I just don't see anything which even comes close to outweighing the huge costs and problems that come with moving to a new language. C++ was a major step forward from C; D is at best a step sideways.