Slashdot Mirror

First off, QUIT FUCKING TRESSPASSING.

How do you know he is?

He didn't specify what the issue is. Granted, he did say "hack into", so maybe he was using it and noticed that his user account page was

http://example.com/user.html?ID=123456789&loggedin=true

If he then enters that URL into a clean browser and accesses his own user information, how is that trespassing? It's the exact address he was given to access his own account.

Now, even without testing another ID, I can be pretty sure that it will work. Only "downside" is that the ID might be random and not sequential, but that's barely an improvement.

Essentially something like this would be the equivalent of me walking into a bank, asking to withdraw 200 dollars, telling them my name is "Martin Schou" (which it is), and them simply giving me 200 dollars without any kinds of checks.

It's not in any way, shape or form trespassing, fraud, identity theft or similar. What it is is a huge security issue.

However - since the original poster didn't specify what the issue was and with whom (with good reasons), you can't make a factual statement as to whether or not he's trespassing.

Perhaps the most legally justifiable answer might be to geolocate the IP address, find the correct trademark owner for a given country, and then redirect to MSD's or EMD's Facebook page as appropriate.

Do your website(s) do that? Should all websites scan their own URLs for trademarks, and redirect some of those URLs to other sites, and then give the previous content some other URL that is guaranteed to not look like someone else's name? Maybe all websites should be search engines, with of course the trademark name database being top priority.

Facebook doesn't represent their URL components as being company names, just like your site probably doesn't. In fact, for most of http://facebook.com/$WORD, $WORD is not anyone's trademark.

And God help review sites. If http://example.com/reviews/exodus is required to point to Exodus' site, then example.com has to post their review of Fabulous Disaster at http://example.com/reviews/butthead_astronomer. This is just silly.

If force is being used against Facebook over this, then 1) that's an outrage 2) they did the right thing in response to it: have http://facebook.com/$WORD do a 404 or something like that.

Perhaps the most legally justifiable answer might be to geolocate the IP address, find the correct trademark owner for a given country, and then redirect to MSD's or EMD's Facebook page as appropriate.

Do your website(s) do that? Should all websites scan their own URLs for trademarks, and redirect some of those URLs to other sites, and then give the previous content some other URL that is guaranteed to not look like someone else's name? Maybe all websites should be search engines, with of course the trademark name database being top priority.

Facebook doesn't represent their URL components as being company names, just like your site probably doesn't. In fact, for most of http://facebook.com/$WORD, $WORD is not anyone's trademark.

And God help review sites. If http://example.com/reviews/exodus is required to point to Exodus' site, then example.com has to post their review of Fabulous Disaster at http://example.com/reviews/butthead_astronomer. This is just silly.

If force is being used against Facebook over this, then 1) that's an outrage 2) they did the right thing in response to it: have http://facebook.com/$WORD do a 404 or something like that.

But if I follow a link to http://example.com/something.jpg, should it just download the image and open an image viewer, or should it display the image in my browser? Images can be inline elements in an html document, or they can be linked to on their own.

Users' choice. A link to an image opens a new document - and that document (html, pdf, jpg, etc) can end up in a new tab, new window or a different app - whatever the user prefers.

I'm not arguing against having a PDF viewer built into the browser - but I've got a much more full featured PDF viewer that I'd prefer to use. Taking the choice away sucks.

IANA guarantees that http://example.com/ will never contain any crap. It's even in the RFC. ~

What happened to the Web 2.0 version?

IANA guarantees that http://example.com/ will never contain any crap. It's even in the RFC. ~

Does this protect http://www.example.com/john/is/a/compulsive/liar ?

This is implied by the separate but concurring judgment. The Chief Justice writes: "In sum, in our view, a hyperlink should constitute publication if, read contextually, the text that includes the hyperlink constitutes adoption or endorsement of the specific content it links to." Crookes v Newton (2011 SCC 47) at paragraph 50.

No.

However, if a post linking to another site itself contains defamatory material, the poster may be liable in a defamation action.

How about http://www.example.com/john-is-a?compulsive=not&liar=no pointing to a page with derogatory statements? Would that fly?

Dunno if they ruled on that. It might depend upon whether the link is visible or not, because there isn't a technical requirement that the link be human-readable in the host document (you can link around any text you want, including potentially libelous stuff that I'm specifically not saying that I am endorsing or agreeing with). True, you could still read the URL in the browser, but I managed to link to the same URL as you did, but without making the potentially libelous words obvious to the reader (although I suppose if the libel was in the domain-name itself slashdot or some other site might tack on the libelous bit automatically). The main point the judges seem to be making is that there is no other practical way to link to potentially libelous materials that might be relevant to a free and public discussion. Anyway, in libel law if you present the libelous stuff yourself, the liabilities are somewhat different from if you say the libelous stuff is available "over there", as supplied from someone else. You might have to be careful about how you refer to the other material, but do it without endorsement and you should be ok. That seems to be the precedent they are setting.

Dunno if they ruled on that. It might depend upon whether the link is visible or not, because there isn't a technical requirement that the link be human-readable in the host document (you can link around any text you want, including potentially libelous stuff that I'm specifically not saying that I am endorsing or agreeing with). True, you could still read the URL in the browser, but I managed to link to the same URL as you did, but without making the potentially libelous words obvious to the reader (although I suppose if the libel was in the domain-name itself slashdot or some other site might tack on the libelous bit automatically). The main point the judges seem to be making is that there is no other practical way to link to potentially libelous materials that might be relevant to a free and public discussion. Anyway, in libel law if you present the libelous stuff yourself, the liabilities are somewhat different from if you say the libelous stuff is available "over there", as supplied from someone else. You might have to be careful about how you refer to the other material, but do it without endorsement and you should be ok. That seems to be the precedent they are setting.

But, the argument made by many FLOSSers is that everyone SHOULD use FLOSS and if they did, the internet would be a better place

Some supporters of FLOSS make somewhat hyperbolic statements. They aren't the mainstream, and you shouldn't get fixated on them.

And, if someone uses FLOSS and finds problems, FLOSSers say "You have the code. Fix it!"

Some might say that, but that's not my experience. IME, what is usually said that then gets misrepresented by anti-FLOSSers this way is more like:
(From a project maintainer) "(That's not at the top of our queue right now/We've got some concerns about how the obvious ways of addressing that concern might impact existing users) but we'd certainly welcome and be willing to evaluate a patch."
(Alternatively, also from a project maintainer) "Your request to add mandatory line numbers is inconsistent with the direction we want to take our scripting language. However, you have the source, so you are free to fork it and implement that yourself if you really need it."
(From a discussion forum that isn't the main support forum for the product) "Whining about that here isn't going to get you any results. You've got the source, fix it yourself, or, failing that, go to the projects issue tracker at http://www.example.com/mypetproject/tracker and file a bug."

which is suggesting everyone who uses FLOSS is obligated to fix any issue they encounter.

Even if they said what you say, it wouldn't suggest that. It would suggest that people who use FLOSS ought to use their access to the source to correct issues in software that they care about.

It doesn't mean that they need to fix issues in open source software that other people whine to them about, in fact, it is absolutely inconsistent with that attitude.

which is suggesting everyone who uses FLOSS is obligated to fix any issue they encounter.

What you describe are actually two separate documents, and thus each should have its own unique URI.

For example, the URIs could be http://example.com/home and http://example.com/m for the long and short documents respectively. Then the URI http://example.com/ would mean "redirect me to whichever version of the index document is optimal for my user agent". Choosing a document based on information other than the URI is commonplace elsewhere, such as a view of a user's page on a social networking site that depends on authorization: whether you're not logged in, logged in as a stranger, logged in as a friend of a friend, logged in as a friend, or logged in as the user himself.

Since a human user using the UA may not know that the different versions exist

Each document would link to the other. I see "Full-size version" and "Mobile version" links in plenty of web sites.

a sensible approach is to provide a very minimal landing page that links them to the two different documents. Then the human user can choose which one to view, keeping in mind the trade-offs of each.

How many web sites actually have such a landing page in practice, as opposed to a "redirect me to the document most appropriate for my class of user agent" page? And if you arrive at a document from a URI distributed outside the site itself, such as an inbound link from another web site or a link from another Internet application altogether such as mail or IRC, how is the site supposed to know whether you want to view a document appropriate for full-size user agents or a document appropriate for limited user agents? Is it even possible for a canonical URI to encompass all such documents in such a case?

What you describe are actually two separate documents, and thus each should have its own unique URI.

For example, the URIs could be http://example.com/home and http://example.com/m for the long and short documents respectively. Then the URI http://example.com/ would mean "redirect me to whichever version of the index document is optimal for my user agent". Choosing a document based on information other than the URI is commonplace elsewhere, such as a view of a user's page on a social networking site that depends on authorization: whether you're not logged in, logged in as a stranger, logged in as a friend of a friend, logged in as a friend, or logged in as the user himself.

Since a human user using the UA may not know that the different versions exist

Each document would link to the other. I see "Full-size version" and "Mobile version" links in plenty of web sites.

a sensible approach is to provide a very minimal landing page that links them to the two different documents. Then the human user can choose which one to view, keeping in mind the trade-offs of each.

How many web sites actually have such a landing page in practice, as opposed to a "redirect me to the document most appropriate for my class of user agent" page? And if you arrive at a document from a URI distributed outside the site itself, such as an inbound link from another web site or a link from another Internet application altogether such as mail or IRC, how is the site supposed to know whether you want to view a document appropriate for full-size user agents or a document appropriate for limited user agents? Is it even possible for a canonical URI to encompass all such documents in such a case?

What you describe are actually two separate documents, and thus each should have its own unique URI.

For example, the URIs could be http://example.com/home and http://example.com/m for the long and short documents respectively. Then the URI http://example.com/ would mean "redirect me to whichever version of the index document is optimal for my user agent". Choosing a document based on information other than the URI is commonplace elsewhere, such as a view of a user's page on a social networking site that depends on authorization: whether you're not logged in, logged in as a stranger, logged in as a friend of a friend, logged in as a friend, or logged in as the user himself.

Since a human user using the UA may not know that the different versions exist

Each document would link to the other. I see "Full-size version" and "Mobile version" links in plenty of web sites.

a sensible approach is to provide a very minimal landing page that links them to the two different documents. Then the human user can choose which one to view, keeping in mind the trade-offs of each.

How many web sites actually have such a landing page in practice, as opposed to a "redirect me to the document most appropriate for my class of user agent" page? And if you arrive at a document from a URI distributed outside the site itself, such as an inbound link from another web site or a link from another Internet application altogether such as mail or IRC, how is the site supposed to know whether you want to view a document appropriate for full-size user agents or a document appropriate for limited user agents? Is it even possible for a canonical URI to encompass all such documents in such a case?

Simple HTML: <a href="http:/example.com">Example</a> yields: Example.

That would hurt. Lets say you type in http://example.com/ in your browser, but the DNS server responsible for example.com is down. Thus the recursive resolver will never get the reply it needs and will time out and send a server error message back to the browser.

You're right. I run my own recursive resolver, and was thinking more along the links of avoiding only the specific server that originated the error. Since most people depend on their ISP for that function they only have the ISP's server to blame, no matter where the error originates. Short of requiring DNS servers to sign their error messages, there is no way to prove that the ISP was or was not responsible the failure to resolve the domain.

On the bright side, at least with DNSSEC they can't outright lie to you and claim NXDOMAIN when the domain actually exists.

stop abusing relative domain references when the full domain is known.

When was the last time you saw a URL with a trailing dot in the hostname? Using relative names with the expectation of them being treated as a full domain name is in fact the norm. But I agree it might be something we should try to change.

The browser can also help by always showing the full domain name returned by the resolver, and not just the portion entered by the user.

Agreed.

It wouldn't hurt to make "server failed" messages more painful, either—for example, whenever a server reports an internal failure of that sort, the resolver could refuse to use it for the next five minutes or so

That would hurt. Lets say you type in http://example.com/ in your browser, but the DNS server responsible for example.com is down. Thus the recursive resolver will never get the reply it needs and will time out and send a server error message back to the browser. If the browser stops using the recursive resolver in that case it will quickly run out of recursive resolvers and will thus be unable to resolve any domain name.

In effect you have made a system that is trivial to perform a DoS attack against.

You need a webserver for your domain which has a http://example.com/.well-known/host-meta file which points to an URL where the public-key-information can be queried.

So, if you have only an e-mail domain (e.g., a domain purchased solely to allow you to have your own GMail domain), then you can't use this service.

There are also a lot of people who have e-mail through an ISP which either won't do this at all, or would screw it up in some way that your login wouldn't work (Verizon, Comcast, etc.). I don't even know if Google would support this, as all HTTP requests to gmail.com seem to redirect to google.com/mail.

You need:

* the normal stuff to handle email:
- like a domain
- like an incoming/outgoing mail server, probably spamfiltering
- probably a IMAP/POP-server
- or maybe a webserver for webmail
- and the a webmail program

If you want to implement the Verified Email Protocol, this adds:

You need a webserver for your domain which has a http://example.com/.well-known/host-meta file which points to an URL where the public-key-information can be queried.

That is all this adds.

If you want to set this up for users, you probably would want an extra settings page in the webmail-app for setting up the public key.

"You may have heard of recent incidents involving compromised accounts on major Web sites, including Twitter. To strengthen the integrity of our systems and accounts and ensure compliance with Federal cybersecurity laws and recommendations, we at Twitter are now instituting a stronger authentication system. In order to continue posting after 11:59:59 PM 2011-07-04, we require your full name, address, Social Security Number (SSN), Date of Birth (DOB), and valid US credit card information. Click Here to verify and secure your account.

We hope you continue to use Twitter.

--The Management"

Insert logo, sidebars, random tips about hashtag and @ usage, and cute birdies as needed.

because if you don't pay for it, normally you tend to abuse it. But if you pay for it, why would they need to mess with your traffic?

Usually when I'm on public wifi (even if paid for), I tend to put downloads on a slow trickle, overnight if possible. Ye olde wget is awesome for that:
wget --limit-rate=20k http://www.example.com/bigfile
will limit the download speed to 20KB/s. All platforms have wget available.

(By the way, why does Slashdot make text URLs into hyperlinks even in code sections?)

I never understood why people (especially on /.) would click on a shortened url. Even though my machine is pretty resistant to exploits and malware, blindly following links seems a bit like roulette to me. Not to mention the possibilites of the url leading to child porn or 2girls, goatse etc. what has been seen cannot be unseen.

Every link is blind. Does http://example.com/totally_safe_for_work.gif point to a gif exploit, a jpg exploit, an html page, a redirect to a goatse png, or any number of other things? Remember when whitehouse.com used to be the "OMG it looks like a safe link!" site? I thank the early-adopters who click on links before us and warn others of naughty links.

So, there probably would be no way to make ftp://example.com and http://example.com/ be on different machines without people having problems accessing one of those two services (since both can be accessed by a web browser).
Yep, much more usable than NAT.

Ok, fair point. But who seriously bothers running anonymous FTP servers these days rather than simply making the files available through a web server?

Also, as anyone involved in security will tell you, obscurity provides very limited security - if your security relies on obscuring your network structure then you're screwed already; and if it doesn't then there is no problem with revealing it.

Really, why should someone outside the network know that the HTTP and FTP services run on different machines?

I take the attitude that whilst there are few reasons why people outside your network need to know these specifics, there isn't really any harm in them knowing and avoiding NAT makes the network far less complex and problems easier to debug. Much the same as people blocking ICMP echo requests and traceroutes because they think it increases their security - in actual fact it does very little for the network security and makes it a hell of a lot harder (sometimes impossible) to debug networking problems; and at worst these idiots block *all* ICMP, not just echo requests, which leads to all sorts of difficult-to-debug unreliability of the network..

So, there probably would be no way to make ftp://example.com and http://example.com/ be on different machines without people having problems accessing one of those two services (since both can be accessed by a web browser).
Yep, much more usable than NAT.

Ok, fair point. But who seriously bothers running anonymous FTP servers these days rather than simply making the files available through a web server?

Also, as anyone involved in security will tell you, obscurity provides very limited security - if your security relies on obscuring your network structure then you're screwed already; and if it doesn't then there is no problem with revealing it.

Really, why should someone outside the network know that the HTTP and FTP services run on different machines?

I take the attitude that whilst there are few reasons why people outside your network need to know these specifics, there isn't really any harm in them knowing and avoiding NAT makes the network far less complex and problems easier to debug. Much the same as people blocking ICMP echo requests and traceroutes because they think it increases their security - in actual fact it does very little for the network security and makes it a hell of a lot harder (sometimes impossible) to debug networking problems; and at worst these idiots block *all* ICMP, not just echo requests, which leads to all sorts of difficult-to-debug unreliability of the network..

That said, their are ISPs that do native v6, so you can just switch to one of them (I have a native v6 connection from EntaNet).

I probably could, but I really like my current 200/200/80/80 FTTH connection for ~29EUR/month.

Well now, that rather depends on what software you're talking about. Web browsers generally don't support it. SIP UAs almost universally do, as do XMPP UAs. MTAs tend to rely on MX records instead, but they are simply an ungenericised record along the same lines.

So, there probably would be no way to make ftp://example.com and http://example.com/ be on different machines without people having problems accessing one of those two services (since both can be accessed by a web browser).
Yep, much more usable than NAT.

Also, as anyone involved in security will tell you, obscurity provides very limited security - if your security relies on obscuring your network structure then you're screwed already; and if it doesn't then there is no problem with revealing it.

However, multi layer security is better than single layer. One of those layers is hiding the network structure. If someone does break in somehow, it will be harder for them to access the information because they will have to find out what's connected to what first, instead of knowing not only that, but all of the IP addresses of all of the machines in the network.

Just like there is no reason for the power company to know what and how many devices I am using (as long as the total power consumption is less that the maximum capacity of the cable), I think that there is no reason for anyone outside my network to know what and how many devices are in it, as long as the packets coming out of it are like they expect. Really, why should someone outside the network know that the HTTP and FTP services run on different machines?

With NAT I can:
1. Load balance two ISPs without their cooperation (or knowledge that I am doing it).
1a. Set up a backup connection so that it is used when the primary is down. No need to reconfigure anything, well, other than the router NATing to a different IP and sending the packets out of a different interface. Without NAT, all computers in the network would have to have 3 different IPs (ISP1, ISP2, LAN) and a way of detecting when the connection fails, so they know which source IP to put in the packets. With NAT, they send the packets as usual and it's the router's job to select a working connection.
2. Have transparent proxies (well, at least for HTTP). Packet going for example.com:90 gets DNATed to proxy:8080.
3. Confuse a server so that two computers appear as one - for logging, access control or whatever.
4. Move services between machines as I wish and only have to update the router, which, unlike DNS (with or without the SRV RRs, which are not supported my a lot of software), is instantaneous.

That said, their are ISPs that do native v6, so you can just switch to one of them (I have a native v6 connection from EntaNet).

I probably could, but I really like my current 200/200/80/80 FTTH connection for ~29EUR/month.

Well now, that rather depends on what software you're talking about. Web browsers generally don't support it. SIP UAs almost universally do, as do XMPP UAs. MTAs tend to rely on MX records instead, but they are simply an ungenericised record along the same lines.

So, there probably would be no way to make ftp://example.com and http://example.com/ be on different machines without people having problems accessing one of those two services (since both can be accessed by a web browser).
Yep, much more usable than NAT.

Also, as anyone involved in security will tell you, obscurity provides very limited security - if your security relies on obscuring your network structure then you're screwed already; and if it doesn't then there is no problem with revealing it.

However, multi layer security is better than single layer. One of those layers is hiding the network structure. If someone does break in somehow, it will be harder for them to access the information because they will have to find out what's connected to what first, instead of knowing not only that, but all of the IP addresses of all of the machines in the network.

Just like there is no reason for the power company to know what and how many devices I am using (as long as the total power consumption is less that the maximum capacity of the cable), I think that there is no reason for anyone outside my network to know what and how many devices are in it, as long as the packets coming out of it are like they expect. Really, why should someone outside the network know that the HTTP and FTP services run on different machines?

With NAT I can:
1. Load balance two ISPs without their cooperation (or knowledge that I am doing it).
1a. Set up a backup connection so that it is used when the primary is down. No need to reconfigure anything, well, other than the router NATing to a different IP and sending the packets out of a different interface. Without NAT, all computers in the network would have to have 3 different IPs (ISP1, ISP2, LAN) and a way of detecting when the connection fails, so they know which source IP to put in the packets. With NAT, they send the packets as usual and it's the router's job to select a working connection.
2. Have transparent proxies (well, at least for HTTP). Packet going for example.com:90 gets DNATed to proxy:8080.
3. Confuse a server so that two computers appear as one - for logging, access control or whatever.
4. Move services between machines as I wish and only have to update the router, which, unlike DNS (with or without the SRV RRs, which are not supported my a lot of software), is instantaneous.

Lets not forget the people who type their search query in the URL line, who are completely dependent on search plugins.

I've seen people go through the drill of going TO google and typing http://example.com/ . I've been setting up brand new sites, on new hostnames, and had to start a remote session to their machine to see how they were screwing it up. No, it doesn't work if Google doesn't know about the site. :) Of course there are plenty of people who don't know exactly what a slash or forward slash are. They'll put a dash, underscore, backslash, or type out slash. I guess it keeps newbies out of slashdot.org, or http;--/.ohrg , as it may be.

4) Run on multiple ports. URLs like https://example.com:23456/index.html. This absolutely confuses the heck out of some firewall monkeys.

Google results typically find three kinds of content

• Real Stuff related to what you're looking for,
• Astroturfed content spam posted by people trying to sell stuff, attract advertising views, or manipulate link ratings, and
• Unrelated stuff collected by accident.

Google's quality regarding Real Stuff is as high as ever, and their ratios of Real Stuff and Unrelated Stuff are still pretty good, though the Web may have a higher noise-to-signal ratio than it used to. The problems I've seen have been the radical increase in content spam by people whose business models consist of littering the web and monetizing it, and it's an arms race between them and Google to keep it under control. It's probably worst with medications (especially if you're looking for drug interactions between Medicine A and Medicine B, which tends to lead to sites selling both of them, even though neither one of them is Medicine V where you're expecting mostly spam...), but I've even gotten content-farm trash when looking for design information on electronic circuits.

A couple of things have surprised me - it sometimes seems like Google must be collecting data that's generated in real time, given the number of results I've seen like http://www.example.com/keywordA-keywordB-keywordC/article.html, where I wouldn't have expected that combination to be frequent enough to pre-stage it all. Also, there are a lot of sites that seem to basically be imitation search engines, where if you're looking for a topic, they'll have a page that's a pointer to a bunch of links about the content, rather than the content itself; it's almost as if they randomly picked some Google results and fed them back to Google, except that many of them aren't actually useful. Is it possible that they just keep a bunch of keywords around, and robogenerate dynamic pages when Google crawls their site? Music lyrics are really a minefield for this kind of thing; it seems very few sites have actual lyrics, even if they're offering to sell you ringtones for songs.

Good luck to Google downrating most of this tripe.

I know you're joking (and it's funny), but I'm inclined to jump to the defense of using regex to solve problems - take this example:

Requirement: Long URLs must have a slash between the domain and the path component. For example, http://example.com?query=parameter is invalid, and instead should be formatted as http://example.com/?query=parameter

I challenge you to find a non-regex solution as nice as this:

url = url.replaceFirst('(://[^/]*)\\?','$1/?');

Java, in this case - but that's another beauty - you could implement the same pattern in any language that supports regex. I love it...I do love it so.

I know you're joking (and it's funny), but I'm inclined to jump to the defense of using regex to solve problems - take this example:

Requirement: Long URLs must have a slash between the domain and the path component. For example, http://example.com?query=parameter is invalid, and instead should be formatted as http://example.com/?query=parameter

I challenge you to find a non-regex solution as nice as this:

url = url.replaceFirst('(://[^/]*)\\?','$1/?');

Java, in this case - but that's another beauty - you could implement the same pattern in any language that supports regex. I love it...I do love it so.

I wrote that when replying to other comments, but basically NAT allows me to make http://example.com/ and ftp://example.com actually go to different servers. Or conversely, I could make example.com:80 and example1.com:80 go to different ports on the same server. Also, NAT allows me to have transparent proxies. Some torrent sites note my IP when I log in and only allow connections from it, now I can log in from my main PC and have the torrents on an other PC. Without NAT I would have to log in from the torrent PC (or set up some sort of proxy on it and then use it).

I wrote that when replying to other comments, but basically NAT allows me to make http://example.com/ and ftp://example.com actually go to different servers. Or conversely, I could make example.com:80 and example1.com:80 go to different ports on the same server. Also, NAT allows me to have transparent proxies. Some torrent sites note my IP when I log in and only allow connections from it, now I can log in from my main PC and have the torrents on an other PC. Without NAT I would have to log in from the torrent PC (or set up some sort of proxy on it and then use it).

It's not a detection problem. The URL is being detected correctly, and it's a properly formed URL, so no, I haven't seen anything that legitimately needs to be blacklisted.

When a man page contains a URL, that URL is expected to be a valid URL, not a redirect. Thus, every man page that contains http://www.example.com/ should be considered buggy, and those pages should be changed to use a different, valid URL. From my perspective, it's as simple as that.

And that was my whole point. This change completely breaks the use of the domain in documentation as an example, making it no longer serve its intended purpose..

The test suite of Darcs needs a domain that doesn't exist. It used to use example.com for that purpose, which now fails:

Sat Jan 29 16:18:53 CET 2011 Ganesh Sittampalam

    * switch test to use a URL we can make sure will fail

    Seems like the behaviour of http://example.com/ changed to start serving

    pages at all URLs...

".example" is recommended for use in documentation or as examples.
".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid.

Guess they should read the rfc.

If you need a dns entry that doesn't exist, pick one that you are authoritative for and make sure it doesn't exist.

That's exactly what they did:

-not darcs get http://example.com/foo
+not darcs get http://darcs.net/nonexistent

Sat Jan 29 16:18:53 CET 2011 Ganesh Sittampalam
* switch test to use a URL we can make sure will fail
Seems like the behaviour of http://example.com/ changed to start serving
pages at all URLs...

Alternatively you could use http://example.com/ instead of making up your own stuff which serves no purpose whatsoever.

    To further this...

    I had a quick look at the CIA world factbook for Rwanda. 70% literacy rate. So 3 in 10 people won't know how to spell their own names, much less how to go to http://refugee-registry.example.com./ Once there, they won't be able to read what it says.

    There are 11 million people in the country. There are 2.9 million cell phones in use. There are 0.455 million Internet users. So, it would be fair to say that most of the population has had no exposure to the Internet. It would also be fair to say that if roaming, long distance tolls, and number portability were not a concern, cell phones would be the best method of letting people find each other.

    Cell phones are a world wide network. You can call from any remote area that has phone service, to any other remote area that has phone service, regardless of how far apart those remote areas are. If a refugee were given a phone, and their old phone number assigned to it, and they were able to make calls to any of their friends and family, they have a fighting chance of finding them.

    Since that's not the way it works, the subject of the beginning of the article, now living in Denmark, can't get a replacement phone with her old number (if she had one). She likely can't afford the long distance calls to friends and family, who themselves likely don't have phones with the same number, if they've re-established themselves elsewhere. If they've brought their phone to another country, they likely can't afford to use it, being that it would now be doing international roaming, assuming the phone is a GSM phone.

Perhaps http://oppressive-regime.example.org/ would like to collect a list of their users who are logged into http://controversial-website.example.com/?

I don't think "oppressive-regime.example.org" would bother with a cheap exploit like this.
The fact of the matter is that since they're the regime, they control the network, and are already sniffing your packets.

I already knew this, but now it makes me think why not we instead use HTTP redirection strategy? That is, say the client hits the server directly at http://example.com/very-large-file.zip, the server detects the client's IP and permanently redirects it to http://[location].static.example.com/very-large-file.zip, where static.example.com is a subdomain managed by Akamai and [location].static.example.com always resolves to CDN node nearest to the specified location regardless of the client's IP address.

I already knew this, but now it makes me think why not we instead use HTTP redirection strategy? That is, say the client hits the server directly at http://example.com/very-large-file.zip, the server detects the client's IP and permanently redirects it to http://[location].static.example.com/very-large-file.zip, where static.example.com is a subdomain managed by Akamai and [location].static.example.com always resolves to CDN node nearest to the specified location regardless of the client's IP address.

I normally don't go to URL shortener links at all, having long ago seen how easy they are to hid the real URL of suspicious sites. Also, I've been using Safari for years, and although Firefox is installed it's my preferred browser. Normally I have the download window and the activity window active on the right side of my desktop. The Activity window in particular is very handy for monitoring any and all surfing activity.

Similarly, I have been a long-time user of Little Snitch to monitor and authorize/deauthorize outgoing connections, with the network activity window always showing upon outgoing network activity. I suspected one, or both, of these tools would be useful.

Little Snitch, as expected, shows the network activity as a fairly constant level of network activity, but since it's an authorized outgoing connection (your web browser, naturally, has to be allowed to make connections to the usual internet ports like 80, etc, or no browsing for you) there isn't much that would really seem unusual. Many requests and deliveries of data are of course visible, but this is relatively normal and probably would not really alert anyone; for example it is similar to what you would see with a streaming server delivering content on a page. It's there, but it's not obvious something nefarious is going on unless you were really paying attention, and there's really no reason to be, since it's a standard browser operation, more or less.

Safari's Activity window, however, reveals the activity quite obviously. In a few moments using the sample page outlined in the original article, you see a huge amount of requests to the target url. A normal webpage might have up to 100 or even 200 different components, but not a constant stream that gets to 100 in a few seconds, and keeps going. The urls are fairly obvious as well, taking the form of:
http://www.example.com/?v=1292889926999 ...{continuous stream of ... example/com/?v= [some incremental number]} ...
http://www.example.com/?v=1292889877790

The webpage does not fully load, but the stream continues until you close the page { [Command-W] or mouse click on the close button }

With the Activity Window open you should be able to monitor and react to being an unwitting party to the DDoS.

I normally don't go to URL shortener links at all, having long ago seen how easy they are to hid the real URL of suspicious sites. Also, I've been using Safari for years, and although Firefox is installed it's my preferred browser. Normally I have the download window and the activity window active on the right side of my desktop. The Activity window in particular is very handy for monitoring any and all surfing activity.

Similarly, I have been a long-time user of Little Snitch to monitor and authorize/deauthorize outgoing connections, with the network activity window always showing upon outgoing network activity. I suspected one, or both, of these tools would be useful.

Little Snitch, as expected, shows the network activity as a fairly constant level of network activity, but since it's an authorized outgoing connection (your web browser, naturally, has to be allowed to make connections to the usual internet ports like 80, etc, or no browsing for you) there isn't much that would really seem unusual. Many requests and deliveries of data are of course visible, but this is relatively normal and probably would not really alert anyone; for example it is similar to what you would see with a streaming server delivering content on a page. It's there, but it's not obvious something nefarious is going on unless you were really paying attention, and there's really no reason to be, since it's a standard browser operation, more or less.

Safari's Activity window, however, reveals the activity quite obviously. In a few moments using the sample page outlined in the original article, you see a huge amount of requests to the target url. A normal webpage might have up to 100 or even 200 different components, but not a constant stream that gets to 100 in a few seconds, and keeps going. The urls are fairly obvious as well, taking the form of:
http://www.example.com/?v=1292889926999 ...{continuous stream of ... example/com/?v= [some incremental number]} ...
http://www.example.com/?v=1292889877790

The webpage does not fully load, but the stream continues until you close the page { [Command-W] or mouse click on the close button }

With the Activity Window open you should be able to monitor and react to being an unwitting party to the DDoS.

Before payment is accepted, you have access to view a notice on the package: "By purchasing this product, you agree to the standard form contract at http://www.example.com/eula/productname [example.com]."

First of all, normal boxed software doesn't actually have that sort of notice written on it.

Second, it's still irrelevant because when you buy an item the contract is between you and the retailer, not you and the copyright holder. In order to create an actual valid license agreement, the store would have to be acting as the legal agent of the copyright holder or something.

USC Title 17 section 117(a)

The opinion of a U.S. court in the bnetd case was that for any computer program primarily designed to connect to a network service, the end user waives any rights under section 117 as a condition of accessing the service.

I've always held that UCC Article 2 says it was a sale if they can't show an explicit agreement otherwise made before payment was accepted

Before payment is accepted, you have access to view a notice on the package: "By purchasing this product, you agree to the standard form contract at http://www.example.com/eula/productname." What does the UCC say that rules out notices on product packages that include the EULA by reference?

Well one answer is to start thinking of the port as part of the address. I have given this some thought. The major suckage of this scheme will be that there are no longer "well known" ports.

If you use carrier grade NAT you might as well assign all the addresses via DHCP.

You define some new DHCP options that passes a group of ports to the client. These are the ports the NAT engine will be forwarding to that host.

The DHCP client will have to be configured to know about the services the machine will host. You would know that your ISP was going to give you 10 ports and so you would just configure the client with a map that says my first port will be http, my second port will be smtp, my third ftp and so on. The client sends this information back in the DHCP inform. The DHCP server will then create DNS srv records with the service name and the port number as the data.

Once the DHCP negotiate is finished the operating system on the client restarts the services binding them to the correct ports received in the DHCP options.

Browsers and new apps will need to be updated to check the srv records for the ports to append to the url. Users will have to learn to enter urls like http://example.com:7634/ into legacy applications.

It could work for the most part though, without breaking legacy networks and applications. Kludgey sure, but better than nothing.

Read the post you're replying to! That's all changed since 1.5. Now SVN knows when you branched and what you've already merged together.

Read about it here.

For most branching, the command would be a simple 'svn merge http://svn.example.com/repos/calc/trunk' from within the branch. The most complicated part is specifying the location of the branch to merge from (trunk in this case).

1.5 did wonders for SVN.

Why not just aim wget right at /dev/null?

No need to muck about making actual files. Also you would be better served grabbing an image dir or the largest single file you can find them serving.

The following would be an example:

wget -O - -o /dev/null http://example.com/bigfile.tgz > /dev/null 2>&1

Wasn't there a recent Slashdot article about using existing tools rather than building your own?

Rather than writing your own crawler, why not use an existing one -- no Python required:

wget -r -p -l 0 http://example.com/