Not quite. Most RFID tags I've worked with have a unique hardware ID encoded in them. If you need to track individual items seperately, the easy way is to just use that hardware ID and tie it to the item's record via an ID-code column in the database.
Also, if the government was interested in tracking someone via this, the first thing they'd subpoena would be the library's patron record and database of tag-to-title information. Once they have that they can find which tags belong to the books you currently have checked out and start tracking those tag IDs.
ICANN acted without a hearing? Yaright. How much of a hearing did Verisign give ICANN before Verisign unilaterally messed with DNS? Sauce for the goose and all.
I want Mr. Lewis' e-mail address. I need to practice frying someone to a crisp without ever resorting to personal attacks, foul language or other such low-class behavior.
There's only one problem with a parallel loader: system load. You've seen it before. When you run a massive compile or some other heavy-duty job, the system slows down. When you're copying tons of files around, disk access from other programs slows down. The same thing happens during boot: the more things you're starting in parallel the harder the disk and CPU get hit and the slower each individual service starts.
Best exemplified by his statement that runlevels aren't important. Maybe runlevels as explicit runlevels aren't, but the idea is. Remember, we started with one big monolithic init script, and runlevels and such were introduced because lots and lots of admins had the same need: to start a system with a predefined set of things turned on or not, eg. a single-user mode with no system services running so major things can be replaced without interference or major system breakage that prevents normal startup from happening can be fixed. If he leaves out "profiles", they will be reintroduced for the same reasons runlevels were introduced.
Forget that the Web exists. 90% of the Internet doesn't involve the Web. Three-quarters of it doesn't even involve human beings. Therein lies the rub. "Similar function" means different things depending on context. For example, the SNMP client in a LAN network monitoring box has a very different idea of what might be a correct alternative than the program-driven automated FTP application trying to grab today's payroll files or the SCP transfer of a password file. The problem is that DNS doesn't know which one it is, so it can't sensibly pick which one it should assume it's dealing with.
Correcting typos is simply too application-specific. It's why telephone books don't list possible alternative numbers for misspelled names. If you need to find the phone number for a given name, you look in the phone book. If you need to figure out which name you should be looking up, you call directory assistance or look in the yellow pages or use some other service designed to let you find names.
This is Verisign's mistake. They took a fundamental lookup service that needs to work correctly for a wide range of applications and proceeded to graft functionality onto it that assumed that it was used by one and only one application (web browsers) and used in one and only one way (a human being watching a screen). The resulting train-wreck was utterly predictable.
If you go to look up a phone number for someone and they aren't listed, you want to be told they aren't listed, not given the number for someone else with a similar name.
DNS is the phone book of the Internet. What you're describing is nice when looked at just as part of browsing the Web, but not as part of FTP or LDAP lookup or NTP synchronization.
Except that that's not even what SCO's claiming. SCO's claiming that IBM copyrighted a function and added it to Linux, and that because IBM also licensed SCO to use that function that IBM no longer has any right to let anyone else use that function without SCO being paid.
Problem is, I don't usually promise such things. When I buy something, I promise to obey the restrictions of copyright law. When I go to use my copy, then, I find out I have to agree after the fact to additional conditions not part of the contract of sale. TCPA insures that my computer will enforce those terms whether or not I've agreed to them. I'd be less inclined against TCPA-type things if they worked the other way as well, enforcing the rights of the computer owner as well as the software owner.
No, this was the 2 certificates that were recognized by Windows and IE as valid Microsoft certificates. You didn't have to decide to trust them, they were already trusted by default by Windows and IE. A seperate problem with the revocation bits made it impossible to simply revoke them short of revoking Microsoft's own primary certificate (which would have invalidated all Microsoft certificates). Fixing the problem involved replacing the entire master certificate store in Windows.
I just haven't been too intimate with the actual servers in the last couple of years. When I was, the root servers really did serve up the.com/.net/.org zones directly. I think you're right, I should have said gTLD and ccTLD servers.
The problem with most "trusted computing" proposals so far is that "trusted" is an accurate description of them. It's just an imcomplete description. They aren't about insuring that you, the owner of the computer, can trust the computer or the software on it. They're about insuring that third parties can trust your computer to do what they tell it to do. The proponents omit that part because they know all too well that if they did say all of what they meant that Joe Sixpack would scream bloody murder and refuse to have anything to do with it.
Just to make a point, imagine a virus that couldn't be removed from a computer. Under the "trusted computing" proposals someone could do exactly that by tagging the virus as "user does not have permission to delete" and the computer itself would prevent the AV software from removing the virus.
Frankly I think ICANN should formally seperate the registrars and the root DNS registry. Make these changes to the rules:
The root DNS registry operator may not themselves be a DNS registrar, nor may they have any affiliation with or organizational ties to one. The registry operator receives a fee per domain for operating the registry, there should be no incentives other than this fee affecting their operation of the registry. It's too critical to the rest of the Internet. If those fees alone aren't enough to make it worthwhile for any company to run the registry, then perhaps the registry shouldn't be run by a company.
The registry operator may not run a publically-accessible root nameserver (but they may run one for purposes of transfering root zone data to root nameserver operators, so long as it is not listed in the root hints file). That would make it so that changes in the root zones such as adding wildcard records could, at least in principle, be filtered out by the root server operators before reaching the Internet at large.
No one entity may, either directly or through affiliated entities, control more than 3 root nameservers or 25% of the root nameservers, whichever is less. That would hopefully insure enough variety in root nameserver operators that bad changes (eg. the wildcards addition or things that required specific non-standard DNS server software) would be rejected by at least one operator.
MSN Search won't replace Google for one reason: MS is constitutionally incapable of leaving their own interests, financial and otherwise, out of the results. People prefer one search engine over another mainly based on whether it returns accurate, unbiased, relevant results, and keeps the paid-for stuff out of the way of the actual results. MS won't be able to resist trying to "improve" things by putting the paid-for listings in with the results (where they're more likely to be clicked on, and therefore more valuable to Microsoft because they can be sold for a higher price), biasing the results in favor of their own sites (which would result in increased value for Microsoft for those sites) and so on. Given alternatives, people will tend to migrate towards the one that gives priority to their interests and away from the one that considers their interests secondary.
I don't know about your system, but on mine "ls -lh" reports K using 1024 bytes/K and M using 1024 K/M. "df -k" and "df -m" also report in the same sort of units. 1K = 1024 and 1M = 1024K have been accepted in computer usage as long as I've been dealing with computers (a bit over two and a half decades).
BTW, if a package in a store advertised itself as containing 16 pounds of something, with a small note on the back of the box that "1 pound means 1 ounce", you'd probably win a suit claiming this was deceptive.
The problem with that delegation scheme is that while you can add wildcard records to a zone, IIRC there's no way to do wildcard delegation in BIND. To make it work Verisign would have to either add real delegation records for every possible domain name to the.com and.net zones (infeasible) or modify BIND and convince all the non-Verisign people who run the actual root nameservers to install that modified BIND. At least one of the roots is run by ISC itself, and I don't see them obliging Verisign that way. As long as at least some of the roots don't run the modified software, I just edit named.ca to remove Verisign's servers and I'm back to normal.
McCloud is right, people will pay the kind of sums he's talking about for the kind of content he's talking about. It's already happening. The caveat is that McCloud's talking about a certain type of content, that satisfies one of two conditions:
It's immediately recognized by many people and already known to have value, and the buyer's basically already looking for that specific content.
It's content available only from one source.
Shirky's right, because the majority of the Web doesn't satisfy either of those two conditions. If I'm looking for information on a particular aspect of HTML, or information on how to tie a particular necktie knot, then I'm unlikely to want any one particular source of that information enough to pay for it when it's available from another source without paying. The kind of stuff McCloud's pointing to as examples of why micropayments will work may be large in absolute numbers, but it's a small fraction of the entire Web and the vast majority of the Web is the kind of stuff Shirky's talking about.
There's also a third hurdle: whether or not I can pay. McCloud's site is a good example: I can't pay no matter how much I might like to, because I don't have an account with the only system he accepts. So I do have a big hurdle: I have to like his comic in particular enough to justify going and getting a BitPass account. Before micropayments become common one of two things will have to happen: either it'll have to reduce to only one or two systems so I don't have to keep opening new accounts all the time, or the sellers will have to accept enough systems that most of the time I'll already have an account with one they take. I'd note that this is a situation that came up with credit cards as well, and got solved by the world reducing to 2 big ones (Visa and MC) and 2 smaller ones (Amex and Discover) so that most people who have a card at all have one of them (even ATM cards now are either Visa or MC).
That won't work. For example, I have an account on a system that can be used to pay on-line, PayPal. But I can't buy McCloud's work, because he doesn't accept PayPal. I don't have to just have a micropayment account, I have to have one that the person I'm trying to buy from accepts. So unless there's only one or two systems out there that everyone accepts, there's the barrier of having to set up Yet Another Banking Account.
Look at it this way: if the consumer's choice to install a program that substitutes pop-ups trumps the web site's desire to display their pop-ups, then my choice to install software that blocks pop-ups period also trumps the web site's desire to display their pop-ups.
The ISP is to the user what the backbone provider is to the ISP. The ISP should no more be filtering ports than the backbone provider should be filtering ports. If users not knowing what they're doing is becoming too much of a problem, or is putting other users at too much risk, then the ISP should be doing what we require for cars: users must prove a certain level of knowedge and ability to safely operate a computer/car before they're allowed on the Internet/road.
Unfortunately, this isn't an ideal world. Until people stop whining that, effectively, "Why do I have to know how to drive? I just want to go places in my car!", we may have to live with this.
My guess would be that the creator of the document could always alter the DRM settings. The problem would come when either the creator of the document isn't around anymore (think key employee leaving the company) or, worse, the creator of the document has an interest in not allowing that use of a document, eg:
A sales rep making representations about a product to make a sale but not wanting a written record of them that could come back to haunt him when the product doesn't live up to the promises.
A client saying "It's OK to leave X out." to get the price down but intending to point out later that X was in the original spec and demanding that it be put in at no additional charge.
An executive making a representation about the company's financial state to get the board to go along with him or to run up the stock price, who doesn't want a written record when he takes his money and runs and the representation turns out to be false (see Enron, WorldCom et. al.).
The accidental problems caused by DRM pale in comparison to the ability to literally make the written record disappear or be invisible to certain select people.
Get the company legal department and managers involved. Point out that company policy and/or the law requires certain things be done with documents, eg. certain finance-related documents must be kept for certain lengths of time or the company can face fines, certain documents must have file copies made, policy dictates that certain people receive copies of documents. The DRM features in the new Office software may, depending on what the sender sets, prevent the required things from being done. If the creator specifies "no copies", archive copies of financial and/or legal documents couldn't be made which must be made. Since some of the senders may not be within the company and may very well have good reason to prevent a record being made, this could put the company in the position of being legally liable while not being able to control their liability. That's the kind of stuff that makes lawyers nervous, and the lawyers have the ear of the board of directors and executives.
If MS includes distributed-computing features in Longhorn, I predict a slew of viruses and worms that take advantage of that to spread. They'll inevitably fail to segregate the client and server code sufficiently and they'll provide for automated loading of the code to be executed to the server that'll execute it, and that'd be all I'd need to create a really nasty self-spreading worm.
The obvious one: if we can't trust spammers not to forge sender addresses and such in SMTP, why should we suddenly trust them to supply correct policy codes in AMTP?
What do you do about individuals getting certificates? There's an increasing number of people who run their own MTA as part of a client setup, bypassing their ISP's mail servers to deliver personal mail directly to the recipient's mail system. This produces the need for an efficient, cheap way of handling a large number of certificates.
Who do you trust to give out the certificates? You have to trust the CAs to never provide havens to spammers by giving them certificates on demand with slightly different names, for example. Is there any authority we can trust to do this?
In section 4.1 of the RFC, what do you do about mail servers that legitimately have more than one name but only one PTR record? Basically, mail servers that server more than one domain. It'd be reasonable for them to announce themselves as being the domain of the mail they're currently sending, but that would cause the certificate security check to fail. You'd have to require that the server uses only it's primary name in the EHLO line, which may be a problem in some cases.
Nobody (for the most part) uses an IM network because of the client. They use it because of the network and the people who use that network. MS should simply acknowledge that in their business model. There's a simple way to do that: stop licensing the client and start licensing access to the network. You buy Windows, it comes with a license to use the network automatically. You don't use Windows, you'll need to get a license from somewhere else (like buying one from MS). End of problem.
MS, of course, will never even consider this, because the problem from their PoV isn't third-party clients accessing their network, it's clients other than theirs existing at all.
Slashdot Mirror
Not quite. Most RFID tags I've worked with have a unique hardware ID encoded in them. If you need to track individual items seperately, the easy way is to just use that hardware ID and tie it to the item's record via an ID-code column in the database.
Also, if the government was interested in tracking someone via this, the first thing they'd subpoena would be the library's patron record and database of tag-to-title information. Once they have that they can find which tags belong to the books you currently have checked out and start tracking those tag IDs.
ICANN acted without a hearing? Yaright. How much of a hearing did Verisign give ICANN before Verisign unilaterally messed with DNS? Sauce for the goose and all.
I want Mr. Lewis' e-mail address. I need to practice frying someone to a crisp without ever resorting to personal attacks, foul language or other such low-class behavior.
There's only one problem with a parallel loader: system load. You've seen it before. When you run a massive compile or some other heavy-duty job, the system slows down. When you're copying tons of files around, disk access from other programs slows down. The same thing happens during boot: the more things you're starting in parallel the harder the disk and CPU get hit and the slower each individual service starts.
Best exemplified by his statement that runlevels aren't important. Maybe runlevels as explicit runlevels aren't, but the idea is. Remember, we started with one big monolithic init script, and runlevels and such were introduced because lots and lots of admins had the same need: to start a system with a predefined set of things turned on or not, eg. a single-user mode with no system services running so major things can be replaced without interference or major system breakage that prevents normal startup from happening can be fixed. If he leaves out "profiles", they will be reintroduced for the same reasons runlevels were introduced.
Forget that the Web exists. 90% of the Internet doesn't involve the Web. Three-quarters of it doesn't even involve human beings. Therein lies the rub. "Similar function" means different things depending on context. For example, the SNMP client in a LAN network monitoring box has a very different idea of what might be a correct alternative than the program-driven automated FTP application trying to grab today's payroll files or the SCP transfer of a password file. The problem is that DNS doesn't know which one it is, so it can't sensibly pick which one it should assume it's dealing with.
Correcting typos is simply too application-specific. It's why telephone books don't list possible alternative numbers for misspelled names. If you need to find the phone number for a given name, you look in the phone book. If you need to figure out which name you should be looking up, you call directory assistance or look in the yellow pages or use some other service designed to let you find names.
This is Verisign's mistake. They took a fundamental lookup service that needs to work correctly for a wide range of applications and proceeded to graft functionality onto it that assumed that it was used by one and only one application (web browsers) and used in one and only one way (a human being watching a screen). The resulting train-wreck was utterly predictable.
If you go to look up a phone number for someone and they aren't listed, you want to be told they aren't listed, not given the number for someone else with a similar name.
DNS is the phone book of the Internet. What you're describing is nice when looked at just as part of browsing the Web, but not as part of FTP or LDAP lookup or NTP synchronization.
Except that that's not even what SCO's claiming. SCO's claiming that IBM copyrighted a function and added it to Linux, and that because IBM also licensed SCO to use that function that IBM no longer has any right to let anyone else use that function without SCO being paid.
Problem is, I don't usually promise such things. When I buy something, I promise to obey the restrictions of copyright law. When I go to use my copy, then, I find out I have to agree after the fact to additional conditions not part of the contract of sale. TCPA insures that my computer will enforce those terms whether or not I've agreed to them. I'd be less inclined against TCPA-type things if they worked the other way as well, enforcing the rights of the computer owner as well as the software owner.
No, this was the 2 certificates that were recognized by Windows and IE as valid Microsoft certificates. You didn't have to decide to trust them, they were already trusted by default by Windows and IE. A seperate problem with the revocation bits made it impossible to simply revoke them short of revoking Microsoft's own primary certificate (which would have invalidated all Microsoft certificates). Fixing the problem involved replacing the entire master certificate store in Windows.
I just haven't been too intimate with the actual servers in the last couple of years. When I was, the root servers really did serve up the .com/.net/.org zones directly. I think you're right, I should have said gTLD and ccTLD servers.
and just how, pray tell, would the author of the virus get his code signed by the TCG?
Perhaps in the same way that a bunch of black-hats could, at one point, sign ActiveX controls with a genuine Verisign-issued Microsoft certificate? :)
The problem with most "trusted computing" proposals so far is that "trusted" is an accurate description of them. It's just an imcomplete description. They aren't about insuring that you, the owner of the computer, can trust the computer or the software on it. They're about insuring that third parties can trust your computer to do what they tell it to do. The proponents omit that part because they know all too well that if they did say all of what they meant that Joe Sixpack would scream bloody murder and refuse to have anything to do with it.
Just to make a point, imagine a virus that couldn't be removed from a computer. Under the "trusted computing" proposals someone could do exactly that by tagging the virus as "user does not have permission to delete" and the computer itself would prevent the AV software from removing the virus.
Frankly I think ICANN should formally seperate the registrars and the root DNS registry. Make these changes to the rules:
MSN Search won't replace Google for one reason: MS is constitutionally incapable of leaving their own interests, financial and otherwise, out of the results. People prefer one search engine over another mainly based on whether it returns accurate, unbiased, relevant results, and keeps the paid-for stuff out of the way of the actual results. MS won't be able to resist trying to "improve" things by putting the paid-for listings in with the results (where they're more likely to be clicked on, and therefore more valuable to Microsoft because they can be sold for a higher price), biasing the results in favor of their own sites (which would result in increased value for Microsoft for those sites) and so on. Given alternatives, people will tend to migrate towards the one that gives priority to their interests and away from the one that considers their interests secondary.
I don't know about your system, but on mine "ls -lh" reports K using 1024 bytes/K and M using 1024 K/M. "df -k" and "df -m" also report in the same sort of units. 1K = 1024 and 1M = 1024K have been accepted in computer usage as long as I've been dealing with computers (a bit over two and a half decades).
BTW, if a package in a store advertised itself as containing 16 pounds of something, with a small note on the back of the box that "1 pound means 1 ounce", you'd probably win a suit claiming this was deceptive.
The problem with that delegation scheme is that while you can add wildcard records to a zone, IIRC there's no way to do wildcard delegation in BIND. To make it work Verisign would have to either add real delegation records for every possible domain name to the .com and .net zones (infeasible) or modify BIND and convince all the non-Verisign people who run the actual root nameservers to install that modified BIND. At least one of the roots is run by ISC itself, and I don't see them obliging Verisign that way. As long as at least some of the roots don't run the modified software, I just edit named.ca to remove Verisign's servers and I'm back to normal.
McCloud is right, and Shirky is right.
McCloud is right, people will pay the kind of sums he's talking about for the kind of content he's talking about. It's already happening. The caveat is that McCloud's talking about a certain type of content, that satisfies one of two conditions:
Shirky's right, because the majority of the Web doesn't satisfy either of those two conditions. If I'm looking for information on a particular aspect of HTML, or information on how to tie a particular necktie knot, then I'm unlikely to want any one particular source of that information enough to pay for it when it's available from another source without paying. The kind of stuff McCloud's pointing to as examples of why micropayments will work may be large in absolute numbers, but it's a small fraction of the entire Web and the vast majority of the Web is the kind of stuff Shirky's talking about.
There's also a third hurdle: whether or not I can pay. McCloud's site is a good example: I can't pay no matter how much I might like to, because I don't have an account with the only system he accepts. So I do have a big hurdle: I have to like his comic in particular enough to justify going and getting a BitPass account. Before micropayments become common one of two things will have to happen: either it'll have to reduce to only one or two systems so I don't have to keep opening new accounts all the time, or the sellers will have to accept enough systems that most of the time I'll already have an account with one they take. I'd note that this is a situation that came up with credit cards as well, and got solved by the world reducing to 2 big ones (Visa and MC) and 2 smaller ones (Amex and Discover) so that most people who have a card at all have one of them (even ATM cards now are either Visa or MC).
That won't work. For example, I have an account on a system that can be used to pay on-line, PayPal. But I can't buy McCloud's work, because he doesn't accept PayPal. I don't have to just have a micropayment account, I have to have one that the person I'm trying to buy from accepts. So unless there's only one or two systems out there that everyone accepts, there's the barrier of having to set up Yet Another Banking Account.
Look at it this way: if the consumer's choice to install a program that substitutes pop-ups trumps the web site's desire to display their pop-ups, then my choice to install software that blocks pop-ups period also trumps the web site's desire to display their pop-ups.
The ISP is to the user what the backbone provider is to the ISP. The ISP should no more be filtering ports than the backbone provider should be filtering ports. If users not knowing what they're doing is becoming too much of a problem, or is putting other users at too much risk, then the ISP should be doing what we require for cars: users must prove a certain level of knowedge and ability to safely operate a computer/car before they're allowed on the Internet/road.
Unfortunately, this isn't an ideal world. Until people stop whining that, effectively, "Why do I have to know how to drive? I just want to go places in my car!", we may have to live with this.
My guess would be that the creator of the document could always alter the DRM settings. The problem would come when either the creator of the document isn't around anymore (think key employee leaving the company) or, worse, the creator of the document has an interest in not allowing that use of a document, eg:
- A sales rep making representations about a product to make a sale but not wanting a written record of them that could come back to haunt him when the product doesn't live up to the promises.
- A client saying "It's OK to leave X out." to get the price down but intending to point out later that X was in the original spec and demanding that it be put in at no additional charge.
- An executive making a representation about the company's financial state to get the board to go along with him or to run up the stock price, who doesn't want a written record when he takes his money and runs and the representation turns out to be false (see Enron, WorldCom et. al.).
The accidental problems caused by DRM pale in comparison to the ability to literally make the written record disappear or be invisible to certain select people.Get the company legal department and managers involved. Point out that company policy and/or the law requires certain things be done with documents, eg. certain finance-related documents must be kept for certain lengths of time or the company can face fines, certain documents must have file copies made, policy dictates that certain people receive copies of documents. The DRM features in the new Office software may, depending on what the sender sets, prevent the required things from being done. If the creator specifies "no copies", archive copies of financial and/or legal documents couldn't be made which must be made. Since some of the senders may not be within the company and may very well have good reason to prevent a record being made, this could put the company in the position of being legally liable while not being able to control their liability. That's the kind of stuff that makes lawyers nervous, and the lawyers have the ear of the board of directors and executives.
If MS includes distributed-computing features in Longhorn, I predict a slew of viruses and worms that take advantage of that to spread. They'll inevitably fail to segregate the client and server code sufficiently and they'll provide for automated loading of the code to be executed to the server that'll execute it, and that'd be all I'd need to create a really nasty self-spreading worm.
Nobody (for the most part) uses an IM network because of the client. They use it because of the network and the people who use that network. MS should simply acknowledge that in their business model. There's a simple way to do that: stop licensing the client and start licensing access to the network. You buy Windows, it comes with a license to use the network automatically. You don't use Windows, you'll need to get a license from somewhere else (like buying one from MS). End of problem.
MS, of course, will never even consider this, because the problem from their PoV isn't third-party clients accessing their network, it's clients other than theirs existing at all.