Publishing on the Web is very different from older methods of publication. A Web publication is inherently a general, device-independent and program-independent document with structural markup. The presentation of a document may vary greatly, and it must vary, to allow viewing (or hearing) the same document on a wide variety of devices, ranging from wristwatch monitors to full-size movie screens.

Why the fuck don't we get this yet? We've been doing this for 17 years now, and for all the trendy lip service arty web geeks pay to upholding "web standards" we still end up with shit like this. Got a large screen? Too bad. Fixed margins. Pixel offsets. You *will* look at this webpage this way and no other way (unless you want to write your own style sheet to use my horribly named DOM classes that is).

Just try to increase the font size on any "modern" webpage and watch it utterly break.

We have jumped from enforcing design through diarrhea of the <TABLE> tag in the 90s, to enforcing design through obscenely complex CSS styles. It's the same damn thing.

Publishing on the Web Is Different!

Tips about how to make websites more readable for web crawlers as well as human's with disabilities who may be using different user-agents.

Advice includes:

*proper ways to construct alt text
*using title attributes in hyperlinks
*using link tags to denote forward, back, and up leveling
*proper tabel headers

Dive Into Accessibility: Making truely readable websites

Updated
I just got an email from Joe Hart over at SecureTest with a screen shoot confirming IE6 + XP SP2 + Acrobat Reader 6 is vulnerable.

Now we have:
IE6 + Acrobat Reader 4 + XP SP2
IE6 + Acrobat Reader 6 + XP SP2
IE6 + Acrobat Reader 7 + XP SP1
(possibly) IE 6 on non-XP platforms
Firefox 2.0.0.1
Firefox 1.5.0.8
Opera 8.5.4 build 770
Opera 9.10.8679

RSnake is a fucking genius. Using a file:/// URL pointed at the manual PDF installed with Acrobat, you can execute JavaScript in the local zone. Oh yeah, local file access, program execution, completely uncrippled XmlHttpRequest.

This is not good.

It hits the fan!

There is a flaw in Abode’s Acrobat reader plugin which allows JavaScript to execute. This flaws means ever website that contains a PDF file has a de facto Cross Site Scripting (XSS) vulnerability. Clicking on a link like http://bank.com/report.pdf#EVILCode will cause JavaScript to execute in the context of bank.com. Regardless of how security bank.com’s website is, attackers can get their own JavaScript to interact with the website, exposing everyone on bank.com to all the traditional dangers of XSS. It is important to note that there is nothing wrong or malicious about the PDF file itself. An attack doesn’t need to upload a malicious file for this to work. The issue is Adobe executes an JavaScript that is contained in the fragment (#) of a hyperlink.

This flaw essentially backdoors every website on the Internet that hosts a PDF. Any website with a PDF can be the target of a hyperlink with a malicious fragment added to it. This flaw is so extremely dangerous because an attacker simply creates a malicious hyperlink to any legitimate PDF on any website and can attack that website.

It gets worse, because there is little a website can do to stop the attack. If a victim clicks on a link like http://bank.com/report.pdf#EVILCode, the #EVILCode fragment is not actually sent to bank.com. Thus bank.com cannot detect if a PDF is being requested to launch an attack, or is being requested for legitimate purposes Short of removing all PDF’s from their site, a company cannot protect itself or it’s users from this technique. This flaw can also be exploited using an HTML iFrame. This means a victim doesn’t have to physically click on a bad link; simply viewing a website could cause a PDF to load and exploit the user.

XSS can be used for various types of attacks, such as phishing, password stealing, self-propagating worms, keystroke logging, and attacking internal corporate networks.

This vulnerability is interesting because it occurs in a browser plugin, making all browser’s that use the plugin vulnerable. It is also interesting because it doesn’t require an attacker to create or upload a malicious file. This attack piggybacks on top of perfectly safe PDFs.

Updated
Effected Browser: (all on Windows)
IE6 + Acrobat Reader 7 + XP SP1
IE6 + Acrobat Reader 4 + XP SP2
(possibly) IE 6 on non-XP platforms
Firefox 2.0.0.1
Firefox 1.5.0.8
Opera 8.5.4 build 770
Opera 9.10.8679

So, ignore global warming, meteors, the ozone leaving or the sun exploding, we are definitely going to blow ourselves up!

Funny Flash animation of nuclear Armageddon.

The End of the World

An 8.3-ounce can of Red Bull contains 80 milligrams of caffeine, about the same amount of caffeine as in a cup of coffee. By comparison, Coca-Cola contains about 34 milligrams of caffeine per 12 ounces. Full Throttle energy drink contains 144 milligrams of caffeine per 16-ounce serving, while 16 ounces of Rockstar contain 150 milligrams of caffeine.

For a healthy adult, 200 to 300 milligrams of caffeine a day is considered a moderate amount, according to the American Dietetic Association.

Some cool info buried in an standard "oh won't someone think of the children" article.

I consume way more than 5 red bulls in 30 days.

ABC News: Red Bull Not the Best Mixer

Jello wrote:

Acidus wrote:

new Ajax.Request('?url=backend',{onSuccess:responseHandler});
var responseHandler = function(t) { json = eval(t.getResponseHeader('X-JSON'));

eval() is the WORST thing you can ever do in JavaScript and people who process JSON with eval() should be punched in the face.

Quoting from the great Douglas Crockford:

However, [eval()] can compile and execute any JavaScript program, so there can be security issues. The use of eval is indicated when the source is trusted. This is commonly the case in web applications when a web server is providing both the base page and the JSON data. There are cases where the source is not trusted. In particular, clients should never be trusted.

When security is a concern it is better to use a JSON parser. A JSON parser will only recognize JSON text and so is much safer:

var jsonObject = eval('(' + jsonString + ')');

You mean like that?

Ducks.

As Crockford (the man who invented JSON) states, eval give access to the full JavaScript compiler. Using eval to parse JSON can be attacked 2 ways:

1- You have a mashup or data from other sources that you cannot trust.
2- Unvalidated user input is placed inside the object being returned by JSON.

Consider receiving/processing a JSON object which is an Array of someone name.

["Alice", "Eve", "Bob"]

Eve makes her name ""]; alert('xss');//
Now what gets evaled is ["Alice", ""];alert('xss');//", "Bob"]

Eve has achieved code execution!

Once again something that an be solved if all user input is properly validated, included data from 3rd party sites.

However, the big reason I made this most is that Prototype (and thus Script.aculo.us) has a built in feature, to always eval the contents of an HTTP header! I doubt most people using the framework know this exists, and short of modifying the framework, it doesn't appear that you can turn it off.

At what point does a feature become a backdoor?

More on: X-JSON in Prototype

new Ajax.Request('?url=backend',{onSuccess:responseHandler});
var responseHandler = function(t) { json = eval(t.getResponseHeader('X-JSON'));

eval() is the WORST thing you can ever do in JavaScript and people who process JSON with eval() should be punched in the face.

Quoting from the great Douglas Crockford:

However, [eval()] can compile and execute any JavaScript program, so there can be security issues. The use of eval is indicated when the source is trusted. This is commonly the case in web applications when a web server is providing both the base page and the JSON data. There are cases where the source is not trusted. In particular, clients should never be trusted.

When security is a concern it is better to use a JSON parser. A JSON parser will only recognize JSON text and so is much safer:

X-JSON in Prototype

January 2007
Cover Story

Stronger Security: How to Clean Up Your AJAX Applications. Apps built with AJAX offer more options than their page-based counterparts -- along with a higher risk of vulnerabilities. Here's how to keep your apps squeaky clean. By Billy Hoffman and Bryan Sullivan

My co-author Bryan Sullivan and I wrote the cover story on January's Software Test and Performance magazine. Editor's on our side and their side trimmed some of the more technical details, but I'm very happy with the results.

You can download the issue in PDF.

Ajax cover story in Software Test and Performance magazine