I should clarify the example at the end: I am absolutely not saying that cookies should cross domain borders; the set of cookies for the 'parent site' and the 'child site' would remain orthogonal - but not *DISABLED*.
Alright, fine. Some types of cookies can be easily exploited, but there is one type of cookie that you DON'T want to turn off (and don't want people in general to turn off), and that is the session cookie.
All this 'anti cookie' propaganda is really getting out of hand. Session cookies are a great way to securely identify a series of otherwise unrelated requests as belonging to the same session. By turning off cookies one is also disabling this very valuable feature.
"But it doesn't matter" you say, because web sites can use URL rewriting instead. Well, think about it:
* If URL rewriting is used, exactly how is this better, from a privacy stand-point, than a session cookie? The exact same information is propagated, so nothing is gained in terms of privacy. In addition, the "evil" people whom everybody is presumably trying to prevent from tracking a user's session can also use this technique.
* On the issue of security and technical convenience however, you are making it worse. URL rewriting is inherently less secure in the fact of 'accidents' such as paste:ing a link (which the average joe won't understand contains sensitive information) to a work collegue sitting behind the same NAT:ing gateway. And how about referrer URL:s making it into web server logs? (There is no guarantee that the session identifier is encoded such that a security conscious browser can spot it, and refrain from sending it as part of a referrer URL to another web server.)
Overall, session cookies are vastly superior to URL rewriting in a number of different situations. But this overzealous anti-cookie paranoia is forcing people to use URL rewriting *anyway*. In tryng to increase privacy, it has actually been lessend - along with security!
Just to give one example of how the ACP (anti cookie paranoia) can interact with web pages: I was recently involved in a situation where some browsers would disable cookies (even session cookies) for requests that were made as part of an IFRAME on a page hosted on another domain (presumably for privacy concerns). This resulted in, for practical purposes, a total inability to use cookies on that site. URL rewriting is now used instead, to a detriment of security and privacy.
While I share everyone's initial reaction, it's not completely far-fetched.
Consider the amount of progress made from JDK 1.0 to JDK 1.4. The changes would reflect a 1.0->4.0 versioning scheme much better than 1.0-1.4. And instead of having 1.4.2_01 they would have 4.2.1, which would more accurately reflect the singificance of each update.
So. If you look at it as Sun simply dropping the initial 1 to 'adjust' the versioning scale, it actuall makes quite a bit of sence, since we've gone from 1.0 to 2.0, 3.0, 4.0 and now 5.0. And the changes made between those versions definitely warrant a new major version number in my opinion.
So while this weird versioning is annoying (I *still* cringe at the thought of "Java 2 1.4"), if they will now stick to the new versioning scheme it should reflect reality better than before.
I would be willing to bet a considerable amount of money that you have never used Smalltalk - based on the above statement.
Smalltalk is lightyears ahead of "gdb --pid=[running process]". With Smalltalk you can develop and bugfix your application *while it is running* and experience the results immediately.
For example, I did considerable work on an IRC bot developed in VisualWorks, while the bot was connected to the IRC server. There was almost never any need to restart anything. Changes I made were immediately available. The only reason to re-connect was if something was changed that affected the connetion/login procedure - for obvious reasons.
In a real crunch you can debug and alter a production system with zero downtime and no restarts. There is no stop/edit/compile/run cycle. If I recall correctly someone posted on comp.lang.smalltalk a while back describing such a situation...
Everyone interested in this might want to have a look at AOS, one of the two platforms (CLR/.NET being the other) targeted by SmallScript/S# at www.smallscript.net.
I am not that well informed, but as I understand it AOS is essentially a more generic and language neutral alternative to CLR.
I've been saying a long time that C and other unsafe languages simply are not suitable for most applications. There must be a very good reason for such languages to be the primary (good) choice.
And truthfully, I don't feel safe knowing that most of the code running on my machine and servers out there is written in unsafe languages.
Like the article author mentioned, who knows how many bugs are out there being actively exploited because they are not yet widely known?
Of particular importance is the fact that bugs such as buffer overflows don't exist *AT ALL* in other languages. Yes, there are many ways to introduce security vulnerabiliies in applications, regardless of language. But with unsafe langauges that allow bufer overflows, even the simplest application may have disastrous bugs.
For example, a network monitoring system that does nothing but monitor traffic can easily contain a remote root exploit if written in an un-safe language. If written in a safe language, it is virtually unthinkable that such a bug exists, because the application simply does not perform actions that are even related to privileges / unsafe file access, and, as opposed to the unsafe language equivalent, there are no arbitrary-code-execution bugs. (Assuming of course one doesn't doo things like invoking shell scripts, in which case unchecked parameters can cause grief.)
If everyone started writing code in safe languages except where an unsafe language was *really* called for, there would almost certainly be a LOT less exploitable bugs, and in particular, a lot less random. Yes, a buggy ssh server written in a safe language is a hazard. But a buggy time server isn't, nor is a network monitoring application, and nor are a number of other types of applications.
In short, without arbitrary-code-execution bugs, it is much easier to determine what type of damage is likely to be caused by a certain application. And the probability that a bug steps outside of its scope of expected bugs is much smaller.
So please, enough with the low-level conservatism please.
I am currently involved in a project where we are trying to launch a WaveLAN based internet service to custerom's in a small area (200-300 houses). No DSL alterantives are available from any major supplier, and the cost of a pair of copper wires alone makes using DSL to expensive for the customer.
Initially, at least 50 people reported interest. We later learned there were many people interested who had not responded to the initial call for interest. It looks like there are 50-100 houses in the area seriously interested in an internet connection of this kind.
We recently started taking orders; so far we have slightly about 10. Probably because most people are waiting for other people's experience, etc. We're not sure. We have a few cards to play in order to spice up interest, but not much.
I mean, this is not just some minor licensing issues or whatever. People are actually trying to put other people in jail for writing software that enables people wo watch DVD:s they have payed for. That's exactly what's happening - why can't the people adovacting this crap see that?
*sigh*
Better than MPEG-4? Why do you say that?
on
High Definition DVD
·
· Score: 1
Have you tried comparing it? I haven't, but I certainly haven't seen anything from MS that does as good a job as FFMPEG's MPEG-4 implementation (ffmpeg.sourceforge.net) or DivX;-).
And what is the status of H26.L (I think it's called). It's supposed to be the next-generation post-mpeg-4 codec, but I have not found much information on it.
(I'm not a developer, just an observer of the project.)
Subversion is nearing a first final release. The alpha version is just around the corner, and development is very active.
Subversion is basically CVS done right. Natively client/server, atomic commits, proper handling of binary files, proper versioning of everything - including directories and file metadata, and much more. Go read about it at http://subversion.tigris.org
Put spaces? Ok, if you want to burn lots of paper. It's difficult to do when you are given two pieces of paper filled with questions and a specific amount of vertical space to answer each one.
As for whining, I *should* whine if I believe there is a flaw in the system. Just accepting fact and living with it instead of *thinking* is the reason Hitler got away with it...
>If you, as the poster mentioned, feel the need to erase "large blocks" of code, you probably didn't think the program out well enough ahead of time.
See my other response on this subject. It's not about inability to think the program out well enough ahead of time; it's about having to do so to a different extent - and in a different way - than normal. When writing code on paper, certain things suddently become relevant that are irrelevant when using a text editor. One such thing is the number of lines of code a code block will end up taking.
(Of course, if you end up with code blocks a hundred lines long it's probably badly desgined in some languages etc, but that's another issue.)
Of course they have - a pretty good idea. You don't write the entire program line-by-line mentally first (at least, I've never heard of anyone doing that).
Part of programming is creating abstractions and factoring code. You don't keep the source code and state of the entire program in your head at one time. You deal with the relevant parts. For example, suppose I were to write a method that answers the absolute age difference between two people.
This implementation is completely independent of the implementation of Person>>ageDifference. After writing that method, I would implement #ageDifference - unless it already existed:
ageDifference: aPerson
^self age - aPerson age.
This is my normal way of doing things. If I had to do this on paper, I would have to think through dependency methods first in order to calculate what will fit where.
But to get back to the issue of braces. Suppose I needed to write code that answers the most wealthy relative of a person. First, I'd probably write:
mostWealhtyRealtive
"Answers the most wealthy relative of the receiver, or nil if the receiver has no relatives."
self hasRelatives ifTrue: [
] else: [
^nil.
].
After having written this, I would fill in the code block. The implementation may be extremely simple, or mit may be relatively complex, depending on the methods already available to me and to which extent I want to factor the implementation for usability (i.e. divide into more methods).
It may sound simple; but when doing this on paper, the whole process of writing code just becomes different. Suddently you need to concentrate on pety details of syntax instead of the problem. It wastes time, and is annoying.
I have no resect for any exam that involves writing actual code on paper. Asking about fundamental principles is fine; asking for pieces of code or specific API details is IMO rediculous.
Granted, you can never design a perfect test. But you can at least do away with the totally obvious imperfections like asking people to do things in ways they never do and never will do in the future (except on other tests).
The few times I was subjected to these tests, I sure felt primitive erasing entire chunks of code after having realized I needed to insert something in the beginning. And it's a hard thing to avoid; I don't think any reasonably experienced programmer writes code entirely from top to bottom. Just a simple thing as placing braces becomes a hurdle in writing unless you know the length of the code you need to put between them!
This is a big problem on Windows due to the way the system is designed and due to the way applications work. I have been involved in this sort of thing for a while now; and while we've managed to mostly get things done correctly, it's not perfect.
Firstly, Windows does not really have the concept of a home directly. Certainly, there is the user's profile which gets synched to the server (assuming a domain account). But the problem is that the concept of a user *ONLY* having access to his or her own file - PERIOD - is non-existent.
Firstly, MANY applications require administrator provileges to even run correctly, EVEN THOUGH they don't *actually* need it to perform their task. This is absolutely brain-dead on the part of the software vendor; it's as if 'mutt' were to need write access to anything but ~ in order to work.
In the windows world, the need it becaues they want to store user data in the program folder on C, or under HKEY_LOCAL_MACHINE in the registry, or various other stupid reasons. This has the result that we are often FORCED to give users administror privileges just so they can run their broken applications! Even *THE* most popular bookkeeping program here in Sweden has problems of this kind. I cannot believe they get away with it.
The above negates the effect of fiddling with file permissions such that the user cannot write to C: except to c:\temp. So that's out. And even if it weren't, there are plenty of applications that insist on fiddling with certain files outside of the user's profile, even if they do not store any critical user data outside it.
On Unix it's simple. Backup ~ and you have *EVERYTHING*, period.
In my opinion, going digital is a good thing for quality reasons.
Analog technology yields random picture noise, both in theaters and on DVDs mastered from an analog source. Just compare a DVD mastered from a movie shot with a digital camera (such as Livvakterna and SW2; and I'm sure a host of others) to those mastered from analog sources. The difference is huge.
Another sideeffect of "noiseless" video is that it compressed much better. Just think of how much you could fit on a HD-DVD in the future if movies were all-digital and they used MPEG-4 on the DVD (although I'm sure they'll stick to MPEG-2 - nevermind being futureproof).
And in theaters - am I really the only one who is annoyed at the artifacts that are continually visible due to particals on te film?
GREAT review! :)
on
Review: U-571
·
· Score: 2, Insightful
Slashdot Mirror
I should clarify the example at the end: I am absolutely not saying that cookies should cross domain borders; the set of cookies for the 'parent site' and the 'child site' would remain orthogonal - but not *DISABLED*.
Alright, fine. Some types of cookies can be easily exploited, but there is one type of cookie that you DON'T want to turn off (and don't want people in general to turn off), and that is the session cookie.
All this 'anti cookie' propaganda is really getting out of hand. Session cookies are a great way to securely identify a series of otherwise unrelated requests as belonging to the same session. By turning off cookies one is also disabling this very valuable feature.
"But it doesn't matter" you say, because web sites can use URL rewriting instead. Well, think about it:
* If URL rewriting is used, exactly how is this better, from a privacy stand-point, than a session cookie? The exact same information is propagated, so nothing is gained in terms of privacy. In addition, the "evil" people whom everybody is presumably trying to prevent from tracking a user's session can also use this technique.
* On the issue of security and technical convenience however, you are making it worse. URL rewriting is inherently less secure in the fact of 'accidents' such as paste:ing a link (which the average joe won't understand contains sensitive information) to a work collegue sitting behind the same NAT:ing gateway. And how about referrer URL:s making it into web server logs? (There is no guarantee that the session identifier is encoded such that a security conscious browser can spot it, and refrain from sending it as part of a referrer URL to another web server.)
Overall, session cookies are vastly superior to URL rewriting in a number of different situations. But this overzealous anti-cookie paranoia is forcing people to use URL rewriting *anyway*. In tryng to increase privacy, it has actually been lessend - along with security!
Just to give one example of how the ACP (anti cookie paranoia) can interact with web pages: I was recently involved in a situation where some browsers would disable cookies (even session cookies) for requests that were made as part of an IFRAME on a page hosted on another domain (presumably for privacy concerns). This resulted in, for practical purposes, a total inability to use cookies on that site. URL rewriting is now used instead, to a detriment of security and privacy.
While I share everyone's initial reaction, it's not completely far-fetched.
Consider the amount of progress made from JDK 1.0 to JDK 1.4. The changes would reflect a 1.0->4.0 versioning scheme much better than 1.0-1.4. And instead of having 1.4.2_01 they would have 4.2.1, which would more accurately reflect the singificance of each update.
So. If you look at it as Sun simply dropping the initial 1 to 'adjust' the versioning scale, it actuall makes quite a bit of sence, since we've gone from 1.0 to 2.0, 3.0, 4.0 and now 5.0. And the changes made between those versions definitely warrant a new major version number in my opinion.
So while this weird versioning is annoying (I *still* cringe at the thought of "Java 2 1.4"), if they will now stick to the new versioning scheme it should reflect reality better than before.
I would be willing to bet a considerable amount of money that you have never used Smalltalk - based on the above statement.
Smalltalk is lightyears ahead of "gdb --pid=[running process]". With Smalltalk you can develop and bugfix your application *while it is running* and experience the results immediately.
For example, I did considerable work on an IRC bot developed in VisualWorks, while the bot was connected to the IRC server. There was almost never any need to restart anything. Changes I made were immediately available. The only reason to re-connect was if something was changed that affected the connetion/login procedure - for obvious reasons.
In a real crunch you can debug and alter a production system with zero downtime and no restarts. There is no stop/edit/compile/run cycle. If I recall correctly someone posted on comp.lang.smalltalk a while back describing such a situation...
Everyone interested in this might want to have a look at AOS, one of the two platforms (CLR/.NET being the other) targeted by SmallScript/S# at
www.smallscript.net.
I am not that well informed, but as I understand it AOS is essentially a more generic and language neutral alternative to CLR.
I've been saying a long time that C and other unsafe languages simply are not suitable for most applications. There must be a very good reason for such languages to be the primary (good) choice.
And truthfully, I don't feel safe knowing that most of the code running on my machine and servers out there is written in unsafe languages.
Like the article author mentioned, who knows how many bugs are out there being actively exploited because they are not yet widely known?
Of particular importance is the fact that bugs such as buffer overflows don't exist *AT ALL* in other languages. Yes, there are many ways to introduce security vulnerabiliies in applications, regardless of language. But with unsafe langauges that allow bufer overflows, even the simplest application may have disastrous bugs.
For example, a network monitoring system that does nothing but monitor traffic can easily contain a remote root exploit if written in an un-safe language. If written in a safe language, it is virtually unthinkable that such a bug exists, because the application simply does not perform actions that are even related to privileges / unsafe file access, and, as opposed to the unsafe language equivalent, there are no arbitrary-code-execution bugs. (Assuming of course one doesn't doo things like invoking shell scripts, in which case unchecked parameters can cause grief.)
If everyone started writing code in safe languages except where an unsafe language was *really* called for, there would almost certainly be a LOT less exploitable bugs, and in particular, a lot less random. Yes, a buggy ssh server written in a safe language is a hazard. But a buggy time server isn't, nor is a network monitoring application, and nor are a number of other types of applications.
In short, without arbitrary-code-execution bugs, it is much easier to determine what type of damage is likely to be caused by a certain application. And the probability that a bug steps outside of its scope of expected bugs is much smaller.
So please, enough with the low-level conservatism please.
I keep reading about internet taxation on slashdot.
What's all the fuss about? Why would the internet's involvement affect taxes at all, in any direction?
Are purchases made over the internet in the US not subject to taxes they would otherwise be subject to?
I don't know if the original poster meant managing their current codebase of C++ or going for something new.
:)
But if productivity is a factor, one should seriously look into Smalltalk.
A few URL:s to have a look at:
www.whysmalltalk.org
www.cincom.com (VisualWorks Smalltalk)
www.squeak.org
www.exept.de (Smalltalk/X)
Squeak is certainly cross-platform... it's difficult to find something it doesn't run on
VW is less portable but fater and commercially supported. Also more expensive.
(There are other not-so-cross-platform dialects.)
I am currently involved in a project where we are trying to launch a WaveLAN based internet service to custerom's in a small area (200-300 houses). No DSL alterantives are available from any major supplier, and the cost of a pair of copper wires alone makes using DSL to expensive for the customer.
Initially, at least 50 people reported interest. We later learned there were many people interested who had not responded to the initial call for interest. It looks like there are 50-100 houses in the area seriously interested in an internet connection of this kind.
We recently started taking orders; so far we have slightly about 10. Probably because most people are waiting for other people's experience, etc. We're not sure. We have a few cards to play in order to spice up interest, but not much.
How did *you* get people to commit?
Guess I was to upset to spell correctly...
Honestly.
I mean, this is not just some minor licensing issues or whatever. People are actually trying to put other people in jail for writing software that enables people wo watch DVD:s they have payed for. That's exactly what's happening - why can't the people adovacting this crap see that?
*sigh*
Have you tried comparing it? I haven't, but I certainly haven't seen anything from MS that does as good a job as FFMPEG's MPEG-4 implementation (ffmpeg.sourceforge.net) or DivX ;-).
And what is the status of H26.L (I think it's called). It's supposed to be the next-generation post-mpeg-4 codec, but I have not found much information on it.
(I'm not a developer, just an observer of the project.)
Subversion is nearing a first final release. The alpha version is just around the corner, and development is very active.
Subversion is basically CVS done right. Natively client/server, atomic commits, proper handling of binary files, proper versioning of everything - including directories and file metadata, and much more. Go read about it at http://subversion.tigris.org
Oh really. I'd be interested in what you base that on, Mr. "Anonymous Coward".
Put spaces? Ok, if you want to burn lots of paper. It's difficult to do when you are given two pieces of paper filled with questions and a specific amount of vertical space to answer each one.
As for whining, I *should* whine if I believe there is a flaw in the system. Just accepting fact and living with it instead of *thinking* is the reason Hitler got away with it...
>If you, as the poster mentioned, feel the need to erase "large blocks" of code, you probably didn't think the program out well enough ahead of time.
See my other response on this subject. It's not about inability to think the program out well enough ahead of time; it's about having to do so to a different extent - and in a different way - than normal. When writing code on paper, certain things suddently become relevant that are irrelevant when using a text editor. One such thing is the number of lines of code a code block will end up taking.
(Of course, if you end up with code blocks a hundred lines long it's probably badly desgined in some languages etc, but that's another issue.)
I do it because it works fine using a text editor. It finishes the outer parts of the code; only the inner parts need to be considered.
:)
I've seen people write entire Java classes entirely from top to bottom. The results are usually not very pretty...
So sue me.
I originally wrote something else, and changed it to ridiculous. I failed to changed the entire word correctly.
Of course they have - a pretty good idea. You don't write the entire program line-by-line mentally first (at least, I've never heard of anyone doing that).
Part of programming is creating abstractions and factoring code. You don't keep the source code and state of the entire program in your head at one time. You deal with the relevant parts. For example, suppose I were to write a method that answers the absolute age difference between two people.
First, I'd worry about the method at hand:
absoluteAgeDifference: aPerson
^self (ageDifference: aPerson) abs.
This implementation is completely independent of the implementation of Person>>ageDifference. After writing that method, I would implement #ageDifference - unless it already existed:
ageDifference: aPerson
^self age - aPerson age.
This is my normal way of doing things. If I had to do this on paper, I would have to think through dependency methods first in order to calculate what will fit where.
But to get back to the issue of braces. Suppose I needed to write code that answers the most wealthy relative of a person. First, I'd probably write:
mostWealhtyRealtive
"Answers the most wealthy relative of the receiver, or nil if the receiver has no relatives."
self hasRelatives ifTrue: [
] else: [
^nil.
].
After having written this, I would fill in the code block. The implementation may be extremely simple, or mit may be relatively complex, depending on the methods already available to me and to which extent I want to factor the implementation for usability (i.e. divide into more methods).
It may sound simple; but when doing this on paper, the whole process of writing code just becomes different. Suddently you need to concentrate on pety details of syntax instead of the problem. It wastes time, and is annoying.
All IMHO of course...
The math situation is different, because that's how you normally do math. It's as simple as that.
If I normally wrote code on paper, it wouldn't be a problem. But I don't. And I won't start in order to defeat some exam.
Eh? Indenting is irrelevant. This is about the amount of vertical space the code is going to take.
I have no resect for any exam that involves writing actual code on paper. Asking about fundamental principles is fine; asking for pieces of code or specific API details is IMO rediculous.
Granted, you can never design a perfect test. But you can at least do away with the totally obvious imperfections like asking people to do things in ways they never do and never will do in the future (except on other tests).
The few times I was subjected to these tests, I sure felt primitive erasing entire chunks of code after having realized I needed to insert something in the beginning. And it's a hard thing to avoid; I don't think any reasonably experienced programmer writes code entirely from top to bottom. Just a simple thing as placing braces becomes a hurdle in writing unless you know the length of the code you need to put between them!
This is a big problem on Windows due to the way the system is designed and due to the way applications work. I have been involved in this sort of thing for a while now; and while we've managed to mostly get things done correctly, it's not perfect.
Firstly, Windows does not really have the concept of a home directly. Certainly, there is the user's profile which gets synched to the server (assuming a domain account). But the problem is that the concept of a user *ONLY* having access to his or her own file - PERIOD - is non-existent.
Firstly, MANY applications require administrator provileges to even run correctly, EVEN THOUGH they don't *actually* need it to perform their task. This is absolutely brain-dead on the part of the software vendor; it's as if 'mutt' were to need write access to anything but ~ in order to work.
In the windows world, the need it becaues they want to store user data in the program folder on C, or under HKEY_LOCAL_MACHINE in the registry, or various other stupid reasons. This has the result that we are often FORCED to give users administror privileges just so they can run their broken applications! Even *THE* most popular bookkeeping program here in Sweden has problems of this kind. I cannot believe they get away with it.
The above negates the effect of fiddling with file permissions such that the user cannot write to C: except to c:\temp. So that's out. And even if it weren't, there are plenty of applications that insist on fiddling with certain files outside of the user's profile, even if they do not store any critical user data outside it.
On Unix it's simple. Backup ~ and you have *EVERYTHING*, period.
In my opinion, going digital is a good thing for quality reasons.
Analog technology yields random picture noise, both in theaters and on DVDs mastered from an analog source. Just compare a DVD mastered from a movie shot with a digital camera (such as Livvakterna and SW2; and I'm sure a host of others) to those mastered from analog sources. The difference is huge.
Another sideeffect of "noiseless" video is that it compressed much better. Just think of how much you could fit on a HD-DVD in the future if movies were all-digital and they used MPEG-4 on the DVD (although I'm sure they'll stick to MPEG-2 - nevermind being futureproof).
And in theaters - am I really the only one who is annoyed at the artifacts that are continually visible due to particals on te film?
I was laughing my ass off all the way through it!