Preventing cross-site scripting attacks
I just noticed that Quixote's htmltext
type is discussed in the current Secure programs HOWTO. Cool.
I just noticed that Quixote's htmltext
type is discussed in the current Secure programs HOWTO. Cool.
Slashdot is running story on greylisting
. The idea is very similar to my spam delay
idea. Some people call it tempfailing
. The author of the paper has missed an important refinement. Using a content filter like spamassassin or spambayes greatly reduces the amount of delayed mail.
Also, it looks like many slashdot kiddies forgot to read the paper (what else is new?). Retrying the delivery immediately will get spammers nowhere since the block lasts for a fixed amount of time.
I just saw this headline on the canoe.ca website: Smoking marijuana
increases risk taking: StatsCan
. That would be a interesting result but I
suspected that the headline was grossly inaccurate. Here's a quote from
Statistics Canada used in the article
the incidence of marijuana use was 1.8 to 2.6 times higher among youth who reported participating in risky behaviours such as staying out all night without permission, taking money from parents and damaging others' property
I wish people would learn the difference between correlation and causality. The quotes from the report don't say anything to support the title of the article.
First, install the iproute tools. ifconfig and route are lame in comparision. To blackhole an address:
ip route add blackhole <address>
If you don't have the iproute tools you can use route to get a similar effect:
route add -host <address> reject
In addition to individual hosts, you can blackhole networks. After figuring this out I promptly blackholed Dartmail's servers. Spamming bastards.
I think the biggest reason why users like web applications is due to stateless nature of HTTP. To a developer, it's a pain in the ass. However, for users it means they can almost always get out of a confusing situation by hammering on the back button or closing the window.
It is because of this theory that I believe breaking the back button is unacceptable. Web developers need to implement things so that the back button works as well as it can. You may not want to but users have a right to expect it to work.
If this theory is correct, there's no reason the idea couldn't be applied to software in general. Undo and redo is available in most applications but users cannot universally rely on it. I think that makes them afraid of getting into a situation that they can't get out of. Imagine a back button for your OS. Deleted a file by mistake? Hit back. Changed the background and don't like it? Hit back.
[comments]