Slashdot Mirror

What I wonder is why the designers of DNS put the name in reverse?

Berners-Lee regrets that as well, from back in 2000...

I have to say that now I regret that the syntax is so clumsy. I would like http://www.example.com/foo/bar/baz to be just written http:com/example/foo/bar/baz where the client would figure out that www.example.com existed and was the server to contact. But it is too late now. It turned out the shorthand "//www.example.com/foo/bar/baz" is rarely used and so we could dispense with the "//".

Uh, simply add that self-signed cert once.
Someone in IT will do it.

Then another time for the website, and another one for the IM server, another time for the VPN, and a couple times more when servers get replaced...

Setting up a CA is a long term solution that only needs to be done once. You can then generate a new cert that will be recognized as valid by somebody in another country.

Setting up your own CA doesn't fix the problems you mentioned (random access point fud).

Yes it does.

If you're lucky:
You go to https://example.com./ It uses a self-signed cert. You accept it, connect to the right server. All is good.

If you're not:
You go to https://example.com./ It uses a self-signed cert. The man in the middle examines your cert, makes another self-signed one with the same details, and presents that to you. You accept it. Connect to the man in the middle who then connect to your server. You read your mail, administrate your servers and so on, while somebody is quietly logging all that data.

With a CA, your cert would be signed by the company's cert. Your company can sign certs with its key, but some random guy running an AP for nefarious purposes can't. The best he can do is to make a self-signed cert with your company's details, but you're not stupid enough to ignore that, are you?

Uh, simply add that self-signed cert once.
Someone in IT will do it.

Then another time for the website, and another one for the IM server, another time for the VPN, and a couple times more when servers get replaced...

Setting up a CA is a long term solution that only needs to be done once. You can then generate a new cert that will be recognized as valid by somebody in another country.

Setting up your own CA doesn't fix the problems you mentioned (random access point fud).

Yes it does.

If you're lucky:
You go to https://example.com./ It uses a self-signed cert. You accept it, connect to the right server. All is good.

If you're not:
You go to https://example.com./ It uses a self-signed cert. The man in the middle examines your cert, makes another self-signed one with the same details, and presents that to you. You accept it. Connect to the man in the middle who then connect to your server. You read your mail, administrate your servers and so on, while somebody is quietly logging all that data.

With a CA, your cert would be signed by the company's cert. Your company can sign certs with its key, but some random guy running an AP for nefarious purposes can't. The best he can do is to make a self-signed cert with your company's details, but you're not stupid enough to ignore that, are you?

To be precise: Obama voted for all amendments opposing telecom immunity and against all of those supporting it. He voted for an omnibus bill at the end of the process that included telecom immunity but also included too many other measures for it to be fair to suggest any voter was "supporting" telecom immunity specifically.

Stories Slash Boxes Comments Slashdot Search News for nerds, stuff that matters * squiggleslash * Help & Preferences * Subscription * Firehose * Journal * Tags * Bookmarks * Logout * Customize Sections * Main * Apple * AskSlashdot * Book Reviews * Developers * Games * Hardware * IT * Index * Interviews * Linux * Mobile * Politics * Science * Technology * YRO Site Info * FAQ * Bugs * Code Stories * Old Stories * Old Polls * Hall of Fame * Submit Story Slow Down Cowboy! Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment. It's been 2 minutes since you last successfully posted a comment Chances are, you're behind a firewall or proxy, or clicked the Back button to accidentally reuse a form. Please try again. If the problem persists, and all other options have been tried, contact the site administrator. Reply to: Obama will not allow it * Obama will not allow it (Score:2, Insightful) by Anonymous Coward on 2009-09-18 18:57 (#29472513) Obama initially opposed the retroactive immunity bill, but switched his stance before the vote (and received contributions from the telcos for it, just like all the flip-flopping congressmen did). Having been bought, he won't risk buring any important bridges by biting the hand that fed him. Expect him to veto this bill (if it ever gets to his desk, which it probably won't, for the same reason given above). Reply to This Post Comment Preview Comment * Re:Obama will not allow it (Score:?) by squiggleslash (241428) on 2009-09-18 21:07 Homepage Journal To be precise: Obama voted for all amendments opposing telecom immunity and against all of those supporting it. He voted for an omnibus bill at the end of the process that included telecom immunity but also included too many other measures for it to be fair to suggest any voter was "supporting" telecom immunity specifically. -- My moved journal [livejournal.com] Edit Comment Name squiggleslash [ Log Out ] URL http://squiggleslash.livejournal.com/ Subject Comment

To be precise: Obama voted for all amendments opposing telecom immunity and against all of those supporting it. He voted for an omnibus bill at the end of the process that included telecom immunity but also included too many other measures for it to be fair to suggest any voter was "supporting" telecom immunity specifically.

Use the Preview Button! Check those URLs! No Karma Bonus No Subscriber Bonus Post Anonymously Allowed HTML

1. • URLs http://example.com/ will auto-link a URL Important Stuff * Please try to keep posts on topic. * Try to reply to other people's comments instead of starting new threads. * Read other people's messages before posting your own to avoid simply duplicating what has already been said. * Use a clear subject that describes what your message is about. * Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you are having a problem with accounts or comment posting, please yell for help. Search Sleep -- the most beautiful experience in life -- except drink. -- W.C. Fields All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the P

Ya, I caught that too. Get on a computer that can't browse to web sites, and then browse to http://mybank.example.com/ . Brilliant advice.

Microsoft is urging it's customers to 'carry out all computing activity from a standalone, hardened, and locked-down computer which is not plugged into any electrical outlet. Such a secure "computer" is known colloquially as the "typewriter"

    Ya, I caught that too. Get on a computer that can't browse to web sites, and then browse to http://mybank.example.com/ . Brilliant advice.

    Since 99.99[ad nauseum]% of the users wouldn't know a hardened secure computer (I'm pretty sure Windows is categorically eliminated), I'm not sure who they were suggesting that to. I have the only Linux virus I've ever seen, and it's safely tucked away on a floppy disk, in a concrete vault, underground, at a location that I forgot. :) Dammit, I knew I shouldn't have left the map in the vault. Most "bank customers" wouldn't keep a dedicated machine just to check their bank balance with. Hell, they'll call out on the company PBX and give their credit card information over the phone to any arbitrary business, with coworkers happily writing it down and the phone admin recording the call.

    Users are their own worst enemy. Hmm, wasn't there a story today saying something to that effect? I once found a bank card (w/ Visa logo) on top of an ATM. For some reason, they set it down and forgot it there. Brilliant. Since there was no one around to claim it, I called the bank. It took me an hour to convince them that I found it and that the card should be canceled. They "couldn't release any information on the card holder until...." I told them, "I'm holding the card in my hand. I guess that makes me the card holder." Finally, they told me "Oh, just bring it to a branch on Monday", at which point they finally canceled it. I knew the people at the branch, so they knew I was legitimate, and they confirmed that it hadn't been canceled. The account hadn't even been noted that I called in to report it. What if I wasn't a nice guy? I would have had 2 days or more to charge anything I wanted. If you can't get a person to maintain control over a little physical piece of plastic, why should you they think that they're going to do any better elsewhere?

I never thought it had to do with bandwidth. I saw URL shorteners become popular shortly after everyone started putting the title of the page into the URL for search engine optimization. It used to be that anyone's blog post would be like http://example.com/blog/2009/09/19 or http://example.com/blog.php?story=urls but now it's like http://example.org/blog/2009/08/19/why-url-shorteners-are-not-a-good-idea . Even Slashdot went this route--one of the URLs for this story is http://tech.slashdot.org/story/09/08/19/120206/URL-Shortener-trim-To-Go-Community-Owned-Open-Source Note that the old style address, http://tech.slashdot.org/story/09/08/19/120206 , also works. The rest is strictly for SEO. (Making it human readable is a nice side benefit, but SEO is the reason.)

I never thought it had to do with bandwidth. I saw URL shorteners become popular shortly after everyone started putting the title of the page into the URL for search engine optimization. It used to be that anyone's blog post would be like http://example.com/blog/2009/09/19 or http://example.com/blog.php?story=urls but now it's like http://example.org/blog/2009/08/19/why-url-shorteners-are-not-a-good-idea . Even Slashdot went this route--one of the URLs for this story is http://tech.slashdot.org/story/09/08/19/120206/URL-Shortener-trim-To-Go-Community-Owned-Open-Source Note that the old style address, http://tech.slashdot.org/story/09/08/19/120206 , also works. The rest is strictly for SEO. (Making it human readable is a nice side benefit, but SEO is the reason.)

you know that link tag could have a description in html?

really long description with seo keywords

sidenote: I use tinyurl as to send link over SMS and to make something easy to remember http://tinyurl.com/higwaytraffic

A note on your example. Usually it is good to have a description of the content than just a hash.

A person can form an expectation from something like
http://tech.slashdot.org/tr.im_To_Go_Community-Owned
Against something with less sense:
http://tech.slashdot.org/article.pl?sid=09/08/19/120206

1. Twitter can fuck off

2. With a bit of sensible design, the sites can manage this functionality themselves.

Redirect short to long. No need for the tinyurl hack.
http://example.com/123
http://example.com/123/arguably-really-long-urls-stuffed-with-keywords-are-good-for-seo

A note on your example. Usually it is good to have a description of the content than just a hash.

A person can form an expectation from something like
http://tech.slashdot.org/tr.im_To_Go_Community-Owned
Against something with less sense:
http://tech.slashdot.org/article.pl?sid=09/08/19/120206

1. Twitter can fuck off

2. With a bit of sensible design, the sites can manage this functionality themselves.

Redirect short to long. No need for the tinyurl hack.
http://example.com/123
http://example.com/123/arguably-really-long-urls-stuffed-with-keywords-are-good-for-seo

1. Twitter can fuck off

2. With a bit of sensible design, the sites can manage this functionality themselves.

Redirect short to long. No need for the tinyurl hack.
http://example.com/123
http://example.com/123/arguably-really-long-urls-stuffed-with-keywords-are-good-for-seo

1. Twitter can fuck off

2. With a bit of sensible design, the sites can manage this functionality themselves.

Redirect short to long. No need for the tinyurl hack.
http://example.com/123
http://example.com/123/arguably-really-long-urls-stuffed-with-keywords-are-good-for-seo

You've sort of muddled the comparison, due to the differences in addressing schemes.

Typing in "example" and being redirected to http://www.example.com/ is more like dialing 555-555-5555 and the country code being inferred, so you actually call 1-555-555-5555 (in the US, since I'm an insensitive clod). You might have meant to call China, but seriously, you probably didn't.

Further still, what IE is doing is essentially connecting you to your preferred operator (Debbie?) whenever "the number you dialed is no longer in service."

How about if the contract says: "You also agree to the terms at http://somedomain.example.com/terms.php?t=3528905325 incorporated herein by reference." ?

Where, of course, the terms at the URL are constantly being changed. And you only know what they originally said, if you printed them and kept a printout (which 90% of people won't do) ?

Oh yes, and every 6 months they'll send you a letter by post that says "The terms of service at this URL have been updated. By continuing to use the service, you agree to the changes. Reply to this message or call us to cancel service if you do not agree to the new terms."

But they won't tell you what the changes are, or even keep record of what/when they changed things. So you have to manually print and re-read the entire thing every 6 months if you want to keep up on the updates.

The misappropriation is technically bad because it's done at the wrong protocol layer, and even when it works it's bad because it'll cause your browser to do something you didn't want.

Here's how DNS is supposed to work when it works, and how it's supposed to work when the lookup fails.

• You have some application that wants to set up a connection to example.com using some protocol.
• The application sends a query to the DNS servers to find out where example.com lives, gets told "192.9.200.1".
• The application sets up a TCP session or UDP query/response to 192.9.200.1, yay!
• But if the query fails, because you typed exampel.com instead, or because the site no longer exists, DNS tells your application "Not Found".
• The application does something application-appropriate in response -
  • If your application was sending email, your mail server can tell your mail client that it couldn't deliver the mail.
  • If your application was receiving email, it might have been doing the lookup to see if the alleged sender existed; failure says it's a spammer.
  • If you were doing ssh, it tells you it couldn't set up a connection.
  • If your application was an Instant Messaging client, it's unlikely that they'll do anything good for you.
  • If it was a modern browser looking up Port 80, it tries tricks like adding a www or a .com, and if those also fail it may feed your query into your favorite search engine.
  • If it was a browser looking up Port 443 https:, it tells you that your connection failed but doesn't try feeding your possibly sensitive information to a random search engine.

Now look at what happens if your DNS server lies to your application by giving it some other IP address instead of the correct failure message, like 68.87.60.144.

• If you're doing ssh, your ssh client will try to set up a connection to a server you have no ability to log in to. If you're lucky, the server won't be running an ssh server application; if you're unlucky, it'll maliciously try to steal your login information.
• If you're sending email, and that system has an email server on it, it might reject your email with a confusing error message (unknown user fred@exampel.com), or it might pretend to accept your message but discard it silently with the rest of the spam, so you don't know it got lost.
• If you're validating received email, it tells you that example.com was an existing mail server, so you're more likely to accept that spamgram.
• If you're trying to make a secure connection to https://example.com/ and Comcast is listening on port 443, you might pass it sensitive information, and at best there's nothing good that can happen from attempting the connection vs. many bad things.
• ... don't profit ...
• Finally, when we get to the one case Comcast and its ilk _were_ thinking of, instead of your browser sending your incorrect URL to the search engine you like or generating a failure message if that's what you prefer, Comcast sends your URL to _its_ search engine in hopes of making a PROFIT on advertising to you.

If you login then of course you need a cookie. And using them for stats within one site is not much different to using IP addresses.

While I agree that there a significant benefit in using login cookies, they are not remotely âoenecessaryâ. Java-based servers have had a fantastic technique using a little-known part of the URI shceme where every segment can have parameters. It looks like this:

http://www.example.com/app;sessionid=ABC123DEF456/<whatever&gt;

This allows cookie-like storage in a way that isn't able to be tracked across multiple domains.

great, so every time someone follows a link from your site (or you include an external image) their session key is transmitted via the referer header...

An extended version of Firefox (or wget or curl) will cheerfully tell you that they're fetching fonts based on a CSS style from http://authorizedcustomer.example.com/

Back to the old web axiom: if you don't want to distribute it, don't publish it. It is impossible, in theory and in practice, to allow someone to simultaneously have and not have a file.

A vulnerability to opening an Excel sheet in IE? How many people do that on a regular basis? How many EVER do it? I dont think I can remember having ever tried to nor needing to. How is this newsworthy?

All it takes is a link to http://example.com/NUDE_PICS_CELEBNAME.xls

To be fair, I wouldn't say the Zope database (ZODB) is not a "solid foundation". It's one of the best parts of the Zope stack and, in 3 years of dozens of clients using it in Zenoss, Plone, and other apps, I've never had it corrupt or lose any data. It's a proper DB--ACID, MVCC, and all that--and you can even lop transactions off the storage to go back in time. Don't expect it to be a relational DB with the ad hoc query tools typical thereof; it's an object DB, with the aim of persisting graphs of Python objects transparently.

Now, if you aren't familiar with it, the ZODB can indeed seem opaque, but, just like any DB, there are tools to read and modify it. At the highest level, just stick "manage" after your Zenoss URL, e.g. http://example.com/zport/dmd/manage . That'll get you into the web-based Zope Management Interface (colloquially, "the ZMI"), where you can poke around at any object that someone's bothered to write a UI for. Deeper than that, you can connect to ZEO (a server that brokers access to the ZODB over a socket) and mess with the object graph using normal Python. When you're done, "import transaction; transaction.commit()". (The Zenoss developers are probably trying to scare you away from such digging around in fear that you'll violate their objects' invariants and leave them a real mess to solve.)

Now, I don't say that Zope isn't scary; it has over 10 years of scary stored up in it. But the ZODB is a cuddly, loving part.

Cheers!

You bet it is !!! ;-))) Comment
#http://slashdot.org/

      Subject
      Re:It was to be expected__________________________
Use the Preview Button! Check those URLs!
      Customize Posting Preferences
  [ ] No Karma Bonus [ ] No Subscriber Bonus [ ] Post Anonymously

      [Plain Old Text_____________] Preview Submit
      Allowed HTML
     

1. • 
          

     URLs
           http://example.com/ will auto-link a URL
           Important Stuff ....

No, it's probably just frequent moderators (like myself) who have been too often bit by that particular UI flaw. Mis-clicks happen, and are an unwelcome side-effect of the overall much-improved moderation system. While I myself don't mod up the boo-boo posts, I sympathize with those who do and I _do_ mod up posts suggesting that this flaw be ironed out (hint hint). I've submitted the behavior as a bug and gotten no response as I'm sure others have. Maybe if cries for a fix start getting +5 we'll see work done to improve it.

Then again, Idle is still around (and broken) and I'm now some kind of dinosaur because they introduced a bug when changing the relationship jewels. But I digress.

The fix for this glitch is to add an "undo" link to the text displayed after a moderation is applied, like this:

Moderated 'Insightful' (undo). 4 points left.

If people think this would somehow be abused, it shouldn't be much more trouble to put a 20-second timer on it, since you're generally immediately aware that you mis-clicked the mod box, and it would have positive effects--we all could be reading and writing more topical posts if it weren't for the original "undo" post, and he wouldn't have lost all moderation in this thread because of a wandering cursor.

By publishing your URL as above? You are right. That is far too difficult for anybody, or any program, to use. You would have to save your favorite URLs in a table of bookmarks, or something; perhaps have an HTTP tag to encapsulate other URLs. Both of these ideas are clearly insane.

But guess what, if you understand NAT, you will NEVER have to upgrade past IPv4, because you will NEVER run out of IP Addresses. NAT is just the flexible approach to the problem that alot of people don't like because they don't understand.

Meanwhile, back in reality...

In abstract, NAT treats addr+port as a 48-bit address, so you're effectively trading ports for address. That means you only get one port 80 per public IP, so forget having more than one webserver (unless you can somehow get your visitors to go to http://www.example.com:8080/ ).

Incorrect. Had you said you only get one port 443 per public IP, I wouldn't have an issue, but HTTP traffic is easy to "route".

Every P2P app, every Skype, every game server, every random application you want to post has to have a unique port number across your entire network.

Can you really not see why that sucks in comparison to IPv6 which lets every machine on your LAN listen on the whole 2^16 port range as your firewall allows?

No argument from me here.

People who don't understand NAT at all like IPv6. People who only barely understand it, like yourself, think IPv4+NAT is spiffy. People who actually understand NAT and what it implies think that it needs to be taken out back and shot.

Every tool has a purpose. NAT is fine for a home, a small business, or an arbitrarily large network of strictly client computers.

But guess what, if you understand NAT, you will NEVER have to upgrade past IPv4, because you will NEVER run out of IP Addresses. NAT is just the flexible approach to the problem that alot of people don't like because they don't understand.

Meanwhile, back in reality...

In abstract, NAT treats addr+port as a 48-bit address, so you're effectively trading ports for address. That means you only get one port 80 per public IP, so forget having more than one webserver (unless you can somehow get your visitors to go to http://www.example.com:8080/ ). Every P2P app, every Skype, every game server, every random application you want to post has to have a unique port number across your entire network.

Can you really not see why that sucks in comparison to IPv6 which lets every machine on your LAN listen on the whole 2^16 port range as your firewall allows?

People who don't understand NAT at all like IPv6. People who only barely understand it, like yourself, think IPv4+NAT is spiffy. People who actually understand NAT and what it implies think that it needs to be taken out back and shot.

There is a page at http://example.com/ so clearly the domain exists. It resolves to an IP address and there is a web server listening there. The page does say that the name and the .org and .net versions "are not available for registration" but that could be considered to apply to all names that are already registered. Note that this differs from the reserved TLDs. These domains are reserved for use in documentation so that you can be sure that your examples never refer to something with some other meaning.

If you look up the registration data for example.com then you can discover that it is registered by IANA. Apparently the registration will expire 13-aug-2011 but I suspect that it will be renewed in time!

Okay!

ere is no way to get that info - e.g. a list of links on a page, each to a file of a different type. If it says http://example.com/file.doc, you know what to expect. Metadata sufficient to render file extensions obsolete would leave us with http://example.com/file, with no way to tell what it contains.

Such metadata already exists. You cannot depend on a URL to tell you the file type of the resulting downloaded object. It's too easy for a malicous site to use server-side URL mapping to redirect the apparent URL http://example.com/file.pdf to a server-side application that delivers up an executable, complete with HTTP header like
Content-Disposition:attachment;filename=file.pdf.exe

Which will trigger your browser to ask you where you'd like to save file.pdf.exe.

ere is no way to get that info - e.g. a list of links on a page, each to a file of a different type. If it says http://example.com/file.doc, you know what to expect. Metadata sufficient to render file extensions obsolete would leave us with http://example.com/file, with no way to tell what it contains.

Such metadata already exists. You cannot depend on a URL to tell you the file type of the resulting downloaded object. It's too easy for a malicous site to use server-side URL mapping to redirect the apparent URL http://example.com/file.pdf to a server-side application that delivers up an executable, complete with HTTP header like
Content-Disposition:attachment;filename=file.pdf.exe

Which will trigger your browser to ask you where you'd like to save file.pdf.exe.

ere is no way to get that info - e.g. a list of links on a page, each to a file of a different type. If it says http://example.com/file.doc, you know what to expect. Metadata sufficient to render file extensions obsolete would leave us with http://example.com/file, with no way to tell what it contains.

Such metadata already exists. You cannot depend on a URL to tell you the file type of the resulting downloaded object. It's too easy for a malicous site to use server-side URL mapping to redirect the apparent URL http://example.com/file.pdf to a server-side application that delivers up an executable, complete with HTTP header like
Content-Disposition:attachment;filename=file.pdf.exe

Which will trigger your browser to ask you where you'd like to save file.pdf.exe.

> Metadata sufficient to render file extensions obsolete would leave us with http://example.com/file, with no way to tell what it contains.

That's where MIME types come in to save you. While it is true that from the URL you can't tell the contents, the moment you do a "GET /file" the server will tell you the mime type (e.g. application/msword), and you can save that information in the file's meta data on your local filesystem (e.g. save it as file.doc).

You're right about implementation with respect to my "human-readable" comment - in practice it wouldn't be much different if there were a standard and ls could tell me the file type as well (kind of an integration of file and ls... which wouldn't be hard to hack together just to see what it would look like, but I digress).

But I still think there are situations in which there is no way to get that info - e.g. a list of links on a page, each to a file of a different type. If it says http://example.com/file.doc, you know what to expect. Metadata sufficient to render file extensions obsolete would leave us with http://example.com/file, with no way to tell what it contains.

There may be a quick fix to this situation that I'm overlooking, but my point remains - there are some times when it's just good to know from the filename what you'll be dealing with.

You're right about implementation with respect to my "human-readable" comment - in practice it wouldn't be much different if there were a standard and ls could tell me the file type as well (kind of an integration of file and ls... which wouldn't be hard to hack together just to see what it would look like, but I digress).

But I still think there are situations in which there is no way to get that info - e.g. a list of links on a page, each to a file of a different type. If it says http://example.com/file.doc, you know what to expect. Metadata sufficient to render file extensions obsolete would leave us with http://example.com/file, with no way to tell what it contains.

There may be a quick fix to this situation that I'm overlooking, but my point remains - there are some times when it's just good to know from the filename what you'll be dealing with.

Twitter with Wikipedia style moderation.

phew, smelly poop -- [citation needed]
@kv8vk that _was_ smelly poop. local news article: http://example.com/
@kgg7ig @kv8vk citation for smelly poop unreliable; local news site cited @kv8vk's twitter feed.

Swine flu fears spread via Twitter! http://example.com/ ZOMG
RT: @obojbaljsb @ljsndljsd @ksahbksjbdv Swine flu spread via Twitter! http://example.com/
RT: @hbs9yho3u @9jbkjsrg @jkbs8h3g @kbhjs89 @kjbiugs3e Swine flu spreads via Twitter!
Swine flu killed my friend via Twitter!
Fail Whale.

Swine flu fears spread via Twitter! http://example.com/ ZOMG
RT: @obojbaljsb @ljsndljsd @ksahbksjbdv Swine flu spread via Twitter! http://example.com/
RT: @hbs9yho3u @9jbkjsrg @jkbs8h3g @kbhjs89 @kjbiugs3e Swine flu spreads via Twitter!
Swine flu killed my friend via Twitter!
Fail Whale.

How would that work? BT might be a top-level CA but if I have an HTTPS-only site (say, https://www.example.com/ they still don't have my private key. Without that private key, they can't do anything to the data flowing between the web server and the end-user's browser without raising some flag or another.

They could create their own certificate for www.example.com in order to fool the end-user's browser, but that would involve a very intelligent proxy and would be incredibly (almost painfully) illegal, even in Britain I'm sure.

The problem is I don't feel like going to Google when I could just change
http://www.example.com/2009/3/foo.html
to
http://www.example.com/2009/3
which will DTRT in Wordpress AFAIK unless your server is broken.

The problem is I don't feel like going to Google when I could just change
http://www.example.com/2009/3/foo.html
to
http://www.example.com/2009/3
which will DTRT in Wordpress AFAIK unless your server is broken.

With mod-rewrite It can be simply http://example.com/1

There's a difference between "Hey, look! I got kiddie porn, check it out here", and "Look, these guys are censoring these sites: a, b, c, d. Seems that b is kiddie porn, c is hate speech and terrorist incitement, we're not quite sure a and d are anything except inconvenient".

The claims of a patent aren't completely isolated from the specification of a patent. While multiple cases warn against reading limitations from the specification into the claims, the terms in the claims often only take on meaning in light of what the specification teaches.

Take a look at figure 1 to get a sense of what Red Hat's inventor claims to have created: a command-line interpreter that can take something like "cat members | http://ws.example.com/ldap-lookup -name | xml://phone > member-phones" and produce meaningful results. That is, making the Unix command line a tool that seamlessly integrates services that are available remotely.

Does this help in interpreting the terms in the claim: "A system comprising: a command-line interpreter ("CLI") to obtain a text string describing a data processing pipeline ... process-launching logic to launch a plurality of child processes ... and remote service interaction logic to accept delimited data strings from a first of the plurality of child processes on a standard input" (simplified).

Well...CGI does not really have a command-line interpreter. You can run a CGI script from the command line, but Apache doesn't need to go through sh when it communicates with a CGI script. If you are running a CGI script from the command line, you're running it locally (even if you have remotely logged into another machine, you are still running it locally on that other machine). Thus, running the CGI script from the command line does not involve remote service interaction logic.

CGI is a poor example to use of something that might anticipate this patent. Perhaps a stronger argument could be made that the claimed invention was obvious in light of combining a command-line interpreter with wget or rsh, but given how long command-line interpreters have required additional programs to access remote services, an argument could be made that integrating the functionality directly into the command-line interpreters is, in fact, non-obvious.

This is a brilliant attempt at a failure.

It is one of the worst ideas I've ever heard of.

I used to work in adult entertainment. One of the big (BIG) things is availability to customers. Regardless if it's mainstream or not, most customers (readers here excluded) are barely functional on the Internet. They have a hard time trying to even go to a site. I'm amazed at how many people have to go to their home page, which happens to be a search engine, to type the url into the search box to get the site. They can't grasp that you enter it in the address bar. If httpp (http for porn) is put on port 81? We're suppose to believe that they can type http://porn.example.com81/ or httpp://porn.example.com?? It'll never happen.

At times, I tried to move things off to other ports. You'd be amazed how many people couldn't grasp the concept. Even putting a mail server web client on http://mail.example.com:8080/ completely throws them, even though you write it down for them, and it's right in front of them when they try to go there.

Other options have been attempted over the years. The meta tag pics-label was suppose to show what kind of content you were serving up. On very rare occasions, I see it used. Usually I don't.

There were other site rating tags that came and went. They weren't generally used by the browsers. They weren't implemented very frequently on web sites. In the end, they died. If someone was running an adult web site, they honestly wouldn't want to run the risk of having their content blocked by the provider, when the customer did want to view it. So, nothing identifying to say "porn".

Even the .xxx TLD was a spiffy keen idea, but that didn't have a prayer. "Please move all of your domains to the .xxx TLD. Ya, right. First problem. You may have different ownership of porn.com and porn.net. They'd both have to complete for that new position. Then you have to tell all of your viewers, "Go to porn.xxx, we're shutting down porn.com in 30 days". Some clients would only view every few months, or even every few years. They wouldn't have seen the memo, and would then be out of luck. No one, regardless of the business they're in, wants to lose their customer base because they had to move. That's why when you see a physical storefront move, you'll usually see a note taped in the front window saying "We've moved to 14 main street, 3 blocks over. Come visit us there!" those moves are usually unavoidable. It's better for a business to expand to a second location, than to ever shut down their first one. Frequently, it's a death sentence.

I know killing off the adult entertainment industry is a motive in wanting to force them to move. It won't work, but it'll really shake up the industry. New companies will get lucky and make more money. Old companies will be very very upset that they went from multi-million dollar empires, down to nothing. In the end, sites will still pop up as .com's on port 80, and they'll make good money by avoiding the new found filters.

If it wasn't an idea that would hurt things, why not move the mainstream sites over to a new "safer" place?

It then brings up the question, what's "safe". What's safe for my kid may not be safe for your kid. I run a news site. We carry news. What if you didn't want your kid to know about wars, or famine, rape, murder, drugs, or gay/lesbian/bi sexual preferences? Better not let them read the news.

Is a woman showing cleavage acceptable? How about in a bikini? Lingerie? Topless? Full frontal nudity? Implied sexual intercourse? Obvious and visual sexual intercourse? You may not want a 10 year old seeing too much cleveage, so should that be in the porn domain? Now you've moved things in

The site will be almost entirely content. It will need to be updated by non-technical staff, specifically uploading PDFs, creating new pages, and applying tags from multiple fixed taxonomies. It will need to handle user accounts and control editing permissions down to the page level. We do our own design so theming should be too hard, and the more flexible in content placement the better.

Thanks in advance.

As a big Joomla! fan I would not recommend you use Joomla unless you are planning on checking out 1.6 from subversion.

Plone has the highest learing curve of Drupal, Joomla!, and Plone., but it requires no tweaking to get what you need.

Plone does all of those thing out of the box.

Because Plone uses Zope instead of MySQL your PDF's will be objects that can have attributes http://www.example.com/mypdf.pdf can have the attribute http://www.example.com/mypdf.pdf/copyright.html

Skinning Plone is harder than Joomla and Drupal but spending the extra time skinning it so you can use a CMS that exactly solves your problem with no coding or extensions is what I would strongly recommend.

The site will be almost entirely content. It will need to be updated by non-technical staff, specifically uploading PDFs, creating new pages, and applying tags from multiple fixed taxonomies. It will need to handle user accounts and control editing permissions down to the page level. We do our own design so theming should be too hard, and the more flexible in content placement the better.

Thanks in advance.

As a big Joomla! fan I would not recommend you use Joomla unless you are planning on checking out 1.6 from subversion.

Plone has the highest learing curve of Drupal, Joomla!, and Plone., but it requires no tweaking to get what you need.

Plone does all of those thing out of the box.

Because Plone uses Zope instead of MySQL your PDF's will be objects that can have attributes http://www.example.com/mypdf.pdf can have the attribute http://www.example.com/mypdf.pdf/copyright.html

Skinning Plone is harder than Joomla and Drupal but spending the extra time skinning it so you can use a CMS that exactly solves your problem with no coding or extensions is what I would strongly recommend.

Alternatively, he might redirect from https://secure.example.com/ to https://secure.example.com/.ijj.cn, except that the slashes and dots in the last example are unicode characters that look like slashes and dots, so they don't register with the browser in the same way. He gets a legit cert to *.ijj.cn, then logs everything and forwards your responses to the address before .ijj.cn. For long URLS (which many secure logins have), the trailing .ijj.cn ends up past the end of your URL bar, and you don't notice.

After seeing Moxie's presentation, I'll be double checking every URL that needs to be secure to verify the 'https' protocol, and doesn't have any unusual endings. For things like the bank, I'll probably just bookmark the https version and never request the http version.

Alternatively, he might redirect from https://secure.example.com/ to https://secure.example.com/.ijj.cn, except that the slashes and dots in the last example are unicode characters that look like slashes and dots, so they don't register with the browser in the same way. He gets a legit cert to *.ijj.cn, then logs everything and forwards your responses to the address before .ijj.cn. For long URLS (which many secure logins have), the trailing .ijj.cn ends up past the end of your URL bar, and you don't notice.

After seeing Moxie's presentation, I'll be double checking every URL that needs to be secure to verify the 'https' protocol, and doesn't have any unusual endings. For things like the bank, I'll probably just bookmark the https version and never request the http version.

Alternatively, he might redirect from https://secure.example.com/ to https://secure.example.com/.ijj.cn, except that the slashes and dots in the last example are unicode characters that look like slashes and dots, so they don't register with the browser in the same way. He gets a legit cert to *.ijj.cn, then logs everything and forwards your responses to the address before .ijj.cn. For long URLS (which many secure logins have), the trailing .ijj.cn ends up past the end of your URL bar, and you don't notice.

After seeing Moxie's presentation, I'll be double checking every URL that needs to be secure to verify the 'https' protocol, and doesn't have any unusual endings. For things like the bank, I'll probably just bookmark the https version and never request the http version.

Alternatively, he might redirect from https://secure.example.com/ to https://secure.example.com/.ijj.cn, except that the slashes and dots in the last example are unicode characters that look like slashes and dots, so they don't register with the browser in the same way. He gets a legit cert to *.ijj.cn, then logs everything and forwards your responses to the address before .ijj.cn. For long URLS (which many secure logins have), the trailing .ijj.cn ends up past the end of your URL bar, and you don't notice.

After seeing Moxie's presentation, I'll be double checking every URL that needs to be secure to verify the 'https' protocol, and doesn't have any unusual endings. For things like the bank, I'll probably just bookmark the https version and never request the http version.

Alternatively, he might redirect from https://secure.example.com/ to https://secure.example.com/.ijj.cn, except that the slashes and dots in the last example are unicode characters that look like slashes and dots, so they don't register with the browser in the same way. He gets a legit cert to *.ijj.cn, then logs everything and forwards your responses to the address before .ijj.cn. For long URLS (which many secure logins have), the trailing .ijj.cn ends up past the end of your URL bar, and you don't notice.

After seeing Moxie's presentation, I'll be double checking every URL that needs to be secure to verify the 'https' protocol, and doesn't have any unusual endings. For things like the bank, I'll probably just bookmark the https version and never request the http version.