Please see my earlier post on this topic. It's currently +5, and this whole discussion is so non-specific it's ridiculous. Yes, it would be neat if we could type "alt://" and have different addresses resolve by using a Gnutella-like system, therefore eliminating the need for ICANN. Is it feasible? Well, let's see, no one's even addressed that. How can you throw around ideas without even mentioning any technical aspect of them and get moderated to +4?
Hey, here's an idea: make it so that every file on the Internet can be downloaded at the same speed, regardless of how fast your connection is. Wow, that'd be neat!
Comon folks, at least think about the actual content of some of these comments before you moderate them up. Whoever thinks that the super-smart crowd that is Slashdot is collectively coming up with ground-breaking Internet concepts should go write an article for ZDNet about it... I'm sure they'd take it.
You must have no concept of how IP routing works across the Internet. I think that the parent post of your comment implies that the box would be moving from one IP subnet to another one. Well, assuming that the entire Autonomous System isn't moving and that Internet-advertised BGP routes aren't changing, the box would have to change IP addresses. That's his point.. DNS makes it possible to transparently move box from one location to another location, changing IP addresses in the process. That is inherently a feature of DNS. You may have other qualms with it, but it's not all bad.
Do you realize how much DNS traffic is passed over the Internet? If there was no central registry that told DNS servers "go to this IP for info on this domain," all DNS queries would somehow propogate in "peer-to-peer" fashion until the appropriate DNS server heard the query (?). That would be remarkably slow and wasteful, similar to the Gnutella search mechanism. Except, in the case of Gnutella, the whole point of the topology is to maintain distributedness at the cost of response time and bandwidth. One cannot make such a case for DNS.
Okay, so maybe you are picturing an architecture along the lines of BGP (large networks share routing information about each other all over the world with no central "Internet route server"). Well, that's a nice concept, except that every DNS server in the world would have to maintain an entire copy of the DNS database (just as most routers employing BGP on the Internet maintain an entire copy of the Internet's routing table via Autonomous System Numbers). The key difference is that the DNS database is many orders of magnitude larger than a "BGP database." In addition, you can't summarize domain names like you can with IP address blocks (i.e. DNS CIDR = oxymoron).. and remember, you said no hierarchy, which would imply that you don't pull "views" of the DNS database from any sort of central/upstream DNS server.
When you speak so vaguely ("DNS should be made peer-to-peer, not top down"), it sounds good.. but that statement carries no real weight in any discussion approaching technical viability. If you're merely speaking idealistically (e.g. "in a perfect world, we would be able to implement DNS in a distributed manner in such a way that it didn't suck"), I agree wholeheartedly.
This notion can definitely be explored further, but it's safe to say that this is not a simple solution, and I daresay that without some fundamental modifications to basic concepts such as "peer-to-peer" and "no hierarchy," very little progress would be made in seeking a superior solution. I don't see any technical merit in your proposal, so the only motivation is "ICANN is bad, now we don't need them."
The next logical step is to fix ICANN, not break DNS.
I concur. I live and work in KC, as well and have not hear anything about this event. The web site looks pretty shoddy, and what's with this remark at the bottom of the page?
"
® LINUX is a registered trademark of Linus Torvalds in several countries"
Anyhow, I might stop by and check it out tomorrow and judging by the 'Speakers' section, there might be some decent material there (someone mentioned a beowulf cluster!).
Unfortunately, due to the lack of promotion, not to mention a "LinuxFest sucks" story on Slashdot, I am having my doubts as to how great this will actually be.
By the way, if anyone decides to have a Linux-centric event in the future and they're considering the use of any forms of the words "festival" and "linux" in the title, there better be some kegs there.. discussions about "Using Linux for teaching" don't quite qualify as festivals in my book.
"But I THINK Netscape's up to 128 bit SSL now. Yeah, that's still not too great. But consider..."
Wait! Don't tell me.. let me guess: everything you know about encryption you learned on Slashdot. Additionally, you think that since the number 128 isn't really that much bigger than 40 (and you "know" that 40-bit is a Bad Thing (TM)), 128-bit is "still not too great."
You're wrong. Go educate yourself.
This post is intended to be intellectually stimulating -- not offensive.
Why so many rules? Because if you told people about it, they'd realize how ignorant you were for taking RoShamBo so phenomenally seriously:
Hey, let's all write programs that attempt detect other people's patterns and base our moves off of that while, at the same time, making our program seem to be moving in a certain pattern, but not really patterning our moves after anything detectable, so as to seem random. Damn, we're bright!
Some choice words from Mr. RoShamBonehead:
"..but the best strategy can be quite complicated when playing against fallible opponents"
Gee, that sounds strikingly like the skill level needed to win tic-tac-toe (play against stupid people)?
"The game is trivial from a game-theoretic point of view"
I do agree that the game is trivial, but I'm not so sure about this so called "game-theoretic" stuff.. could someone explain some of the game-theoreticizationismifications to us, per chance? I'm not quite sure I see his point of view..
"The optimal mixed strategy is to choose an action uniformly at random. This will ensure a break-even result in the long run, regardless of how strong (or how weak!) the opponent is"
Oh.. well if that's all. I just do the good old-fashioned mixed strategy of uniform randomness and then bing-zam-boom! I'm the winner? Okay. Not only that, but there's some sort of ensured result from this so-called randomness. Dammit, that makes so much sense it's like I'm sitting here saying "please don't be so crystally clear in your ignorance.. you're ruining my Pick-up Sticks (TM) programming contest"
"against predictable opponents, a player can attempt to detect patterns in the opponent's play"
This is just the introduction and it's already getting so damn complicated with all this jazz about being able to predict players that are predictable.. whew!
You are a fraud. You don't use Perl and you never have. You don't know what Perl stands for, nor do you know what it can do. Anyone who makes the above statement must be a GW-BASIC programmer.
So, 30 minutes after initially installing Quicktime and following your 20 easy steps, I've got a hacked-together fully-functional copy running! Wow, that's quality software.
Your excerpt from the patent simply describes one of the many steps in the whole process of displaying banner ads and tracking users with them. This particular step could be summarized as follows:
"Set a cookie so that other servers can read the cookie."
Nothing I've seen indicates that anything that you said relates to the part of the patent that you posted. Centralized banner ad distribution is just one facet of a banner advertising network, and your argument is tangential to the core issue; picking it apart and taking things out of context (not to mention misinterpreting them) won't help your case. Not only that, but the Slashdot editors' comments were extremely relevant.
Summary: Your comment is analagous to saying, "The sky is blue, so Slashdot is dumb."
"
Then, there's the physical network. You don't HAVE to use the backbone routers to connect to others, or vice versa. Anyone can build their own backbone and provide access to anyone on the Internet."
Just out of curiousity, do you have any idea what you're talking about? Let's see.. you went on to say,
"With a rapid increase in distributed projects, cheap home networking, etc, the very notion of a 'backbone' is doomed, in the long run. It's just a matter of when."
Umm.. alrighty. It seems apparent from your post that you think that all traffic on the Internet backbone passes through ICANN (that's non-sensical) or that the existance of some specific Internet backbone is key to its functionality.
"I'd say that ICANN, AT&T and Bell have a LOT to worry about..
I think most people would agree that there isn't an "Internet backbone" as most laymen probably conceptualize in their head. That is, there isn't one big piece of fiber that everything passes across before it can go anywhere else. Given the number of autonomous systems (as in BGP), the notion that AT&T and Bell (or even the bigger providers at large interconnection points such as mae-east/west) somehow rule the Net is nothing more than a misconception.
The basis of your post is that there is centralized control over name services and that if that centralized control is lost, then the centralized control over the physical network will be lost. The premise of the latter part of this statement, that there is some centralized physical network, is entirely incorrect. For example, European Internet traffic probably doesn't pass through the United States en route to South Africa (not to say that it couldn't; I'm just pointing out that there's no friggin' global backbone, per se). Decentralized name services could be designed in such a way that they would be just fine and the Internet is already decentralized, physically and logically, for the scope of this discussion.
Conclusion: This isn't setting a precedent for a chaotic global communications breakdown. It's just the next logical step along the road to virtual nirvana.
As much as I agree with the general tone of this story, I don't think that the analogy used fairly represents the situation:
"I wonder if they would have thought they could get away with this had it been 'You're black and we don't want the racists to break our windows so we ain't selling you an account.'"
That sounds pretty good and even evokes strong emotion. But my insurance company recently told me, "You are a dangerous person and create too high of a risk of financial loss to make it worthwhile for us to continue to provide our insurance service to you. Screw you, potential loss!"
I can't blame them. Given my past history of costing them lots of resources, they decided to drop me, even though none of the car wrecks/stolen vehicle incidents were my fault. Keeping on clients that are magnets for unncessary expenditures is not intelligent. Potential exposures are bad, as well.
Most ISPs' policies state that they can terminate access for any reason whatsoever at their sole discretion. In many other professional fields, these terms would be ridiculous. Nonetheless, ISPs have not been forced through competition to uphold any kind of standard. They want your money but not if it costs them resources (read bandwidth, customer complaints, downtime, network engineers, etc.).
Does this suck? Yes. Can ISPs afford NOT to take every measure possible to avoid a massive DoS that can cost them their business? No.
As a security expert, you know that encryption is EXPENSIVE
This could not be further from the truth. You're line of thinking, that everyone must have a chip on their motherboard before encryption can be widespread and cheap, is nothing short of delusional:
You don't need a chip to do encryption
Chips wouldn't be (and arne't) that expensive, anyhow
You can put such chips on an ISA/PCI/USB interface, as they don't need to be on the motherboard (e.g. hardware that enhances SSL processing)
Did you even read the post you were replying to? How much do you think that individual spent to be able to apply encryption to so many aspects of his computing and communications methods? Virtually nothing.
Your argument is not unreasonable; in fact, I think it's a common misconception. It's not some huge monumental ordeal to deploy encryption for yourself, casually. It should be obvious after reading the parent post that it encryption can be employed almost everywhere, cheaply and effectively, in the status quo.
Read this post if you think that saying "this document is copyrighted by me" means that it can't be reprinted; I think it very clearly explains why Slashdot is in the right:
Unless you're implying that you should be able to enter a random URL, like http://www.joescomputers.com/, and have it discover the price for a 10GB Seagate hard drive, or some specific item, without anyone having told the software the format with which Joe's Computers displays its prices, or even which page they're on, then you're just talking about searching through HTML, tables, etc., which is most certainly not AI.
Are you unable to judge an argument based on its logic and rationale? You don't have to be an expert on anything to be able to present intelligent concepts in an eloquent manner. I take people who are unknown, but make sense, more seriously than I take people who are well-know, but wrong.
You seem to take offense to his comments.. "preaching"? He's not preaching to anyone; he's formed an opinion, presented it, and proposed a solution. The basis of his argument is not "I saved the day once, so you should do what I say!" No part of the article hinges on the fact that he's smart man for doing what he did. He lets its merit stand for itself. Why don't you?
I thought the following snippet of information might be relevant to the discussion taking place. This is, of course, just for reference. Oh, and by continuing to read this post, you agree to Microsoft's EULA and authorize the immediate transferral of your soul to Microsoft Corporation:
The real culprit is short-sited government policies, where as ever they believe that the best way to make a problem go away is to legislate against it.
I don't see how any action the government took (or failed to take) resulted in the creation and spread of this malicious virus. You may think that the government made some bad decisions, or should've made different policies (or no policies at all), but it seems ludicrous to assert that they could've stopped this virus or even that they fostered an environment where virii could propogate.
Your argument is poor. You have no link between the government and this virus, yet you blame them for it.
Your proposed "solution" is equally asinine. The notion of commercializing virii (which, by the way, is an idiotic idea, in and of itself) is inherently tangential to the issue of the ILOVEYOU virus. It is phenomenally feasible for the following to occur:
we elect to put your ridiculous system in place
policies are changed world-wide to fit your schema
an entire industry is born centered around the crap you outline in your post (commercialization of virii-creation and fixing, etc.)
some loser from the Phillipines writes a virus, it spreads, and screws up lots of computers
Wow! That's a great idea you've got there. It does absolutely nothing to address the real issue: preventing virii like this from affecting so many people in such a drastic way.
Trollmastah, a well-known participator in the on-line forum, Slashdot, although once dismissed as a so-called "troll," has risen to the top of the turnip truck by soliciting offers from record producers across the country. They are professing a newly rejuvenated interest in a funky-fresh style among computer kiddies that has been tagged as "digital bands."
No one actually knows what a digital band is, but they're pretty sure it's really stupid.
In summary, I offer the following lyrics from the up-and-coming digital band, Slashdot This, in order to retain topicality (i.e. not off-topic):
Bottom line: Are you willing to sacrifice the future of the entire Internet to avoid the minor inconvenience of a few sleazy pornographers?
Well, I don't know. Is that a loaded question? I wonder..
Did it ever occur to you that we wouldn't be forced to make such ignorant choices (internet or porn: one or the other, but not both) if it weren't for stupid people like you?
Slashdot Mirror
Please see my earlier post on this topic. It's currently +5, and this whole discussion is so non-specific it's ridiculous. Yes, it would be neat if we could type "alt://" and have different addresses resolve by using a Gnutella-like system, therefore eliminating the need for ICANN. Is it feasible? Well, let's see, no one's even addressed that. How can you throw around ideas without even mentioning any technical aspect of them and get moderated to +4?
Hey, here's an idea: make it so that every file on the Internet can be downloaded at the same speed, regardless of how fast your connection is. Wow, that'd be neat!
Comon folks, at least think about the actual content of some of these comments before you moderate them up. Whoever thinks that the super-smart crowd that is Slashdot is collectively coming up with ground-breaking Internet concepts should go write an article for ZDNet about it... I'm sure they'd take it.
You must have no concept of how IP routing works across the Internet. I think that the parent post of your comment implies that the box would be moving from one IP subnet to another one. Well, assuming that the entire Autonomous System isn't moving and that Internet-advertised BGP routes aren't changing, the box would have to change IP addresses. That's his point.. DNS makes it possible to transparently move box from one location to another location, changing IP addresses in the process. That is inherently a feature of DNS. You may have other qualms with it, but it's not all bad.
Do you realize how much DNS traffic is passed over the Internet? If there was no central registry that told DNS servers "go to this IP for info on this domain," all DNS queries would somehow propogate in "peer-to-peer" fashion until the appropriate DNS server heard the query (?). That would be remarkably slow and wasteful, similar to the Gnutella search mechanism. Except, in the case of Gnutella, the whole point of the topology is to maintain distributedness at the cost of response time and bandwidth. One cannot make such a case for DNS.
Okay, so maybe you are picturing an architecture along the lines of BGP (large networks share routing information about each other all over the world with no central "Internet route server"). Well, that's a nice concept, except that every DNS server in the world would have to maintain an entire copy of the DNS database (just as most routers employing BGP on the Internet maintain an entire copy of the Internet's routing table via Autonomous System Numbers). The key difference is that the DNS database is many orders of magnitude larger than a "BGP database." In addition, you can't summarize domain names like you can with IP address blocks (i.e. DNS CIDR = oxymoron).. and remember, you said no hierarchy, which would imply that you don't pull "views" of the DNS database from any sort of central/upstream DNS server.
When you speak so vaguely ("DNS should be made peer-to-peer, not top down"), it sounds good.. but that statement carries no real weight in any discussion approaching technical viability. If you're merely speaking idealistically (e.g. "in a perfect world, we would be able to implement DNS in a distributed manner in such a way that it didn't suck"), I agree wholeheartedly.
This notion can definitely be explored further, but it's safe to say that this is not a simple solution, and I daresay that without some fundamental modifications to basic concepts such as "peer-to-peer" and "no hierarchy," very little progress would be made in seeking a superior solution. I don't see any technical merit in your proposal, so the only motivation is "ICANN is bad, now we don't need them."
The next logical step is to fix ICANN, not break DNS.
Unfortunately, due to the lack of promotion, not to mention a "LinuxFest sucks" story on Slashdot, I am having my doubts as to how great this will actually be.
By the way, if anyone decides to have a Linux-centric event in the future and they're considering the use of any forms of the words "festival" and "linux" in the title, there better be some kegs there.. discussions about "Using Linux for teaching" don't quite qualify as festivals in my book.
Oh well.. we'll see.
Did it occur to you that comparing 4096 to 128 might be like comparing apples and oranges? I'm serious: go educate yourself.
"But I THINK Netscape's up to 128 bit SSL now. Yeah, that's still not too great. But consider..."
Wait! Don't tell me.. let me guess: everything you know about encryption you learned on Slashdot. Additionally, you think that since the number 128 isn't really that much bigger than 40 (and you "know" that 40-bit is a Bad Thing (TM)), 128-bit is "still not too great."
You're wrong. Go educate yourself.
This post is intended to be intellectually stimulating -- not offensive.
"Postive"? For being a grammar nazi, you sure do spell horribly.
Don't talk about RoShamBo club.
Second rule of RoShamBo club:
Don't talk about RoShamBo club.
Gee, that sounds strikingly like the skill level needed to win tic-tac-toe (play against stupid people)? I do agree that the game is trivial, but I'm not so sure about this so called "game-theoretic" stuff.. could someone explain some of the game-theoreticizationismifications to us, per chance? I'm not quite sure I see his point of view.. Oh.. well if that's all. I just do the good old-fashioned mixed strategy of uniform randomness and then bing-zam-boom! I'm the winner? Okay. Not only that, but there's some sort of ensured result from this so-called randomness. Dammit, that makes so much sense it's like I'm sitting here saying "please don't be so crystally clear in your ignorance.. you're ruining my Pick-up Sticks (TM) programming contest" This is just the introduction and it's already getting so damn complicated with all this jazz about being able to predict players that are predictable.. whew! Jeez! I guess he saved the best for last. Now, if only they had RoShamBo for Palm..Why so many rules? Because if you told people about it, they'd realize how ignorant you were for taking RoShamBo so phenomenally seriously:
Hey, let's all write programs that attempt detect other people's patterns and base our moves off of that while, at the same time, making our program seem to be moving in a certain pattern, but not really patterning our moves after anything detectable, so as to seem random. Damn, we're bright!
Some choice words from Mr. RoShamBonehead:
You are a fraud. You don't use Perl and you never have. You don't know what Perl stands for, nor do you know what it can do. Anyone who makes the above statement must be a GW-BASIC programmer.
Are those like optical switches.. or do they have less 'cal' and more 'opti'?
So, 30 minutes after initially installing Quicktime and following your 20 easy steps, I've got a hacked-together fully-functional copy running! Wow, that's quality software.
Your excerpt from the patent simply describes one of the many steps in the whole process of displaying banner ads and tracking users with them. This particular step could be summarized as follows:
"Set a cookie so that other servers can read the cookie."
Nothing I've seen indicates that anything that you said relates to the part of the patent that you posted. Centralized banner ad distribution is just one facet of a banner advertising network, and your argument is tangential to the core issue; picking it apart and taking things out of context (not to mention misinterpreting them) won't help your case. Not only that, but the Slashdot editors' comments were extremely relevant.
Summary: Your comment is analagous to saying, "The sky is blue, so Slashdot is dumb."
The basis of your post is that there is centralized control over name services and that if that centralized control is lost, then the centralized control over the physical network will be lost. The premise of the latter part of this statement, that there is some centralized physical network, is entirely incorrect. For example, European Internet traffic probably doesn't pass through the United States en route to South Africa (not to say that it couldn't; I'm just pointing out that there's no friggin' global backbone, per se). Decentralized name services could be designed in such a way that they would be just fine and the Internet is already decentralized, physically and logically, for the scope of this discussion.
Conclusion: This isn't setting a precedent for a chaotic global communications breakdown. It's just the next logical step along the road to virtual nirvana.
I can't blame them. Given my past history of costing them lots of resources, they decided to drop me, even though none of the car wrecks/stolen vehicle incidents were my fault. Keeping on clients that are magnets for unncessary expenditures is not intelligent. Potential exposures are bad, as well.
Most ISPs' policies state that they can terminate access for any reason whatsoever at their sole discretion. In many other professional fields, these terms would be ridiculous. Nonetheless, ISPs have not been forced through competition to uphold any kind of standard. They want your money but not if it costs them resources (read bandwidth, customer complaints, downtime, network engineers, etc.).
Does this suck? Yes. Can ISPs afford NOT to take every measure possible to avoid a massive DoS that can cost them their business? No.
- You don't need a chip to do encryption
- Chips wouldn't be (and arne't) that expensive, anyhow
- You can put such chips on an ISA/PCI/USB interface, as they don't need to be on the motherboard (e.g. hardware that enhances SSL processing)
Did you even read the post you were replying to? How much do you think that individual spent to be able to apply encryption to so many aspects of his computing and communications methods? Virtually nothing.Your argument is not unreasonable; in fact, I think it's a common misconception. It's not some huge monumental ordeal to deploy encryption for yourself, casually. It should be obvious after reading the parent post that it encryption can be employed almost everywhere, cheaply and effectively, in the status quo.
Read this post if you think that saying "this document is copyrighted by me" means that it can't be reprinted; I think it very clearly explains why Slashdot is in the right:
http://slashdot.org/co mments.pl?sid=00/05/18/2015251&cid=236
I agree.
HTML parsing != natural language processing
Unless you're implying that you should be able to enter a random URL, like http://www.joescomputers.com/, and have it discover the price for a 10GB Seagate hard drive, or some specific item, without anyone having told the software the format with which Joe's Computers displays its prices, or even which page they're on, then you're just talking about searching through HTML, tables, etc., which is most certainly not AI.
Are you unable to judge an argument based on its logic and rationale? You don't have to be an expert on anything to be able to present intelligent concepts in an eloquent manner. I take people who are unknown, but make sense, more seriously than I take people who are well-know, but wrong.
You seem to take offense to his comments.. "preaching"? He's not preaching to anyone; he's formed an opinion, presented it, and proposed a solution. The basis of his argument is not "I saved the day once, so you should do what I say!" No part of the article hinges on the fact that he's smart man for doing what he did. He lets its merit stand for itself. Why don't you?
I thought the following snippet of information might be relevant to the discussion taking place. This is, of course, just for reference. Oh, and by continuing to read this post, you agree to Microsoft's EULA and authorize the immediate transferral of your soul to Microsoft Corporation:
s .
::= SEQUENCE {
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
Page 1 of 12
Microsoft Authorization Data Specification v. 1.0
for Microsoft Windows 2000 Operating Systems
April, 2000
© 2000 Microsoft Corporation.
All rights reserved.
Microsoft Confidential
Please review this Specification copy only if you licensed and downloaded it from Microsoft
Corporation's website; if you did not, please destroy this copy, but you are welcome to license the
Specification at http://www.microsoft.com/technet/security/kerbero
If you are an authorized licensee, when you downloaded the following Specification, you agreed
to the Agreement for Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000
Operating Systems (the "Agreement"). For your future reference, that Agreement is reproduced at
the end of this document.
Abstract
Microsoft Windows 2000 includes OS specific data in the Kerberos V5 authorization data field that is
used for authorization as described in the Kerberos revisions Internet Draft [1]. This data is used for
user logon and to create an access token. The access token is used by the system to enforce
access checking when attempting to reference objects. This document describes the structure of
the Windows 2000 specific authorization data that is carried in that field.
Top-Level PAC Structure
The PAC is generated by the KDC under the following conditions:
- during an AS request that has been validated with pre-authentication
- during a TGS request when the client has no PAC and the target is a service in the domain or a
ticket granting service (referral ticket).
The PAC itself is included in the IF-RELEVANT (ID 1) portion of the authorization data in a ticket.
Within the IF-RELEVANT portion, it is encoded as a KERB_AUTH_DATA_PAC with ID 128.
The PAC is defined as a C data type, with integers encoded in little-endian order. The PAC itself is
made up of several layers. The outer structure, contained directly in the authorization data, is as
follows. The top-level structure is the PACTYPE structure:
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
Page 2 of 12
typedef unsigned long ULONG;
typedef unsigned short USHORT;
typedef unsigned long64 ULONG64;
typedef unsigned char UCHAR;
typedef struct _PACTYPE {
ULONG cBuffers;
ULONG Version;
PAC_INFO_BUFFER Buffers[1];
} PACTYPE;
The fields are defined as follows:
cBuffers - contains the number of entries in the array Buffers
Version - this is version zero
Buffers - contains a conformant array of PAC_INFO_BUFFER structures
The PAC_INFO_BUFFER structure contains information about each piece of the PAC:
typedef struct _PAC_INFO_BUFFER {
ULONG ulType;
ULONG cbBufferSize;
ULONG64 Offset;
} PAC_INFO_BUFFER;
Type fields are defined as follows:
ulType - contains the type of data contained in this buffer. For Windows 2000, it may be one of the
following, which are explained further below:
#define PAC_LOGON_INFO 1
#define PAC_CREDENTIAL_TYPE 2
#define PAC_SERVER_CHECKSUM 6
#define PAC_PRIVSVR_CHECKSUM 7
#define PAC_CLIENT_INFO_TYPE 10
Offset - contains the offset to the beginning of the data, in bytes, from the beginning of the
PACTYPE structure. The data offset must by a multiple of 8. If the data pointed to by this field is
complex, the data is typically NDR encoded. If the data is simple (indicating it includes no pointer
types or complex structures) it is a little-endian format data structure.
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
Page 3 of 12
PAC Credential Information
PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential information for the client of
the Kerberos ticket. The data itself is contained in a KERB_VALIDATION_INFO structure, which is NDR
encoded. The output of the NDR encoding is placed in the PAC_INFO_BUFFER structure of type
PAC_LOGON_INFO.
typedef struct _KERB_VALIDATION_INFO {
FILETIME LogonTime;
FILETIME LogoffTime;
FILETIME KickOffTime;
FILETIME PasswordLastSet;
FILETIME PasswordCanChange;
FILETIME PasswordMustChange;
UNICODE_STRING EffectiveName;
UNICODE_STRING FullName;
UNICODE_STRING LogonScript;
UNICODE_STRING ProfilePath;
UNICODE_STRING HomeDirectory;
UNICODE_STRING HomeDirectoryDrive;
USHORT LogonCount;
USHORT BadPasswordCount;
ULONG UserId;
ULONG PrimaryGroupId;
ULONG GroupCount;
[size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
ULONG UserFlags;
ULONG Reserved[4];
UNICODE_STRING LogonServer;
UNICODE_STRING LogonDomainName;
PSID LogonDomainId;
ULONG Reserved1[2];
ULONG UserAccountControl;
ULONG Reserved3[7];
ULONG SidCount;
[size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids;
PSID ResourceGroupDomainSid;
ULONG ResourceGroupCount;
[size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP ResourceGroupIds;
} KERB_VALIDATION_INFO;
The fields are defined as follows:
LogonTime - the time the client last logged on.
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
Page 4 of 12
LogoffTime - the time at which the client's logon session should expire. If the logon session should
not expire, this field should be set to (0x7fffffff,0xffffffff).
KickOffTime - the time at which the server should forcibly logoff the client. If the client should not be
forced off, this field should be set to (0x7fffffff,0xffffffff). The ticket end time is a replacement for the
KickOffTime. The service ticket lifetime will never be longer than the KickOffTime for a user.
PasswordLastSet - the time the client's password was last set. If it was never set, this field is zero.
PasswordCanChange - the time at which the client's password is allowed to change. If there is no
restriction on when the client may change its password, this field should be set to the time of the
logon.
PasswordMustChange - the time at which the client's password expires. If it doesn't expire, this field
is set to (0x7fffffff,0xffffffff).
EffectiveName - This field contains the client's Windows 2000 UserName, stored in the Active
Directory in the SamAccountName property. This field is optional. If left blank the length, maxlength
and buffer are all zero.
FullName - this field contains the friendly name of the client, which is used only for display purpose
and not security purposes. This field is optional. If left blank the length, maxlength and buffer are all
zero.
LogonScript - This field contains the path to the client's logon script. This field is optional. If left blank
the length, maxlength and buffer are all zero.
ProfilePath - This field contains the path to the client's profile. This field is optional. If left blank the
length, maxlength and buffer are all zero.
HomeDirectory - This field contains the path to the client's home directory. It may be either a local
path name or a UNC path name. This field is optional. If left blank the length, maxlength and buffer
are all zero.
HomeDirectoryDrive - This field is only used if the client's home directory is a UNC path name. In that
case, the share on the remote file server is mapped to the local drive letter specified by this field.
This field is optional. If left blank the length, maxlength and buffer are all zero.
LogonCount - This field contains the count of how many times the client is currently logged on. This
statistic is not accurately maintained by Windows 2000 and should not be used.
BadPasswordCount - This field contains the number of logon or password change attempts with
bad passwords, since the last successful attempt.
* UserId - This field contains the relative Id for the client.
PrimaryGroupId - This field contains the relative ID for this client's primary group.
* GroupCount - This field contains the number of groups, within the client's domain, to which the
client is a member.
* GroupIds - This field contains an array of the relative Ids and attributes of the groups in the client's
domain of which the client is a member.
* UserFlags - This field contains information about which fields in this structure are valid. The two bits
that may be set are indicated below. Having these flags set indicates that the corresponding fields
in the KERB_VALIDATION_INFO structure are present and valid.
#define LOGON_EXTRA_SIDS 0x0020
#define LOGON_RESOURCE_GROUPS 0x0200
LogonServer - This field contains the NETBIOS name of the KDC which performed the AS ticket
request.
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
Page 5 of 12
LogonDomainName - This field contains the NETBIOS name of the client's domain.
* LogonDomainId - This field contains the SID of the client's domain. This field is used in conjunction
with the UserId, PrimaryGroupId,and GroupIds fields to create the user and group SIDs for the client.
UserAccountControl - This fields contains a bitfield of information about the client's account. Valid
values are:
#define USER_ACCOUNT_DISABLED (0x00000001)
#define USER_HOME_DIRECTORY_REQUIRED (0x00000002)
#define USER_PASSWORD_NOT_REQUIRED (0x00000004)
#define USER_TEMP_DUPLICATE_ACCOUNT (0x00000008)
#define USER_NORMAL_ACCOUNT (0x00000010)
#define USER_MNS_LOGON_ACCOUNT (0x00000020)
#define USER_INTERDOMAIN_TRUST_ACCOUNT (0x00000040)
#define USER_WORKSTATION_TRUST_ACCOUNT (0x00000080)
#define USER_SERVER_TRUST_ACCOUNT (0x00000100)
#define USER_DONT_EXPIRE_PASSWORD (0x00000200)
#define USER_ACCOUNT_AUTO_LOCKED (0x00000400)
#define USER_ENCRYPTED_TEXT_PASSWORD_ALLOWED (0x00000800)
#define USER_SMARTCARD_REQUIRED (0x00001000)
#define USER_TRUSTED_FOR_DELEGATION (0x00002000)
#define USER_NOT_DELEGATED (0x00004000)
#define USER_USE_DES_KEY_ONLY (0x00008000)
#define USER_DONT_REQUIRE_PREAUTH (0x00010000)
* SidCount - This field contains the number of SIDs present in the ExtraSids field. This field is only valid
if the LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
* ExtraSids - This field contains a list of SIDs for groups to which the user is a member. This field is only
valid if the LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
* ResouceGroupCount - This field contains the number of resource groups in the ResourceGroupIds
field. This field is only valid if the LOGON RESOURCE_GROUPS flag has been set in the UserFlags
field._
* ResourceGroupDomainSid - This field contains the SID of the resource domain. This field is used in
conjunction with the ResourceGroupIds field to create the group SIDs for the client.
* ResourceGroupIds - This field contains an array of the relative Ids and attributes of the groups in
the resource domain of which the resource is a member.
Fields marked with a '*' are used in the NT token.
When used in the KERB_VALIDATION_INFO, this is NDR encoded. The FILETIME type is defined as
follows:
typedef unsigned int DWORD;
typedef struct _FILETIME {
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME;
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
Page 6 of 12
Times are encoded as the number of 100 nanosecond increments since January 1, 1601, in UTC
time.
When used in the KERB_VALIDATION_INFO, this is NDR encoded. The UNICODE_STRING structure is
defined as:
typedef struct _UNICODE_STRING
USHORT Length;
USHORT MaximumLength;
[size_is(MaximumLength / 2), length_is((Length) / 2) ] USHORT * Buffer;
} UNICODE_STRING;
The Length field contains the number of bytes in the string, not including the null terminator, and the
MaximumLength field contains the total number of bytes in the buffer containing the string.
The GROUP_MEMBERSHIP structure contains the relative ID of a group and the corresponding
attributes for the group.
typedef struct _GROUP_MEMBERSHIP {
ULONG RelativeId;
ULONG Attributes;
} *PGROUP_MEMBERSHIP;
The group attributes must be:
#define SE_GROUP_MANDATORY (0x00000001L)
#define SE_GROUP_ENABLED_BY_DEFAULT (0x00000002L)
#define SE_GROUP_ENABLED (0x00000004L)
The SID structure is defined as follows:
typedef struct _SID_IDENTIFIER_AUTHORITY {
UCHAR Value[6];
} SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY;
The constant value for the NT Authority is:
#define SECURITY_NT_AUTHORITY {0,0,0,0,0,5}
typedef struct _SID {
UCHAR Revision;
UCHAR SubAuthorityCount;
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
Page 7 of 12
SID_IDENTIFIER_AUTHORITY IdentifierAuthority;
[size_is(SubAuthorityCount)] ULONG SubAuthority[*];
} SID, *PSID;
The SubAuthorityCount field contains the number of elements in the actual SubAuthority
conformant array. The maximum number of subauthorities allowed is 15.
The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and their corresponding
attributes:
typedef struct _KERB_SID_AND_ATTRIBUTES {
PSID Sid;
ULONG Attributes;
} KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES;
The attributes are the same as the group attributes defined above.
Client Information
The client information is included in the PAC to allow a server to verify that the PAC in a ticket is
applicable to the client of the ticket, which prevents splicing of PACs between tickets. The
PAC_CLIENT_INFO structure is included in a PAC_INFO_BUFFER of type PAC_CLIENT_INFO_TYPE.
typedef struct _PAC_CLIENT_INFO {
FILETIME ClientId;
USHORT NameLength;
WCHAR Name[1];
} PAC_CLIENT_INFO, *PPAC_CLIENT_INFO;
The fields are defined as follows:
ClientId - This field contains a conversion of the AuthTime field of the ticket into a FILETIME structure.
NameLength - This field contains the length, in bytes, of the Name field.
Name - This field contains the client name from the ticket, converted to Unicode and encoded
using "/" to separate parts of the client principal name with an "@" separating the client principal
name from the realm name. The string is not null terminated.
Supplemental Credentials
The KDC may return supplemental credentials in the PAC as well. Supplemental credentials are
data associated with a security package that is private to that package. They can be used to
return an appropriate user key that is specific to that package for the purposes of authentication.
Supplemental creds are only used in conjunction with PKINIT[2]. Supplemental credentials are
always encrypted using the client key. The PAC_CREDENTIAL_DATA structure is NDR encoded and
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
Page 8 of 12
then encrypted with the key used to encrypt the KDC's reply to the client. The
PAC_CREDENTIAL_INFO structure is included in PAC_INFO_BUFFER of type PAC_CREDENTIAL_TYPE.
Supplemental credentials for a single package are NDR encoded as follows:
typedef struct _SECPKG_SUPPLEMENTAL_CRED {
UNICODE_STRING PackageName;
ULONG CredentialSize;
[size_is(CredentialSize)]PUCHAR Credentials;
} SECPKG_SUPPLEMENTAL_CRED, *PSECPKG_SUPPLEMENTAL_CRED;
The fields in this structure are defined as follows:
PackageName - This field contains the name of the package for which credentials are presented.
CredentialSize - This field contains the length, in bytes, of the presented credentials.
Credentials - This field contains a pointer to the credential data.
The set of all supplemental credentials is NDR encoded in a PAC_CREDENTIAL_DATA structure:
typedef struct _PAC_CREDENTIAL_DATA {
ULONG CredentialCount;
[size_is(CredentialCount)] SECPKG_SUPPLEMENTAL_CRED Credentials[*];
} PAC_CREDENTIAL_DATA, *PPAC_CREDENTIAL_DATA;
The fields are defined as follows:
CredentialCount - This field contains the number of credential present in the Credentials array.
Credentials - This field contains an array of the presented supplemental credentials.
The PAC_CREDENTIAL_DATA structure is NDR encoded and then encrypted with the key used to
encrypt the KDC reply. The resulting buffer is returned in the following structure:
typedef struct _PAC_CREDENTIAL_INFO {
ULONG Version;
ULONG EncryptionType;
UCHAR Data[1];
} PAC_CREDENTIAL_INFO, *PPAC_CREDENTIAL_INFO;
The fields are defined as follows:
Version - This field contains the version field of the key used to encrypt the data, or zero if the field is
not present.
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
Page 9 of 12
EncryptType - This field contains the encryption type used to encrypt the data. The encryption type
uses the same values as the defined encryptions types for Kerberos [1].
Data - This field contains an array of bytes containing the encrypted supplemental credential data.
Signatures
The PAC contains two digital signatures: one using the key of the server, and one using the key of
the KDC. The signatures are present for two reasons. First, the signature with the server's key is
present to prevent a client from generating their own PAC and sending it to the KDC as encrypted
authorization data to be included in tickets. Second, the signature with the KDC's key is present to
prevent an untrusted service from forging a ticket to itself with an invalid PAC. The two signatures
are sent in PAC_INFO_BUFFERs of type PAC_SERVER_CHECKSUM and PAC_KDC_CHECKSUM
respectively.
The signatures are contained in the following structure:
typedef struct _PAC_SIGNATURE_DATA {
ULONG SignatureType;
UCHAR Signature[1];
} PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA;
The fields are defined as follows:
SignatureType - This field contains the type of checksum used to create a signature. The checksum
must be a keyed checksum.
Signature - This field consists of an array of bytes containing the checksum data. The length of bytes
may be determined by the wrapping PAC_INFO_BUFFER structure.
For the server's checksum, the key used to generate the signature should be the same key used to
encrypt the ticket. Thus, if the enc_tkt_in_skey option is used, the session key from the server's TGT
should be used. The Key used to encrypt ticket-granting tickets is used to generate the KDC's
checksum.
The checksums are computed as follows:
1. The complete PAC is built, including space for both checksums
2. The data portion of both checksums is zeroed.
3. The entire PAC structure is checksummed with the server's key, and the result is stored in the
server's checksum structure.
4. The server's checksum is then checksummed with the KDC's key.
5. The checksum with the KDC key is stored in the KDC's checksum structure.
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
Page 10 of 12
PAC Request Pre-Auth Data
Normally, the PAC is included in every pre-authenticated ticket received from an AS request.
However, a client may also explicitly request either to include or to not include the PAC. This is done
by sending the PAC-REQUEST preauth data.
KERB-PA-PAC-REQUEST
include-pac[0] BOOLEAN -- if TRUE, and no PAC present,
-- include PAC.
---If FALSE, and PAC
-- present, remove PAC
}
The fields are defined as follows:
include-pac - This field indicates whether a PAC should be included or not. If the value is TRUE, a
PAC will be included independent of other preauth data. If the value is FALSE, then no PAC will be
included, even if other preauth data is present.
The preauth ID is:
#define KRB5_PADATA_PAC_REQUEST 128
References
1 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network Authentication Service (V5)", draft-ietf-cat-kerberos-
revisions-05.txt, March 10, 2000
2 Tung, B., Hur, M., Medvinsky, A., Medvinsky, S., Wray, J., Trostle, J., " Public Key Cryptography for
Initial Authentication in Kerberos", draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
Page 11 of 12
Legal Notice
This Specification is provided to you pursuant to the terms and conditions of the Agreement for
Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems (the
"Agreement") for the sole purpose of allowing you to review the Specification for security analysis,
as further specified in the Agreement. If you have not downloaded the Specification from
Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an
authorized licensee of the Specification.
For your reference, the Agreement is reproduced below.
Agreement for Microsoft Authorization Data Specification v. 1.0
for Microsoft Windows 2000 Operating Systems
IMPORTANT--READ CAREFULLY: This Microsoft Agreement ("Agreement") is a legal agreement between you (either
an individual or a single entity) and Microsoft Corporation ("Microsoft") for the version of the Microsoft
specification identified above which you are about to download ("Specification"). BY DOWNLOADING,
COPYING OR OTHERWISE USING THE SPECIFICATION, YOU AGREE TO BE BOUND BY THE TERMS OF THIS
AGREEMENT. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, DO NOT DOWNLOAD, COPY, OR USE THE
SPECIFICATION.
The Specification is owned by Microsoft or its suppliers and is protected by copyright laws and international
copyright treaties, as well as other intellectual property laws and treaties.
1. LICENSE.
(a) Provided that you comply with all terms and conditions of this Agreement, including without limitation
subsections (b)-(d) below, Microsoft grants to you the following non-exclusive, worldwide, royalty-free,
non-transferable, non-sublicenseable license, under any copyrights or trade secrets owned or
licensable by Microsoft without payment of consideration to unaffiliated third parties, to reproduce
and use a reasonable number of copies of the Specification in its entirety for the sole purpose of
reviewing the Specification for security analysis. By way of clarification of the foregoing, the
Specification is provided to you solely for your informational purposes (for review as specified above)
and, pursuant to this Agreement, Microsoft does not grant you any right to implement this
Specification.
(b) The Specification is confidential information and a trade secret of Microsoft. Therefore, you may not
disclose the Specification to anyone else (except as specifically allowed below), and you must take
reasonable security precautions, at least as great as the precautions you take to protect your own
confidential information, to keep the Specification confidential. If you are an entity, you may disclose
the Specification to your full-time employees on a need to know basis, provided that you have
executed appropriate written agreements with your employees sufficient to enable you to comply
with the terms of this Agreement. You are also permitted to discuss the Specification with anyone else
who has downloaded the Specification and agreed to these terms and conditions.
(c) You may not remove any of the copyright notices or other legends from any copy of the
Specification.
(d) Microsoft reserves all other rights it may have in the Specification and any intellectual property therein.
Microsoft may have patents or pending patent applications, trademarks, copyrights, trade secrets or
other intellectual property rights covering subject matter in the Specification. The furnishing of this
Specification does not give you any license to these patents, trademarks, trade secrets, copyrights, or
other intellectual property rights, except as specifically set forth in subsection (a) above with respect
to certain copyrights and trade secrets.
Windows 2000 Kerberos Authorization Data April 2000
© 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
Page 12 of 12
2. ADDITIONAL LIMITATIONS.
(a) The foregoing license is applicable only to the version of the Specification which you are about to
download. It does not apply to any additional versions of or extensions to the Specification.
(b) Without prejudice to any other rights, Microsoft may terminate this Agreement if you fail to comply
with its terms and conditions. In such event you must destroy all copies of the Specification in your
possession or under your control.
3. INTELLECTUAL PROPERTY RIGHTS. All ownership, title and intellectual property rights in and to the Specification
are owned by Microsoft or its suppliers.
4. DISCLAIMER OF WARRANTIES. To the maximum extent permitted by applicable law, Microsoft and its
suppliers provide the Specification (and all intellectual property therein) AS IS AND WITH ALL FAULTS, and
hereby disclaim all warranties and conditions, either express, implied or statutory, including, but not limited to,
any (if any) implied warranties or conditions of merchantability, of fitness for a particular purpose, and of
accuracy or completeness, all with regard to the Specification and any intellectual property therein. ALSO,
THERE IS NO WARRANTY OR CONDITION OF TITLE OR NON-INFRINGEMENT WITH REGARD TO THE SPECIFICATION
AND ANY INTELLECTUAL PROPERTY THEREIN.
5. EXCLUSION OF DIRECT, INCIDENTAL, CONSEQUENTIAL AND CERTAIN OTHER DAMAGES. TO THE MAXIMUM
EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY
DIRECT, SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, BUT NOT
LIMITED TO, DAMAGES FOR LOSS OF PROFITS OR FOR BUSINESS INTERRUPTION) ARISING OUT OF OR IN ANY WAY
RELATED TO THE USE OF OR INABILITY TO USE THE SPECIFICATION, ANY INTELLECTUAL PROPERTY THEREIN, OR
OTHERWISE UNDER OR IN CONNECTION WITH ANY PROVISION OF THIS AGREEMENT, EVEN IF MICROSOFT OR ANY
SUPPLIER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
6. LIMITATION OF LIABILITY AND REMEDIES. Notwithstanding any damages that you might incur for any reason
whatsoever, the entire liability of Microsoft and any of its suppliers under any provision of this Agreement and
your exclusive remedy for all of the foregoing shall be limited to the greater of the amount actually paid by
you for the Specification or U.S.$5.00. The foregoing limitations, exclusions and disclaimers shall apply to the
maximum extent permitted by applicable law, even if any remedy fails its essential purpose.
7. APPLICABLE LAW. This Agreement is governed by the laws of the State of Washington.
8. ENTIRE AGREEMENT. This Agreement is the entire agreement between you and Microsoft relating to the
Specification and it supersedes all prior or contemporaneous oral or written communications, proposals and
representations with respect to the Specification.
Your argument is poor. You have no link between the government and this virus, yet you blame them for it.
Your proposed "solution" is equally asinine. The notion of commercializing virii (which, by the way, is an idiotic idea, in and of itself) is inherently tangential to the issue of the ILOVEYOU virus. It is phenomenally feasible for the following to occur:
- we elect to put your ridiculous system in place
- policies are changed world-wide to fit your schema
- an entire industry is born centered around the crap you outline in your post (commercialization of virii-creation and fixing, etc.)
- some loser from the Phillipines writes a virus, it spreads, and screws up lots of computers
Wow! That's a great idea you've got there. It does absolutely nothing to address the real issue: preventing virii like this from affecting so many people in such a drastic way.No one asked you to be excited. The purpose of the article is to make you aware of the fact that this product is coming. That's all.
Trollmastah, a well-known participator in the on-line forum, Slashdot, although once dismissed as a so-called "troll," has risen to the top of the turnip truck by soliciting offers from record producers across the country. They are professing a newly rejuvenated interest in a funky-fresh style among computer kiddies that has been tagged as "digital bands."
No one actually knows what a digital band is, but they're pretty sure it's really stupid.
In summary, I offer the following lyrics from the up-and-coming digital band, Slashdot This, in order to retain topicality (i.e. not off-topic):
UNIX.com: It's What's For Dinner
Did it ever occur to you that we wouldn't be forced to make such ignorant choices (internet or porn: one or the other, but not both) if it weren't for stupid people like you?
It isn't flamebait, it's the truth.
Moderate this comment up.
"Undegreed" is the most worthless term I've ever witnessed the application of in reference to the ability of an individual to write quality code.
I'm not going to purvey any content in this post other than the degree to which I am dumbfounded by this assertion: VERY.
Wow, Bob. You're astonishing.