There are many ways to design an interface.

Perhaps the oldest is a linear text based input system where things are done sequentially and interrupts must be addressed immediately. The programmer was happy because this meant only a limited amount of juggling. Whenever the program(mer) needs something from the user, it has to interrupt whatever the user is doing. This is frustrating, especially if the user has to respond to many questions (do you want to accept this cookie? what about this other one? is it OK to redirect to another web site? you're about to lose your form data...).

Links/Lynx use this traditional linear input system for when you load a http url that has a redirect or that offers a cookie. You're stopped for each individual problem. It's really bothersome.

The first replacement for a linear system was of course something non linear. The screen is filled with multiple items which accept input and the user is given some freedom about the sequence in which they are filled out. Eventually this led to windows.

Unfortunately programmers are lazy and like the linear approach so they created modal dialogs which annoy people as much as the text based linear system and frustrates them more because they know that windows are supposed to work better.

Windows allows multitasking; the user might load one page in one window and read another page in another window. It turns out (see apple's Single Window mode and an idealized tabbed browser) that users really don't like to be interrupted. They'd much rather finish what they're doing, then read a list of problems and address or ignore them collectively.


So what problems am I considering?

suppose you visit http://classic.example.com/firstpage

classic.example.com sends you some cookies.

Firstpage has some html with images, a background, JavaScript to open a window, some plugin content and of some text you want to read.

Let's deal with these items chronologically in terms of web browser development.

Originally web pages were just text documents, which was of course the important stuff.

Then html supported images and web browsers allowed you to view them inline. But not everyone wanted to see them.

So what happened?

some people wanted a pref, some people wanted a confirmation, some people just wanted to see them, and some people never wanted to see them.

An amusing note about just how bad dialogs are, Mozilla at one point allowed you to be prompted about whether you wanted to load each image individually. The feature was removed because the prompts piled up, caused nesting and eventually a crash if you didn't respond to them quickly enough :). The feature is gone, which is a good thing. But some people actually complained about it going away :o.

So... what did old browsers do?

Normally you would choose whether you wanted images to load by default, and if you didn't then you'd have two options, a way to load all images for the current page, and a way to load an individual image.

Then Netscape invented cookies. And then someone discovered paranoia.

So servers can send you cookies, and your browser promises only to share the cookies with the server from whence they came. It wasn't supposed to be a big deal.

There are currently three ways that browsers handle the receipt of cookies.

  1. They accept all of them
  2. They refuse all of them
  3. They ask the user about each of them, offering accept all, refuse all, accept, reject.

There are also some simple policies for cookies, limiting them to the current session and only accepting cookies from the server of the main document.

Some strange proposals have been given which would allow the web site to tell the user how it intends to use the cookies it gives the browser, but there's nothing which forces the web site to honor its claims and it doesn't really change the choices available to the user (well, it adds even more complicated and confusing choices, but in the end you still have options equivalent to 1, 2, or 3).


Cookies

Cookies in Mozilla were stored in a file called cookies.txt, and people could look at them and snip out cookies one at a time, or many at a time. Normal users wouldn't do it, but advanced users might.

IE groups cookies by site, so you can either edit cookies.txt or edit magic files for the individual sites. I doubt anyone really knows about these abilities, but some probably know that they can delete all cookies, or all cookies for a single site.

Mozilla/5's response to all of the problems I'm describing in this page are managers, each manager is basically a two column narrow dialog which might let you select one line at a time and perhaps do something to it. Searching isn't really available and if you want to change settings for cookies and images for a specific site then you'll have to open the manager for each type of thing and search for the site.


Plugins

This introduced the idea of enhanced content. Some people would spend lots of time collecting plugins to handle content. Other people might only want certain content to be handled by certain plugins. Some browsers had ways to configure which plugin was used for individual mimetypes, some were supposed to at least let you disable individual plugins.


Certificates

A certificate is supposed to assure someone or something that something is what it says it is.

What can go wrong?

Otherwise, here are some things that content developers can do to make life hard for the useragent:


Popups.

Created in Netscape 3, they allowed sites to provided floating navigation windows among other things.

Was this creation necessary?

Users could already create windows on their own by context clicking and selecting open link in new window. Users could already drag links from one window/frame to another. Using traditional frames, web sites could manipulate other pages.

So what did popups add that wasn't available?

Floating movable navigation/control windows.

Is there some other way to achieve this without putting the control in the hands of the content authors?

Probably. The open frame in new window option could affect the window object references and transfer any script contexts so that it would still relate to its original peers.
Are there other choices? yes. Read on :)