At this point, this is nothing more than another "me too" sort of post, but I like it.
I can agree that there is probably more whitespace than needs to be, but I don't find it distracting.
I'm fairly indifferent on "position: fixed" elements on a page, so I can't relate to the out-rage over the header and sidebar.
I can copy & paste into text boxes again, so that's a plus.
As for performance, if there's any kind of "comment auto-loading" based on scrollbar event firing, see Learning from Twitter by John Resig. I haven't personally experienced this yet, so this may not be the issue at all.
Anyway, definitely an improvement in appearance.
Dr. Jahn, we believe that the purpose of science is to serve mankind. You, however, seem to regard science as some kind of dodge or hustle. Your theories are the worst kind of popular tripe, your methods are sloppy, and your conclusions are highly questionable. You are a poor scientist, Dr. Jahn.
I will not comment on the obviousness (or non-obviousness) of this patent, but I would like to point out the following:
"[F]or a court to find infringement, the plaintiff must show the presence of every element or its substantial equivalent in the accused device." Wolverine World Wide, Inc. v. Nike, Inc., 38 F.3d 1192, 1199 (Fed. Cir. 1994)
-Wikipedia entry on Patent Infringement
If this is true, and every claim must be violated, then to avoid infringement there are a number of things a developer can do:
Use more or less than 4 degrees of separation (claim 7 of Friendster patent)
Do not store email addresses for unregistered users (claim 8) [how to send invitations without storing email addresses in a database is left as an excercise to the reader.]
Do not hyperlink the entire "connection path" between two registered users. (claim 5)
It is important to note that I am not a lawyer, and this is not to be construed as legal advice. The validity of what I am suggesting hinges on the notion that all claims of a patent must be infringed for the patent to be infringed upon. I do not know for certain that this is the case.
Yes, a GET request can be put into the src of an img tag, but that doesn't make POST more secure. A proper web-app should use GET requests for fetching data, and POST for modifying data. However, all requests should be validated on the server-side. If an unprivileged client can follow a GET request that deletes content, then the web-app is not performing proper validation. If that's the case, hiding the request behind a POST is not going to stop a malicious attacker from deleting content. This was my original point, if you're not validating a request, POST or GET, then using POST instead of GET is a pretty weak measure of "securing" anything.
Treading into the land of off-topicism here, but I encountered a similar thing at a previous job. What was even more awesome was that the code to open the file specified in somescript.pl?template=filename used the Perl open function, without any input validation. So, not only could you read any file, you could also pass in something like: template=filename|ls and execute any command on the server under the privileges of the script's owner.
You are absolutely correct. The example the author provides of the.len paramter not being checked by the web app is a prime example of the kinds of problems that plague any web application, AJAX or not. Input validation, session validation, user authentication and so forth are required by EVERY web application. This part particularly irritated me:
If the XmlHttp-interface is merely protected by cookies, exploiting this is all the easier: the moment you get the browser to make a request to that website, your browser is happily sending any cookies along with it.
That is true of most common methods of session management. For instance, PHP's very own built-in session management, which many people use, uses nothing more than a cookie value to manage the session. If you want to secure any web-app that uses sessions through cookies (again, AJAX or not) you'd better be using an HTTPS connection and cookies that are flagged to only be transmitted across a secure connection, and the author never touches on this point.
Add to that the whole nonsense about POST being "more secure" or "harder to fake" and it becomes clear that these are the words of a novice web programmer. And clearly this article illustrates nothing more than a web programmer's first experiences with examining the security of a web app.
But, he's linked to slashdot's main page, with plenty of AdSense links... so good for him.
I've seen those same bugs in FF 1.5 as well. The flickering bookmark bug is a pain, it seems that occasionally if you click on a bookmark folder, it will stop the flickering, but this doesn't always work and the only sure method does seem to be to close the browser and start again. I'd recommend the session saver plugin as something to help cope with that irritation.
As for flash, I initially had the same problem, but it didn't seem to be tied to Flashblock, rather the flash plugin itself. I'm currently running Ubuntu, so this may not be the same issue you're having, but the solution I found was to backup my bookmarks, then blow away all of ~/.mozilla/firefox, and let 1.5 rebuild the directory as it saw fit. Simply removing the plugins folder wasn't enough.
I hope this helps, but if not, at least I wasted some of your time!
Consider your sig: Stop censorship, eliminate the SLC funding that enables CIPA.
You wish to Kill SLC to stop CIPA, apparently with the intent of ending some form of censorship. And yet, you talk essentially classify anyone reading this particular book as a "retard", unless they're reading it for purely educational purposes or for the sake of completeness.
Perhaps I'm being too extreme, perhaps I'm simply not understanding your enlightened position. Whatever the case may be, to "answer their challenge with a bullet" sounds like a pretty strong form of censorship to me.
This demonstrates that no matter how old you are, where you work, or how low your Slashdot UID is, you can still be a full blown douche bag.
Shop at Think Geek, Fools
or
Fools shop at Think Geek
Or some other permutation of this that I'm too inept to figure out because I wasted what little mental capacity I had anagramming "Fake Ghostlike Photons"
It appears to be based on GTK 2, which has been ported to windows, so at least, in theory, it is possible. Whether or not it will be ported will remain to be seen.
I remembered seeing a preview for a Fantastic Four movie on a VHS many years ago, it looked terrible, and I never heard anything more of it. It apparently turns out that a movie was made in 1994 and, I guess, never actually released. IMDB (the link) provides some insight into why it wasn't, and what the goal was originally. So, Hollywood will not only steal your childhood and market it to you again later on, it will also steal your childhood for the sake of marketting it to itself! Hooray for Earth!
Right, but the point was, if there are people who make poor choices in operators for overloading, there are people who make poor choices in functional naming in the same way. I just used Date here because I happened to be working with one when I wrote the original post. The ultimate point is that "bad form" practices, such as unclear operator usage, or poorly named member functions, are affected only in a small way by forbidding operator overloading.
Exactly. Removing a feature will not drastically improve coding practices. For instance, a bad programmer may do funny things with a '+' operator that confuse the rest of us, but they can just as easily do bad things like name a member function.doSomething(... ), which is just as unclear within the code.
If we assume MyDate is a subclass of Date, and that it relies on Date's constructors, we should get a Date object that represents 2 milliseconds before the Epoch (Jan 1, 1970 00:00:00 GMT). Of course, how I know this is because of the javadoc documentation, so if we assume the programmer creating MyDate uses javadoc to indicate what.add(-5) does to MyDate, everything's still right as rain. However, they could just as easily do the same with the +/-* operators, and then everything is again, just as nice.
I agree with this whole-heartedly. While I've gotten away from operator overloading on account of using Java, it bothers me every time I'm allowed to do a "this" + "sucks" and have it resolve to an object. I think the idea behind not providing operator overloading was to remove ambiguity, because some people might make arbitrary choices about how two different objects are combined with an operator that may not be intuitive to other developers. While that reasoning seems ok, consider what's happened instead. They wanted to prevent lines like:
Date d = new Date() + 5;
So, now what we get is this instead:
MyDate d = new MyDate();
d.add(5);
Is it really any clearer to someone who's not going to dig through MyDate.java (provided it is available) what this is doing versus the previous example?
I think Sun effed up on this choice.
Re:Why I believe this sig to be of interest.
on
Prime Obsession
·
· Score: 1
Haha, well, the two ideas are very similar, just a difference in interests I suspect;) Math dominates almost every aspect of my life, thus: a math based sig. I'm not suggesting that Star Wars dominates every aspect of your life, but I would wager it's at least an enjoyable hobby for you, heh.
Slashdot Mirror
You can manually add sites to block by going to the blocked sites manager:
http://www.google.com/reviews/t
At this point, this is nothing more than another "me too" sort of post, but I like it. I can agree that there is probably more whitespace than needs to be, but I don't find it distracting. I'm fairly indifferent on "position: fixed" elements on a page, so I can't relate to the out-rage over the header and sidebar. I can copy & paste into text boxes again, so that's a plus. As for performance, if there's any kind of "comment auto-loading" based on scrollbar event firing, see Learning from Twitter by John Resig. I haven't personally experienced this yet, so this may not be the issue at all. Anyway, definitely an improvement in appearance.
One need only consult Jim Mallon's Wikipedia Page or the Onion AV Interview with Joel to confirm that it was a fight between Hodgson and Mallon that ended Hodgson's time with MST3K.
Dr. Jahn, we believe that the purpose of science is to serve mankind. You, however, seem to regard science as some kind of dodge or hustle. Your theories are the worst kind of popular tripe, your methods are sloppy, and your conclusions are highly questionable. You are a poor scientist, Dr. Jahn.
I will not comment on the obviousness (or non-obviousness) of this patent, but I would like to point out the following:
If this is true, and every claim must be violated, then to avoid infringement there are a number of things a developer can do:
It is important to note that I am not a lawyer, and this is not to be construed as legal advice. The validity of what I am suggesting hinges on the notion that all claims of a patent must be infringed for the patent to be infringed upon. I do not know for certain that this is the case.
Yes, a GET request can be put into the src of an img tag, but that doesn't make POST more secure. A proper web-app should use GET requests for fetching data, and POST for modifying data. However, all requests should be validated on the server-side. If an unprivileged client can follow a GET request that deletes content, then the web-app is not performing proper validation. If that's the case, hiding the request behind a POST is not going to stop a malicious attacker from deleting content. This was my original point, if you're not validating a request, POST or GET, then using POST instead of GET is a pretty weak measure of "securing" anything.
Treading into the land of off-topicism here, but I encountered a similar thing at a previous job. What was even more awesome was that the code to open the file specified in somescript.pl?template=filename used the Perl open function, without any input validation. So, not only could you read any file, you could also pass in something like: template=filename|ls and execute any command on the server under the privileges of the script's owner.
Very well said. I particularly like the view of GET and POST as functions, but then I am a mathematician, at least in title.
You are absolutely correct. The example the author provides of the .len paramter not being checked by the web app is a prime example of the kinds of problems that plague any web application, AJAX or not. Input validation, session validation, user authentication and so forth are required by EVERY web application. This part particularly irritated me:
That is true of most common methods of session management. For instance, PHP's very own built-in session management, which many people use, uses nothing more than a cookie value to manage the session. If you want to secure any web-app that uses sessions through cookies (again, AJAX or not) you'd better be using an HTTPS connection and cookies that are flagged to only be transmitted across a secure connection, and the author never touches on this point.
Add to that the whole nonsense about POST being "more secure" or "harder to fake" and it becomes clear that these are the words of a novice web programmer. And clearly this article illustrates nothing more than a web programmer's first experiences with examining the security of a web app.
But, he's linked to slashdot's main page, with plenty of AdSense links... so good for him.
I've seen those same bugs in FF 1.5 as well. The flickering bookmark bug is a pain, it seems that occasionally if you click on a bookmark folder, it will stop the flickering, but this doesn't always work and the only sure method does seem to be to close the browser and start again. I'd recommend the session saver plugin as something to help cope with that irritation.
As for flash, I initially had the same problem, but it didn't seem to be tied to Flashblock, rather the flash plugin itself. I'm currently running Ubuntu, so this may not be the same issue you're having, but the solution I found was to backup my bookmarks, then blow away all of ~/.mozilla/firefox, and let 1.5 rebuild the directory as it saw fit. Simply removing the plugins folder wasn't enough.
I hope this helps, but if not, at least I wasted some of your time!
Consider your sig: Stop censorship, eliminate the SLC funding that enables CIPA. You wish to Kill SLC to stop CIPA, apparently with the intent of ending some form of censorship. And yet, you talk essentially classify anyone reading this particular book as a "retard", unless they're reading it for purely educational purposes or for the sake of completeness.
Perhaps I'm being too extreme, perhaps I'm simply not understanding your enlightened position. Whatever the case may be, to "answer their challenge with a bullet" sounds like a pretty strong form of censorship to me.
This demonstrates that no matter how old you are, where you work, or how low your Slashdot UID is, you can still be a full blown douche bag.
Shop at Think Geek, Fools
or
Fools shop at Think Geek
Or some other permutation of this that I'm too inept to figure out because I wasted what little mental capacity I had anagramming "Fake Ghostlike Photons"
The proper decoding of the post is left as an exercise for the reader.
In a post-Columbine world, it is critical that we at least one inflammatory troll to replace Jon Katz.
Not that this is even remotely on topic now, but...
It is possible that Adams has little or no control over this sort of thing. I remember Bill Waterson being really upset with how the Syndicate made use of "Calvin" (pissing on various car emblems and so forth.) In fact, if you look at the BSAEngineers page, and read the copyright notice at the bottom, Adams isn't even mentioned.
"DILBERT©United Feature Syndicate, Inc"
Intersting point, but if it is all this direct and simple, why can't we replicate it in machines yet?
Nope, they mean Val Kilmer.
It appears to be based on GTK 2, which has been ported to windows, so at least, in theory, it is possible. Whether or not it will be ported will remain to be seen.
I remembered seeing a preview for a Fantastic Four movie on a VHS many years ago, it looked terrible, and I never heard anything more of it. It apparently turns out that a movie was made in 1994 and, I guess, never actually released. IMDB (the link) provides some insight into why it wasn't, and what the goal was originally. So, Hollywood will not only steal your childhood and market it to you again later on, it will also steal your childhood for the sake of marketting it to itself! Hooray for Earth!
Right, but the point was, if there are people who make poor choices in operators for overloading, there are people who make poor choices in functional naming in the same way. I just used Date here because I happened to be working with one when I wrote the original post. The ultimate point is that "bad form" practices, such as unclear operator usage, or poorly named member functions, are affected only in a small way by forbidding operator overloading.
I'm pretty sure it's a long, but I could be wrong.
Exactly. Removing a feature will not drastically improve coding practices. For instance, a bad programmer may do funny things with a '+' operator that confuse the rest of us, but they can just as easily do bad things like name a member function .doSomething( ... ), which is just as unclear within the code.
If we assume MyDate is a subclass of Date, and that it relies on Date's constructors, we should get a Date object that represents 2 milliseconds before the Epoch (Jan 1, 1970 00:00:00 GMT). Of course, how I know this is because of the javadoc documentation, so if we assume the programmer creating MyDate uses javadoc to indicate what .add(-5) does to MyDate, everything's still right as rain. However, they could just as easily do the same with the +/-* operators, and then everything is again, just as nice.
;)
PS: Love the sig
I agree with this whole-heartedly. While I've gotten away from operator overloading on account of using Java, it bothers me every time I'm allowed to do a "this" + "sucks" and have it resolve to an object. I think the idea behind not providing operator overloading was to remove ambiguity, because some people might make arbitrary choices about how two different objects are combined with an operator that may not be intuitive to other developers. While that reasoning seems ok, consider what's happened instead. They wanted to prevent lines like:
Date d = new Date() + 5;
So, now what we get is this instead:
MyDate d = new MyDate();
d.add(5);
Is it really any clearer to someone who's not going to dig through MyDate.java (provided it is available) what this is doing versus the previous example?
I think Sun effed up on this choice.
Haha, well, the two ideas are very similar, just a difference in interests I suspect ;) Math dominates almost every aspect of my life, thus: a math based sig. I'm not suggesting that Star Wars dominates every aspect of your life, but I would wager it's at least an enjoyable hobby for you, heh.