Slashdot Mirror

And use DANE to publish the CERT in a cryptographically verifiable manner,

They had another team working on their special RFC 1149 implementation.

In other words, IE and Chrome do not implement the data URI to the specification. Lucky them, they can pose now as "more secure".

I actually read TFS(TFRFC?). IIRC, the standard doesn't specify that an application honor redirects. It would depend on your interpretation of

"the same security considerations as any implementation of the given media type."

The passage seems to imply a "default deny" approach.

In other words, IE and Chrome do not implement the data URI to the specification.
Lucky them, they can pose now as "more secure".

...has more holes in it than Swiss cheese. It is not an invention per se as there is nothing new. It is not novel either, as the same thing has been done on many different types of devices before someone at this company thought to file a patent for it. Let's pick the thing apart, shall we? Claim by claim - though we'll skip a few for brevity.

Claim 1 asserts a base station which communicates with wireless clients and pushes relevant configuration data to them. It can only do that when the wireless device is in range. As a rough equivalent, think of a wireless router pushing network configuration data through DHCP to relevant clients. It can send specific data to specific clients (based on MAC, etc). The wireless clients generally notify the user ('wireless network detected!') and perform the configuration changes as pushed by the base station (can be anything from simple network configuration to more elaborate changes). If DHCP is not enough for your configurations needs, try ACAP (rfc 2244) as it has been languishing since 1997... would be nice to use it as I thought it showed promise back then.

Claims 2-8 just say this should be applied to a mobile device connected to the WWAN. Big deal. They narrow down the patent a bit, probably to make it easier to get it past the examiners. There is no inventiveness nor novelty in changing these specific parameters of a device configuration so it does not really make sense to have these claims - it is not as if the application of the mechanisms used by the likes of DHCP suddenly becomes novel and inventive when applied to the intensity of the backlight instead. It is, in other words, obvious to anyone in the field.

Claim 9 touches ACAP again, of course you need authentication to change certain parameters. You don't want that base station at the corner coffee shop to change your PROXY settings to run everything through their cousin's server.

Claim 10 tells the device to go into sleep mode. Yes, and? Why is this worthy of a claim in a patent application? Where is the novelty or inventiveness? What is the difference between putting the device in sleep mode and, eg, putting the backlight or the ringer in 'sleep mode' (ie. turning it off)? Next, please...

Claims 11-13 cover location assertion based on various methods, as all devices which are equipped with the right hardware have been doing since this hardware became available. Next.

Claim 14 tries to make a special case for a mobile device which uses its WLAN interface instead of WWAN. Next.

Claims 15 and onwards are of the same calibre - a total and utter lack of either inventiveness or novelty permeates them. As it does this whole 'patent'.

Still, the patent was awarded. And as such it can be used to stifle competition, force wanton changes in competitors' devices under the threat of litigation and actual litigation. If this comes before a jury the outcome can be anything as shown by the recent 1 billion dollar charade. If it comes before a panel of experts I have some hope that it will be squashed.

A friend of mine is a patent liaisons specialist ('patentgemachtigde'). When I speak to her about these issues she keeps on responding that bad patents are not a problem since they will be turned down in court. It has been a while since I spoke to her so I don't know if she still makes these claims, but it should be clear as daylight that the court is NOT the place to decide whether something is worth patenting. This should be handled by the patent office, NOT in the courts. The current system where patentability seems to be determined by 'throwing claims at the office to see which sticks' causes untold grief and massive economic losses for anyone not involved in the actual patenting process. And that is probably also why the likelihood of any significant changes is rather low, as the ones deciding on these changes are often direct beneficiaries of the current system: lawyers...

I don't mind if they all use a compatible OTP system, so that I can just have the one Google Authenticator app for my iOS device (or a compatible J2ME program on my non-smartphone). The services that annoy me are the ones that use different methods that I can't integrate with code generating programs I already have.

The nice thing with TOTP/RFC 6238 is that it's an open standard and not subject to the whims of a particular company. It's also completely independent of third-parties: I can set up my own TOTP system on my own systems and not have it be dependent on the availability or security of any third party.

Someone will hack them and will export the shared secret used for RFC 6238 TOTP: Time-Based One-Time Password Algorithm. Two factor authentication job is to protect the user, It doesn't make Dropbox security practices better, and they already demostrated are bad

Although I fundamentally agree that the underlying issue is their security practices (or lack thereof), this does address the specific recent hack (of an employee of theirs reusing the same password on Dropbox as on another account with another company that was compromised), and is a good idea regardless. I wish more sites did it.

the TCP-influenced algorithm almost exactly matched the ant behavior

How close?

They talking about a full implementation of RFC 5681 with all 4 schemes and all the bells and whistles, or just some trendy popular science stuff with "well, there seems to be ACKs".

http://tools.ietf.org/html/rfc5681 (not a rickroll, I promise)

I suppose a RFC 5681 loss recovery mechanism would be something like what happens when you step on an ant. ssthresh TCP setting is like how many ants fit thru the hole at once when you agitate the colony with a stick? We could probably have a lot of fun doing "official slashdot ant analogies" instead of the more common "official slashdot car analogies"

Someone will hack them and will export the shared secret used for RFC 6238 TOTP: Time-Based One-Time Password Algorithm. Two factor authentication job is to protect the user, It doesn't make Dropbox security practices better, and they already demostrated are bad

There is a big chance that will change in the future though. What do you think of Multi Path TCP ?

short demo:

http://www.youtube.com/watch?v=VWN0ctPi5cw

Longer presentation:

http://www.youtube.com/watch?v=02nBaaIoFWU

IETF WorkGroup:

http://datatracker.ietf.org/wg/mptcp/charter/

Linux kernel implementation:

http://mptcp.info.ucl.ac.be/

Unfortunately, multicast basically doesn't work on the current internet, at least not for most users, because most networks don't properly forward it. The MBONE, a 1990s overlay/tunnelled network, was probably the closest it's ever gotten to general deployment outside specific controlled contexts. 2001's RFC 3170 on deployment difficulties is largely still accurate, with the exception of its first sentence, "IP Multicast will play a prominent role on the Internet in the coming years."

Multicast is a very tricky thing to actually implement when you're dealing with multiple networks managed by different people/companies. I'm not going to get into the details, but there are a lot of engineering problems and security risks with allowing multicast at the provider level. Generally speaking, it's only used within discreet networks.

Unfortunately, multicast basically doesn't work on the current internet, at least not for most users, because most networks don't properly forward it. The MBONE, a 1990s overlay/tunnelled network, was probably the closest it's ever gotten to general deployment outside specific controlled contexts. 2001's RFC 3170 on deployment difficulties is largely still accurate, with the exception of its first sentence, "IP Multicast will play a prominent role on the Internet in the coming years."

The IETF disagrees. They know a thing or two about running the Internet, too, I hear.

Worthless, ill-designed, junk.

Nooooo!?! Next thing you are going to tell me is that the hackers disregard RFC3514 during attacks???

It is no longer entirely true that e-mail is not encrypted. Many SMTP servers support encryption using SSL or TLS when communicating with another SMTP server. For example here is an example of an SMTP server receiving an e-mail from one of Google's gmail SMTP servers.

Aug 7 13:33:28 x postfix/smtpd[22642]: setting up TLS connection from mail-gh0-f182.google.com[209.85.160.182]
Aug 7 13:33:28 x postfix/smtpd[22642]: Anonymous TLS connection established from mail-gh0-f182.google.com[209.85.160.182]: TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

I believe this behavior is defined by RFC 3207
If you manage a Postfix SMTP server and have not enabled TLS support I would suggest you read
http://www.postfix.org/TLS_README.html

The unique part about his equipment is that it's actually working like it's supposed to. The all-zeros address is the subnet-router anycast address, and if you attempt to talk to it, you should receive a reply from one of the routers on the subnet.

Linux implements this. If forwarding is enabled for an interface, then it will respond to traffic to the all-zeros address on any subnets on that interface.

(I'm not quite sure what happens for internal traffic if you have multiple routers on a single subnet. Maybe you'll end up sending packets to whichever one responds to NDP first? It's not an issue for traffic from outside the subnet, since that will just naturally hit one of the routers, which will handle the response.)

• digital encoding
• parallel transmission of multiple bits
• a multi-national network of data links

  Maybe not a full digital data network in the modern sense, but a large number of the fundamental ideas of such networks were exercised well before the introduction of the (serial) telegraph system.

  Further reading : http://en.wikipedia.org/wiki/Semaphore_line

  I learn that the Internet Engineering Task Force has produced an RFC ( http://tools.ietf.org/html/rfc4824 ) for using semaphore systems as a physical layer under IP and TCP.

  The status of this post is : ha-ha, but serious.

1) "The Internet" was invented by Vint Cerf, Yogen Dalal, and Carl Sunshine who worked for Stanford University and issued RFC 675 "SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM", and they were funded by ARPA.

2) Lots of other people and organizations developed lots of networks. ARPANET between University of California, Los Angeles and the Stanford Research Institute (funded by ARPA). There was also privately operated Telenet & Tymnet, and university lead MERIT networks as well as UUCP started at University of North Carolina at Chapel Hill.

3) I worked for one of the first private Internet Service Providers - tt was also one of the first providers of dial-up shell accounts, and later had one of the first national DS-3 IP networks. When I started cold-calling people for web design, they often told me "My customers will never use the Internet" (if they even knew what the Internet was). Suffice it to say that a lot of very forward-looking private providers of capital made that company possible, and they all made a lot of money in the process, and that turned the Internet from something you tinkered with at University into something real.

Also look at private companies like Cisco that made IP routing practical at large scales.

So I will 100% agree that government funding of university researchers created the Internet. However it would have never gone anywhere without private money funding a massive expansion and buildout of it.

Think university solar cell research funded by the government - good. Solyndra funded by government - bad.

And it would have also gone NOWHERE if government tried to regulate early ISPs as roughly as it regulated the incumbent telecommunications companies. We could do pretty much whatever we wanted with little regulation or censorship.

...really? You're gonna go there? So it had nothing to do with all the other stuff happening in 94-96? rfc1700 - assigned numbers in 94, rfc1737 Functional Requirements for Uniform Resource Names in Dec94, http/1.0 finalized in 1996, Linux bringing a bunch of common folks exploding onto the scene with things like RedHat 1.0 in Dec1994...you're not really giving credit to bloat and advertising for the explosion of the internet, are you? I owned an ISP from 1994-1996 (sold it). There was practically no advertising at the time, and it was still exploding. It exploded in spite of the bloat that came later. Are you just a ad exec or something, that you would put all the other things happening in the mid 90's behind advertising. Yeesh.

...really? You're gonna go there? So it had nothing to do with all the other stuff happening in 94-96? rfc1700 - assigned numbers in 94, rfc1737 Functional Requirements for Uniform Resource Names in Dec94, http/1.0 finalized in 1996, Linux bringing a bunch of common folks exploding onto the scene with things like RedHat 1.0 in Dec1994...you're not really giving credit to bloat and advertising for the explosion of the internet, are you? I owned an ISP from 1994-1996 (sold it). There was practically no advertising at the time, and it was still exploding. It exploded in spite of the bloat that came later. Are you just a ad exec or something, that you would put all the other things happening in the mid 90's behind advertising. Yeesh.

...really? You're gonna go there? So it had nothing to do with all the other stuff happening in 94-96? rfc1700 - assigned numbers in 94, rfc1737 Functional Requirements for Uniform Resource Names in Dec94, http/1.0 finalized in 1996, Linux bringing a bunch of common folks exploding onto the scene with things like RedHat 1.0 in Dec1994...you're not really giving credit to bloat and advertising for the explosion of the internet, are you? I owned an ISP from 1994-1996 (sold it). There was practically no advertising at the time, and it was still exploding. It exploded in spite of the bloat that came later. Are you just a ad exec or something, that you would put all the other things happening in the mid 90's behind advertising. Yeesh.

It's called wildcard aliasing...

$ dig +short ip-over-avain-carriers.slashdot.org
216.34.181.48

I don't think /. "support" RFC1149 (yet).

Perhaps somebody has an (expert) answer here to this question: Why was IPv4 even allowed or implemented in the first place? Did this have to do with computing and/or memory limitations back in the day (1974 to 1981) that nobody every thought could be overcome or even required? I know hindsight is 20/20.

I find it hard to understand how the researchers developing the IP protocol could think that 4.29 billion address would be sufficient given the scale of possible adoption in the future.

First things first: due to all of the reserved address ranges, particularly (what were once called) Class D and E addresses, there are fewer publicly routable internet addresses than ~4.29 billion. The number is ~3.70 billion addresses once you take the various reserved address ranges out.

With that out of the way, the world was a vastly different place back in the 1970's when IPv4 was first defined. The idea of everyone carrying a telephone with them everywhere was science fiction, and the notion that such devices would feature processing functionality that would be able to take advantage of being network-enabled probably wasn't even conceived. The personal computer revolution hadn't happened yet either. As you said, hindsight is 20/20. It's easier to see how we got to now from there than the other way around.

It's also worth keeping in mind that when IPv4 was standardized in 1981 ([RFC 791]), computers were not particularly powerful; a state of the art desktop machine of the era would have little RAM, an 8 bit processor, and would run at less than 5Mhz. A device with an 8 bit processor would require at least 4 LOAD instructions to load an address from memory into registers, plus whatever processing would be required against the address (particularly for routing). Newer 16 bit processors (such as the 8088 and 8086) could do the same sort of processing with only two MOV instructions, but using a 128 bit address like in IPv6 would have required 8 bit systems to do a lot of processing just to handle the addresses -- you'd have to run 16 LOAD instructions just to read every part of the address into registers. This would be very significant processing wise for the time; I'd venture to say you'd need a supercomputer just to act as an IPv6 router back in 1981 (even with the limited number of hosts actually on the network). Memory would be a consideration as well -- 16KB fills up pretty quickly, so squeezing every byte out that you can would have been advantageous.

I'm also not particularly sure that the designers of IPv4 had a public Internet in mind. It wasn't until the early 1990's that the Internet was generally opened to commercial use; prior to that it was limited to government and research use. I don't think in the mid 1970's when Robert E. Kahn and Vint Cerf started work on trying to unify the various networks then in operation, that they considered that people would have a dozen or more Internet enabled devices in their homes (at current count there are 24 IP enabled devices in my home, although I certainly don't claim to be typical). That is, the "purpose" of the protocol at the time wasn't to provide a pervasive network that covered the globe, and the idea of 2^32 hosts was probably completely inconceivable. IPv4 has since invention been shoehorned into uses and purposes that were never conceived at the time of its invention. Indeed, considering how many protocols were being invented, and how quickly new iterations were being introduced, it probably wasn't expected that the world would still be using IPv4 over thirty years after it had been first defined.

IPv4 is getting to be a creaky, old technology with all sort of band-aids applied to it over the years. It is time for replacement -- the research and development community has been saying so for fifteen years or more. Unfortunately, the momentum behind IPv4 is massive, and entrenched inte

That seems great, but then to validate against the schema you must have a full JavaScript interpreter (or almost full, depending on how much you're willing to restrict what can be used in the isValid function). Not to mention that, this being JavaScript, a lot of schemas would end up being a mess, which would defeat half of the purpose of a schema -- being a human-readable documentation of the data format.

Schema validation is a very clear example of a situation where it's not good to have a Turing-complete language. There is a proposal for a JSON schema language (where schemas are themselves JSON documents). Apparently there's not much interest, though.

Then it cannot replace HTTP and should be withdrawn, or it's been wrongfully sorted in under "HTTP/2.0 Proposals"

The IETF HTTPbis Working Group has been chartered to consider new work around HTTP; specifically, a new wire-level protocol for the semantics of HTTP (i.e., what will become HTTP/2.0), and new HTTP authentication schemes.

Good point - unless there are particular reasons that a "niche protocol" for highly interactive sites is better than a general purpose one then a replacement that covers all uses should be covered. In fact I have come round to agreeing with TFA: "SPDY Should Be Viewed As a Prototype"

Then it cannot replace HTTP and should be withdrawn, or it's been wrongfully sorted in under "HTTP/2.0 Proposals"

The IETF HTTPbis Working Group has been chartered to consider new work around HTTP; specifically, a new wire-level protocol for the semantics of HTTP (i.e., what will become HTTP/2.0), and new HTTP authentication schemes.

A home or "cloud" PC that you can login to from any dumb terminal makes much more sense.

Not if you're on a bus that doesn't provide affordable Wi-Fi. At $10 per GB for cellular data, remoting into another computer can get expensive.

and if you've got a static IP

Homes aren't guaranteed to have this. A lot of countries have effectively run out of IPv4 addresses, and ISPs are giving home customers 10.x.x.x addresses on private internets. To accept incoming connections, you'll need to pay extra for business class service.

Involved in the creation of the browser useragent

That was entirely self-serving. They wanted a mechanism to allow webpages to target IE specifically rather than the standard HTML features.

Video codec innovations which led to VC-1 being the premier codec for HD-DVD and BR discs.

Early codecs were based on Quicktime code stolen by a sub-contractor from Apple. VC-1 is inferior to H.264, HD-DVD lost the format war and many BR discs with the best video quality use H.264.

Helped establish TrueType

Did you even read the page you linked to? I quote: "TrueType is an outline font standard originally developed by Apple Computer in the late 1980s as a competitor to Adobe's Type 1 fonts used in PostScript."

ClearType

They were copying ATSUI.

The Taskbar

A copy of the NEXT dock and other systems.

Ability to alter compiled code while debugging it

NEXT had that in the 90's with the predecessor to X-Code and Objective-C.

Lots of small innovations in .NET that when combined equal large cumulative innovation.

The .NET framework borrowed ideas from Cocoa and Java.

XNA

Most high profile games that are multi-platform use C/C++ code rather than XNA.

Shadow Copy

A backup on the same hard drive? That is not a backup. It is idiotic.

Certainly that should qualify as an innovation.

Nope.

Microsoft has never been an innovative company. Never.

They came up with AJAX and prior to that Iframes, maybe you've heard of those?
Microsoft had the first console to feature an internal HD eliminating the need for memory cards for save games among other things.
Intellisense is amazing (it's an example of auto completion done well).
The scroll wheel on a mouse. The first optical mouse.
The first mouse featuring backwards and forwards buttons.
First mainstream ergonomic mouse.
While not the first, they're responsible for ergonomic keyboards (due making them affordable, just like PCs)
Teraserver (1998 a precursor to Google Earth)
Involved in the creation of the browser useragent
Video codec innovations which led to VC-1 being the premier codec for HD-DVD and BR discs.
Helped establish TrueType
ClearType
The Taskbar
Ability to alter compiled code while debugging it
Dynamic HTML desktops
Lots of small innovations in .NET that when combined equal large cumulative innovation.
XNA
Alt tab to switch between applications
Photosynth
Microsoft OneNote
First OS to have a 3D Sound api for games
Shadow Copy
Certainly that should qualify as an innovation.

They won the PC-DOS contract in 1981, overlaid it with Windows GUI 4 years later...Apple that were doing the innovating.....

By giving Xerox a bunch of stock in their company for access to their GUI technology, essentially buying technology just like Microsoft?

according to that link PBKDF2-HMAC-SHA512 is, when implemented correctly; as an example of bad implementation see that microsoft blog post about .NET 2.0 (we are at 4). A good place to start is to understand that jargon is RFC 4868 as it has almost all the links to the pertinent material.

This seems like the kind of problem made by one of those "super-bright" children that got hired for way too much money in the late 90's and were given offices with dog beds and room for their skateboards while they ignored all the great original standards that made the internet possible, and built insanely over-engineered new ones in the hope of making a fortune.

I'm not sure what "this" refers to there, but, as per RFC 958, the "leap indicator" dates back at least to 1985, and, at least if I remember correctly, the "seconds since the Epoch" doesn't mean "seconds that have elapsed since the Epoch" dates back to the original 1988 POSIX.

As far as I knew, NTP just says "Hey, server, what time is it" and gets back "It's f*****ing 3 o'clock, exactly 1 hour since the last time you asked. Now go away and quit bothering me!" (only it says it really fast using a single big number) At which point the software makes sure my server knows it's 3 o'clock.

No, as others have noted, NTP does a lot more - including saying "hey, a {positive or negative} leap second is coming up!" (look for "leap indicator" in RFC 5905). What the NTP client does with that is up to the client; I guess Linux is trying to do what POSIX specifies, i.e. having "seconds since the Epoch" be something other than a count of the seconds that have elapsed since the Epoch.

From my own machines and comparing notes with some other people (all in all, about 3k servers) the bug seems to affect machines randomly. Known facts:

There's a kernel patch that fixes the supposed issue: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

I don't think that's the issue. The issue discussed in this lklm thread is a different issue with, presumably, a different John Stultz fix.

The fix has been posted at lot of places: /etc/init.d/ntp stop; date; date `date +"%m%d%H%M%C%y.%S"`; date; /etc/init.d/ntp start

Presumably meaning "workaround" rather than "fix".

(I'm all for switching unix time to a simple counter and leaving it to the calendar libs to put the leap seconds where necessary)

Sounds good to me, but I thought that was a good idea back in the late '80's; the POSIX people thought otherwise, so....

At least as I read RFC 5905, time stamps in NTP packets are essentially "simple counters", and count positive leap seconds and don't count seconds removed with negative leap seconds. I'm not sure what an NTP implementation is supposed to do with the "leap indicator"; that might be dependent on what sort of time the system is supposed to provide to applications. I don't know whether the Linux kernel giving a damn about leap seconds is due to it trying to supply "POSIX time", i.e. time represented as "seconds since the Epoch" rather than as the number of seconds that have elapsed since the Epoch (yes, the two are different), or if it has to do that to function as an NTP client.

There are no "secret cookies". Cookies are stored by your browser. Opting out means telling your browser not to store the cookies sent by the server. All other forms of "opting out" are doomed to fail anyway. It's as simple as that.

If your browser still accepts cookies despite you have configured it not to do that, it's your browsers fault, not the fault of the website operator. Don't get me started on stupid things like "Do not track". There was a time when IT people laughed at things like that (remember the evil bit?).

I think that's Slashdot's sig facility in operation. The dash-dash separator gives it away.

Though I note that the RFC(section 4.3) specifies (for Usenet posts) dash-dash-space.

ISPs should be LRO compliant to ensure YRO. In fact, why not just use the RFC 1130.5 protocol but remove the obviously useless section 5.1.5. Then all that would need to be done is TTLA the WRG on a section 554(b), and let the GNIC handle the rest. Easy peasy!

I found your paper. Pastebin Mirror.

It's only a hierarchy because a long time a ago when the hosts.txt file got too big Paul M figured out a way to slide it up to balance the storage and computational power. Brian R got Paul V to take the Berkely B-Tree code into a professional product. Jon P asked the same question on the MSGGROUP mailing list and there was no agreement so he made up the com/net/org convention.

We don't need the hierarchy any more...

There's no inherant reason bad.shit.com needs be any relation to good.shit.com. Arguably it's just not worked out that one guy gets shit.com and some guy gets com, if each name were discrete it reduces or elimiates a bunch of problems.

as for actual transport:

DHT - The Network is the Registry....with 480-bit Keys ....
PUT(KEY,DATA,TIME)
GET(KEY)

Simon Higgs made what I thought was the best first approximation of a sensible tld-space if you wanted to stay in that model. God knows why you'd want to though, it got us going but it's really been nothing but trouble.

http://tools.ietf.org/html/draft-higgs-tld-cat-02 He worked on this with Jon.

While that's true, a standard (and popular library) for SCTP-over-UDP could be created. At most, you'd need a single well-known UDP port for inbound SCTP-over-UDP (9989 is suggested by the Internet draft for this). SCTP ports would be used to distinguish between separate SCTP-using services on the server. I'm sure that the existing Linux and BSD SCTP stacks could support this with little effort. Firewalls that only permit HTTP/HTTPS would block this variant, but it would work well enough through NATs, especially if the multiple-endpoint parts of standard SCTP were left out.

Personally I'm a little sceptical about the testing methodology:

For a proxy, I used the Cotendo CDN (recently acquired by Akamai). Cotendo was one of the early adopters of SPDY, has production-grade SPDY support and high performance servers. Cotendo was used in three modes – HTTP, HTTPS and SPDY (meaning HTTPS+SPDY).

Surely that means that the proxy would have to download at least some of the pages from non-SPDY servers on demand, rendering this entire thing suspect? He said that he ran 5 replicates, but no attempt is offered at explaining why SPDY should be slower than plain ol' HTTP, only why it might not be faster. I could be wrong, but it looks like the protocol is more concise on average even for a single-page request. Maybe Cotendo just has a bad implementation?

Neither Chomsky or Ayyadurai seem to have heard of RFCs.

"To", "From", "cc", and "subject" are all parts of the original 1975 RFC for mail transport protocol which standardized the eariler 1973 RFC.

In the days of the eariler internet, the ideas of "from" and "sender" were not presumed to be the same (or example, it might be assumed that the "from" might be the person that dictated the message and the "sender" was the secretary, or even an automated computer process).

Email with a "To" routed to a machine located in your own organization was usually very trivial (user name only, no machine name at all, or at most the name of any machine on the locally admistered network if your machine wasn't on that specific network), just like a memo.

Unfortunatly, non-local address mechanisms on the (pre-global-domain-routed) internet, were usually very complicated (unlike the post office or an internal organization memo). Today, postal addressing is hierarchical (even pre-zipcode, postal addressing was city-state and they tried to figure it out for you). The pre-domain internet** used to be like postal addressing of olden-times when you had to put a rural-route# as part of the address since many streets didn't have names and if it didn't get there, it was most likely gonna get stuck in general delivery at a sorting center.

Of course my experience isn't the earliest (I'm not that old yet). In case anyone is interested, the list of known routable email systems circa 1979 is listed in RFC 808, many of those systems had be up for at least 5 years and in specific, the BBN SNDMSG was up and going in 1971 (which is by general consensus the granddaddy of email systems, but they didn't use To/From, but the more cryptic TOUSR/RPY)...

**Life was especially bad in the early internet days when many folks had shiny new fully qualified domain name email addresses, but many machines (which were email endpoints) weren't connected to the internet so some addresses needed to have routing information that was composed of parts that were right to left (domain style) and some left to right (! uucp style). I had the mispleasure of implementing sendmail rules for rmail/domain/decnet routing, so I was scarred permanently by that period of time...

"To", "From", "cc", and "subject" are all parts of the original 1975 RFC for mail transport protocol which standardized the eariler 1973 RFC.

In the days of the eariler internet, the ideas of "from" and "sender" were not presumed to be the same (or example, it might be assumed that the "from" might be the person that dictated the message and the "sender" was the secretary, or even an automated computer process).

Email with a "To" routed to a machine located in your own organization was usually very trivial (user name only, no machine name at all, or at most the name of any machine on the locally admistered network if your machine wasn't on that specific network), just like a memo.

Unfortunatly, non-local address mechanisms on the (pre-global-domain-routed) internet, were usually very complicated (unlike the post office or an internal organization memo). Today, postal addressing is hierarchical (even pre-zipcode, postal addressing was city-state and they tried to figure it out for you). The pre-domain internet** used to be like postal addressing of olden-times when you had to put a rural-route# as part of the address since many streets didn't have names and if it didn't get there, it was most likely gonna get stuck in general delivery at a sorting center.

Of course my experience isn't the earliest (I'm not that old yet). In case anyone is interested, the list of known routable email systems circa 1979 is listed in RFC 808, many of those systems had be up for at least 5 years and in specific, the BBN SNDMSG was up and going in 1971 (which is by general consensus the granddaddy of email systems, but they didn't use To/From, but the more cryptic TOUSR/RPY)...

**Life was especially bad in the early internet days when many folks had shiny new fully qualified domain name email addresses, but many machines (which were email endpoints) weren't connected to the internet so some addresses needed to have routing information that was composed of parts that were right to left (domain style) and some left to right (! uucp style). I had the mispleasure of implementing sendmail rules for rmail/domain/decnet routing, so I was scarred permanently by that period of time...

That was fast - "A New HTTP Status Code for Legally-restricted Resources" by Tim Bray of Google...

SIGH :(

http://tools.ietf.org/html/rfc524

I agree that the guy's claim is dopey, and I'm not paying careful attention to Chomsky's claim, but I suspect that here he is playing some semantic game that he finds relevant in theory, but serves no useful purpose in fact.

403 is exactly right:
  "The request was a legal request, but the server is refusing to respond to it"

No, because you're not talking to the server your requested. A gateway before the server is refusing to let you access the real server. This is why a code in the 45x series is better as several parental control systems already use 450 to signal gateway censorship.

The patent covers using the page the request was made from to decide what file you should get. The original patent was filed in the UK in April 1996 and discusses the HTTP protocol and the referrer address, but RFC 1945 was published a month later and defined the HTTP protocol (including the misspelling of referer). Perhaps this information was added to the US version of the patent when it was filed in March 1997.

This seems like something they could get a few bucks each out of the various blogs that forbid hotlinking by serving up goatse whenever the referer URL for a picture is some other site. But I guess they can get more than a few bucks out of Google and AOL, even if it's not really clear how they infringe on the patent.

You don't ??
At least bother to read the relevant section in the rfc.

403 is exactly right:

"The request was a legal request, but the server is refusing to respond to it"

Next question please.