ICANN is subsidizing this garbage industry to the tune of about $300,000,000 to $500,000,000 per year - yes every year - out of our pockets.
This is because the "domainers" get free domain name registration tryouts while the rest of us are forced to pay a ICANN-fiat "registry fee" of about $7 per name per year.
The ratio of our full-time registrations to these freeebies is about 1:200. In other words, each of our paid domains is paying the costs for 200 of these "domainers".
ICANN allows this, but it never really was presented to the board of directors for approval (I know, I was on the board at the time). ICANN should stop it and make the registry-fee match the actual costs that Verisign and PIR and others incurr to handle the back-room registry function - a fee that, rather than ICANN's $7 probably ought to be about $0.02 per year - a savings for you and me of more than $300,000,000 per year, every year.
Huh? What about Ed Gould and others?
on
The Birth of vi
·
· Score: 1
Back at the Unix Users Group meeting in Santa Barbara in around 197?? Ed Gould described how he was working on a full-screen version of ed.
Let's give credit where credit is due - to the *entire* group of folks at Berkeley.
My company disabled afilliate ads (the display of our ads on third party websites) because of what appeared to be fraudulant clicks. Google seemed not to care.
When we turned it off, guess what? It turned itself back on. Of course, we had no explicit record to demonstrate this to google, and they had no records of their own. It cost us several thousand dollars in fees to google.
We now take screen shots of every single interaction with google's adword/adsense control system.
Overall, however, we are finding the value of ads on third party pages to be decreasing.
Back in 1991 at the Interop trade show my company (Epilogue Technology) helped Simon Hackett (now of Internode in Adalaide), show "Etherphones". (Some rather nice T-shirts were made to note the event.)
These were internet based telephones that ran using phone handsets hooked to sound cards in PC's.
The caller would call - and of course software on the PC was involved - making a connection over UDP.
So I would say that MS's patent claims were merely prettier versions of what was more than 6 years earlier.
But even earlier, back in the 1970's or 1980's, the folks at ISI (Marina del Rey) and SRI (Menlo Park, Calif.) had voice over the net. I understand that at one time they even had a van driving up/down US 101 with an internet phone in it.
GPLv2 contains the following language in paragraph 9:
If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation.
This provision gives the option of deciding whether to follow V2 or V3 to the person making a copy of V2 code, not to the author.
There is a serious ambiguity - if that person adds or changes some of the code, can that person convert the entire module to V3 or is the module now fragmented? And if the latter, how is anyone supposed to keep track of what statement of code is under what license?
Personally I have abandoned publishing code under the GPL - I now use the less restrictive, non-viral MIT/BSD style licenses.
There is another situation that few have discussed - The rules of copyright in the US are defined by statutes enacted by, and changable by, Congress.
There is a chance that Congress could amend the US copyright law to deny the right of enforcement to anyone who has made only a partial or small contribution to the totality of the work or if that contribution has been subject to several intervening layers of further contributions. (It would be a bear to define these things, but the Congress critters would be getting a lot of help from the IP and non GPL software industry.)
The problem with human marked ballots is that humans tend to miss the edges of the bubbles, use weird color inks (in one election the scanners expected a kind of blue-purple ink and mis-read when people used black or dark blue), or simply don't fill things in very consistently.
In other words, by using machines to place the marks we avoid the bubble-card equivalent of hanging, dimpled, and pregnant chads.
What you suggest is similar to the proposal via the Open Voting Consortium.
The differences are in that in the OVC approach only the results of a voter's selection are printed onto the generated paper. (We don't use pre-printed papers except that we use marked papers so that it is possible to distinguish between fake ballots that are printed elsewhere and valid ballots printed in response to a real voter's choices.)
The reason why the non-selected choices are not printed is mechanical - to keep the voter's selections on one sheet of paper.
Yes, multiple pages could be printed, each bearing the election idenfication information. This increases the issue of paper handling. One of the biggest problems with these machines are printers (not adequately reliable, need supplies, tend to draw a lot of power, take so long that the voter might walk away, print on papers that are not mechanically strong enough to withstand fast scanning by the vote counting equipment, etc) Remember this stuff has to work in conditions that range from 0% to 100% humidity and with power that is downright awful delivered through building wiring that may date from days of Edison and Tesla.
But overall, I agree with you that the right approach is to consider the voting machines to be ballot marking machines, with variaions to fit the needs of physically disabled voters - and that the paper that is generated is "the" ballot and becomes valid only when physically inserted into a ballot box.
For one thing, the A root server isn't at ICANN, it's at Verisign, in Virginia.
Secondly, the L root server, which is claimined by ICANN is actually part of IANA and is one server out of about 130 root servers, so it's hardly singularly important.
And the L root server itself is not in Marina del Rey.
There is an urban legend that ICANN has something to do with keeping the internet running.
That's not true. ICANN imposes business, economic, and legal policies (largely trademark friendly ones) onto the net, but ICANN does very little that has any contact with the actual ability of DNS servers to transform DNS query packets into DNS reply packets.
If ICANN were to vanish in a poof of green (money colored) smoke, it would be hard to say whether anybody except the trademark lawyers would notice.
On the other hand, a lot of people do believe that ICANN is some sort of FEMA protecting the upper tier of DNS from some kind of internet Katrina. ICANN has abrogated any such protective duties.
Come to think of it, yes, ICANN is the FEMA of the internet - and just like FEMA it will let us down when things technically wobble.
I wonder whether google's lawyers have considered that even when someone submits original material that the person might not be of sufficient age to legally enter into a binding agreement of that nature.
Actually the DNS root servers are a fairly resiliant target.
The reason is that their data is so small - only about 250 names, the whole thing compresses down to less than 20K bytes - that it is well cached (and privately replicated.)
I've traced root server queries and most sites that don't reboot their resolvers will generate usually no more than a few hundred queries to the roots per month. If root servers stopped responding, most people would live out of their ISP's resolver caches for a long time, many people might not even notice unless root servers were inoperable for days.
On the other hand, the large top level domains (TLDs), such as.com and.org, are too large to cache and the access is sparse. So if a TLD stops responding almost everyone will perceive the outage almost instantly.
And.net is the home to many of the servers themselves - so there is a cross-TLD dependency.
So a DDoS attack on TLD servers is more likely to cause trouble than a DDoS to root servers.
This is not anything new - several folks (such as Bruce Schneier) have written about this for years.
And I've been trying for years to get ICANN to actually get concerned. But they only pay attention to attacks on trademarks, prices, and whether accurate "whois" data.
A couple of quick points - Yes, various good ideas have been floating about for a while. For example, David Chaum has some really good ideas about this stuff with regard to ballot receipts that are split into two parts that are individually meaningless but together can be used to verify, even at a later date, that the voter's vote has been properly tallied.
As for receipts - In pretty much every state it is illegal to generate a receipt that says how the voter voted.
Why? Because there are folks out there who want to coerce voters - coerce as in "do physical violence to" - to cast their votes in desired ways. Such folks would require that the voter hand over a receipt proving that the voter followed their "advice". This isn't hypothetical - a goodly number of voting rules are based on real-life experience.
By-the-way, I and others have concerns about bar codes - people can not directly read 'em. That raises questions in people's minds about what is in the bar code and whether it is recording someing incorrectly or that should not be recorded at all (like the voter's name). Given the mistrust of voting these days it's probably not a terrific idea to do things that might inflame that mistrust.
Oh, and one more thing - voting officials find touch screens sexy. But from the point of view of sight impaired voters they are very useful. Don't underestimate the need to handle folks with physical impairments.
It's harder than you might at first think
on
Diebold Flops in Alaska
·
· Score: 5, Informative
I'm part of the Open Voting Consortium and we've been proposing a system in which the voter uses a machine to produce a paper ballot. That ballot *is* the ballot, not some copy, not some receipt, but the actual ballot. And it isn't good until stuffed into a ballot box.
The paper ballot is the core - it's in a form and font easy for machine readers to read, but it can also be read by people.
Now, that vote-printer machine can be any machine that has an interface appropriate to the needs of the voter - such as audio driven for sight impaired voters. (A ballot reader would be available to do an audio readback.)
Our proposal is to do this, plus a canvassing system (that's the part that aggregates the precinct counts into the grand totals.)
And we feel that *all* code, and all machinery, should be inspectable and testable by anybody who wants to run a test (and they should be able to publish their test results.) That's one step short of full open source - which doesn't mean that the code couldn't also be open source under one of the licenses.
It is a mistake to think of these things as a software issue - it involves machines (even if they look and smell like PC's, although I personally tend to prefer smaller/lower power engines like the WRAP or Soekris machines) and procedures, lots and lots of procedures (like what to do if a voter walks out in the middle of casting his/her vote - there are laws that say what to do, and they, of course, vary from state to state and even county to county.)
But it is harder to do than one thinks - the machines themselves can't just be any old junk PC. They need to be robust in the face of voter use and tampering behind the scenes. And they need to have lots and lots of places where they can be locked-down (often using things as simple as lead-and-wire tamper seals) to prevent hanky-panky by warehouse or precinct people.
They need to be power-conserving (imagine a precinct with a single circuit breaker/fuse and a flakey or non-existant ground, and that the voting is occuring during a thunderstorm.) UPS's are a pain - they have a high failure rate and given that they often contain a lead-acid battery, are neither lightweight nor quite innocent should they leak. And it's important to keep the fire marshall happy.
And printers are a pure pain in the rear - they can draw a lot of power and are generally the most failure prone part of the system.
And there are lots of legal requirements - like protecting the privacy of the vote. You can, for example, potentially reconstruct which voter voted which way by looking at things like sequencial files used for audit/error-detection or for ballot tallies.
And the stuff has to be easily configurable en masse - counties tend to need hundreds, thousands of these things, and they better all be the same. And they need to be able to be transported by folks who aren't necessarily gentle and set up by people who make your grandmother look like a tech support wizard.
We were planning on doing a project to produce a reference model for such a system via the University of California (multi-campus project with UC Santa Cruz in the project lead position) but we got cut out of California's HAVA (Federal voting act) funding when the previous California Sect'y of State got caught up in a brouhaha on other matters. It's still worth doing - every state would benefit.
You've asked a very good question - which, to my mind as a person who writes and creates software and stuff, is "how in the world would I design a DRM scheme" that knows when to disable itself, and how do I do that so that a sneeky user can't simply change the apparent date and bypass the protection during the copyright period?"
My answer is this: I dunno.
But my response is that the onus of answering the question ought to be on those who want to impose EDRM (Eternal DRM). If they can't come up with an answer then they ought not to be allowed DRM.
You allude to another issue that I think is not often raised: What happens when historians of the future want to see what our world was like - DRM will still be DRM. There might be amazing devices to crack 21st century DRMs, but then again maybe we've now gotten good enough at cryptography that we really can create things that will be hard to unlock even in the future.
(I do have this mental image of some 25th century RIAA lawyer suing an historian of the early 21st century under the, by-then quite hoary, DMCA anti-circumvention provision, for cracking the DRM on a copy of Disney's Snow White found in some archeological excavation of what was once called "LA".)
The copyright clause in the Constitution allows Congress to enact laws to protect the work of authors only for limited periods of time.
Now, in the Mickey Mouse case, the court said that protection periods on the order of 100 years are OK, but the Court kinda hinted that it might not go along with this much further.
Anyway, the technique of leveraging DRM protections in via a copyright and then having them live forever is rather a slap in the face of the Constitutional limitation on the duration of copyrights.
Of course, Congress does have a weasel-way out: they might say, "oh, we allow DRM to exist forever as part of our powers over commerce among the states."
But in practical terms, DRM forever transforms what is supposed to be a copyright of limited duration into a copyright that lasts for all eternity. And that, is contrary to the purpose, a purpose actually stated in the US Constitution, to promote the arts and sciences, for copyright and patents.
It seems to me that in the fight over copyright and digital rights management few have considered what happens in the distant future when the material being protected is no longer covered by copyright. That thought led me to propose the following rule and accompanying pledge.
The Rule Against Digital Perpuities:
No Digital Rights Management (DRM) limitation or anti-copying mechanism may endure longer than the original copyright in the protected work.
The Pledge:
I pledge to neither specify nor standardize nor implement any system that does not conform to the Rule Against Digital Perpetuities.
Don't read too much into this contract. It is really only a purchase by the gov't from ICANN of a very few, limited services.
What is important to understand is that this contract does *not* include all of the controversial stuff.
This contract does *not* include ICANN's role as arbiter of who gets to put a new top level domain into the root zone. Nor does this contract deal with ICANN's right to impose its regulatory system onto the domain name registries, registrars, and domain name buyers. Nor does this deal with ICANN's operation of the L-root server.
All that this contract does, in the DNS space, is to obligate ICANN to do some clerical work, according to a prescribed procedure and schedule, to handle requests to update name server (NS) records in the root zone and to update the TLD whois records accordingly.
All-in-all, this leaves ICANN in a precarious legal situation - ICANN is most clearly a combination that restrains trade. And most countries have laws about that sort of thing. As soon as the US government lift's its hand from ICANN's shoulder - and that hand is not to be found in this contract - then folks around the world might begin to ask whether ICANN's combination in restraint of trade passes legal muster under their national laws.
ICANN, presumably gets its authority to do all the stuff that is controversial via a separate document, a Memorandum of Understanding (MoU) with the US gov't. That has not yet been renewed.
I use CF with a pair of ext-3 filesystems on the PC-Engines WRAP boards, consequently this article was useless for me.
And using Windows via a USB based reader/writer, and timing it with a stopwatch - sheesh, how much noise do they want to introduce into their measurements.
They could have eliminated the USB factor by using a PCMCIA based adaptor.
Does ICANN need to be replaced or reformed into something almost entirely new? You Betcha!
A few years back I was elected to the ICANN board - and I voted against all the junk that is today being recognized as a disaster, such as the perpetual grant of.com to Verisign. But when I decided to look at how ICANN spends its money, they decided to unlawfully block me, forcing me to sue 'em (I won) - ICANN reacted by erasing public seats on the board of directors.
Today, ICANN has erased virtually all forms of public participation - to the degree that you and I can't even observe how ICANN makes its decisions. Yet, at the same time the dns registries (Verisign et al), all the big telcos, and the intellectual property get the red carpet treatment - to the degree that ICANN is now gifting some on the order $300,000,000 per yer out of the pockets of captive.com customers into Verisign's bank account (this is based on an estimate of the cost of about $0.03 to deliver the service that ICANN allows Verisign to charge $7.00 for.)
ICANN, with the help of NTIA, is really nothing more than a mideavel guild - it sets product descriptions, terms of sale, and choses who can be a member of the guild. In modern terms it is a combination in restraint of trade. Those are often illegal in the US and elsewhere, but few are willing to play hardball and ask that question in court because of the hand of the US government agency, NTIA, that rests on ICANN's shoulder. Yet NTIA, like many of the actions of todays US gov't are based on rather fancyful readings of the constitution or statutes and may, when reviewed, be found to be excessive claims.
So it is quite appropriate that people remember that tomorrow is the 4th of July - and should remember that just as the Declaration of Independence cited grievances against King George III, you should send your concerns and complaints to NTIA by the 7th.
It sounds like the *nix VM world is moving along the track established by Multics and IBM's CP/67 (later VM/370) projects.
It seems to me that the differences in the *nix approaches are mainly whether the abstract machine seen by user written code resembles a hardware machine or some nicer abstract machine.
In all VM approaches the idea that one can freeze an entire system and look at it, or isolate it, or migrate it, is a very valuable one. It's done well for IBM on their mainframes.
As for adding resources on the fly - way, way back (mid 1980's) Robin O'Neil and I did a System V based kernel for the Cray's out at Livermore. We had to run on top of the real OS, so we gave each user his/her own copy of Unix and create a file system that could grow or contract, adding, or removing inodes on the fly. And some of those inodes could reference files held by the underlying OS, thus making strange things, like "df" showing less space on the file system than was shown by a "du" summation of the file sizes in the file system. We published a paper on this at one of various Unix gatherings of the time.
So if we could expand file systems on the fly 20 years ago I don't see why it should be so hard to do today.
Now if we'd just get serious about capability architectures... (Much of the secure OS work of the '70's was done with capability architectures with hardware support such as the old Plessy machines.)
You are in luck - the Open Voting Consortium design does, in fact, produce a paper ballot that shows, in human readible form, the voter's choices. It's not a receipt, it's the actual ballot and has to be put into a ballot box to be counted. And it won't go into the ballot box until you, the voter, have a chance to review it to ensure that it reflects your choices.
The OVC system is very much the traditional paper ballot system but with computer systems added to help voters (including voters with physical impairments) create the paper ballots and to help voting administrators count the paper ballots.
The idea of having open or disclosed/inspectable source is to help you, me, and everyone gain faith that the system is relatively bug free and free of trojan horses. You can look to see that some naive programmer hasn't tried to stuff the vote counts into a 16-bit integer, you can look to see that the vote counting software won't get confused if there are two candidates with the same name.
Also, voting systems are not just software - there is a big procedural component (like ensuring that the vote counters are zero before counting starts, like making sure that voters only get to vote once, like knowing how to handle a voter who spoils his/her ballot or walks out in the middle of filling out the ballot). And there is a big hardware task - this stuff has to run in garages with ungrounded circuits from circa 1903 and a penny stuffed into the fuse box, etc. The software is perhaps the easier part.
Way back in 1995 I wrote the real time core of "IP/TV". We sold the company to Cisco in 1998 and Cisco still holds the US registered trademark "IP/TV".
In any event, even way back a decade ago we were thinking how to move entertainment grade video - but there some things that people should be aware of. The first is that in the minds of many the entertainment stream is merely a container for advertising. The ability to do personalized, fast-cut, commercial inserts was one of the holy grails. One of the others was to do customized product placements (e.g. change a generic can into a can of Pepsi or Coke on a per-viewer basis.)
Good video and audio does take a goodly chunk of bandwidth - more than comes in to most US homes even with cable or DSL. And if the typical home scenerio plays out, many homes will be taking several parallal feeds at the same time.
The old Palantir scanners could do Wagner
on
Scanjet Music
·
· Score: 1
The old Palantir scanners - mid 1980s- would play Wagner's Ride of the Vulkuries on the stepper motors during the self-test. It was really amazing and went on for quite a long time increasing in intensity and complexity.
But along with the original Internet toasters (two implementations in 1987) the Palantir scanners seem to have vanished.
You obviously have missed the fact that privacy of whois has been one of the big issues of internet governance ever since the latter 1990's.
Just the other day I listened to a person from the FTC say, in essence that to protect privacy they have to eliminate it.
As for whois being public - I'm in the 1974 ARPAnet directory, something that evolved into whois, so I'm hardly unfamiliar with its history. The rules of acquisition of domain names shifted from being a clubby kind of thing where you'd call up Susan or Joyce at the NIC at SRI and ask for a name to a pay-for and subject-to-contract commercial mass system with now 44 million names in.com. And with that shift we moved from having that information available to people who you reciprically (sp) knew to a system in which domain names became one of the few non-dangerous instrumentalities, apart from land, that required the purchasor to publish his/her name, address, phone number, affiliation, and e-mail to the world 24x7.
Ever heard of Megan's law, where the names of predators are published to parents? The current regime of domain name whois is Megan's Law in reverse - where we publish the names of the potential victims to the predators, whether those predators be spammers or stalkers.
I have suggested several times that there be safeguards, such as requiring anyone who wants to look at whois to state, and prove, their identity, state the reason why they claim they need to look and give supporting facts, that the list of people making such inquiries be given to the domain name registrants, and that there be a yearly publication of how many whois queries each person made.
Perhaps a lot of those names with bogus contact info are being used in the domain parking business - that's where people register thousands of names and monitor the traffic for a couple of days to deside which ones are getting hits and which are not. The good ones might then be paid-for and updated with better contact info while the poor ones are released without payment.
But there is a bigger issue: Why should those of use who buy domain names be forced to reveal our contact information to the world?
The reason is that the intellectual property industry, which dominates ICANN, forced this down our throats.
It is an ICANN rule that is in violation of the privacy laws of many countries.
Some lazy law enforcement types claim that they need an open "whois" to enforce the law. That is not true. Law enforcement types have tools (subpoenas) to open closed databases, and, moreover, allowing access to law enforcment does not require that the public be granted the same access 24x7x365.
There is a claim that "whois" data for DNS has operational value, yes it has some, but it is of much lower value operationally than the value of the whois data for IP addresses, a separate and disinct database.
The other week I met an attorney for a large company (very large) who routinly registers domain names anonymously - so as to avoid giving notice of the company's actions. Yet at the same time he watches new registrations and has a tool that automatically sends out cease and desist letters to names that offend his regular expression. Fair? Not really. An exercise in economic bullying? Yes.
Since the European Union (.eu) is a federation of states not all that different in the gross sense from the United States (.us), consistency argumes that the members of.eu should relinquish their individual top level ccTLDs, such as.uk, and.de.
Otherwise the US, Canada, and other countries that are formed using a model with overall sovreignty split between an overall federal government and several component states, should obtain top level domains for the individual states, such as.cal for California.
At the recent ICANN meeting in Vancouver there were demands for names such as.berlin and.nyc (New York City). And ICANN has granted a top level domain for speakers of the Catalonian language. (Why not ones for English, Mandarin, or Boontling?)
Slashdot Mirror
ICANN is subsidizing this garbage industry to the tune of about $300,000,000 to $500,000,000 per year - yes every year - out of our pockets.
This is because the "domainers" get free domain name registration tryouts while the rest of us are forced to pay a ICANN-fiat "registry fee" of about $7 per name per year.
The ratio of our full-time registrations to these freeebies is about 1:200. In other words, each of our paid domains is paying the costs for 200 of these "domainers".
ICANN allows this, but it never really was presented to the board of directors for approval (I know, I was on the board at the time). ICANN should stop it and make the registry-fee match the actual costs that Verisign and PIR and others incurr to handle the back-room registry function - a fee that, rather than ICANN's $7 probably ought to be about $0.02 per year - a savings for you and me of more than $300,000,000 per year, every year.
Back at the Unix Users Group meeting in Santa Barbara in around 197?? Ed Gould described how he was working on a full-screen version of ed.
Let's give credit where credit is due - to the *entire* group of folks at Berkeley.
My company disabled afilliate ads (the display of our ads on third party websites) because of what appeared to be fraudulant clicks. Google seemed not to care.
When we turned it off, guess what? It turned itself back on. Of course, we had no explicit record to demonstrate this to google, and they had no records of their own. It cost us several thousand dollars in fees to google.
We now take screen shots of every single interaction with google's adword/adsense control system.
Overall, however, we are finding the value of ads on third party pages to be decreasing.
Back in 1991 at the Interop trade show my company (Epilogue Technology) helped Simon Hackett (now of Internode in Adalaide), show "Etherphones". (Some rather nice T-shirts were made to note the event.)
These were internet based telephones that ran using phone handsets hooked to sound cards in PC's.
The caller would call - and of course software on the PC was involved - making a connection over UDP.
So I would say that MS's patent claims were merely prettier versions of what was more than 6 years earlier.
But even earlier, back in the 1970's or 1980's, the folks at ISI (Marina del Rey) and SRI (Menlo Park, Calif.) had voice over the net. I understand that at one time they even had a van driving up/down US 101 with an internet phone in it.
GPLv2 contains the following language in paragraph 9:
If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation.
This provision gives the option of deciding whether to follow V2 or V3 to the person making a copy of V2 code, not to the author.
There is a serious ambiguity - if that person adds or changes some of the code, can that person convert the entire module to V3 or is the module now fragmented? And if the latter, how is anyone supposed to keep track of what statement of code is under what license?
Personally I have abandoned publishing code under the GPL - I now use the less restrictive, non-viral MIT/BSD style licenses.
There is another situation that few have discussed - The rules of copyright in the US are defined by statutes enacted by, and changable by, Congress.
There is a chance that Congress could amend the US copyright law to deny the right of enforcement to anyone who has made only a partial or small contribution to the totality of the work or if that contribution has been subject to several intervening layers of further contributions. (It would be a bear to define these things, but the Congress critters would be getting a lot of help from the IP and non GPL software industry.)
The problem with human marked ballots is that humans tend to miss the edges of the bubbles, use weird color inks (in one election the scanners expected a kind of blue-purple ink and mis-read when people used black or dark blue), or simply don't fill things in very consistently.
In other words, by using machines to place the marks we avoid the bubble-card equivalent of hanging, dimpled, and pregnant chads.
What you suggest is similar to the proposal via the Open Voting Consortium.
The differences are in that in the OVC approach only the results of a voter's selection are printed onto the generated paper. (We don't use pre-printed papers except that we use marked papers so that it is possible to distinguish between fake ballots that are printed elsewhere and valid ballots printed in response to a real voter's choices.)
The reason why the non-selected choices are not printed is mechanical - to keep the voter's selections on one sheet of paper.
Yes, multiple pages could be printed, each bearing the election idenfication information. This increases the issue of paper handling. One of the biggest problems with these machines are printers (not adequately reliable, need supplies, tend to draw a lot of power, take so long that the voter might walk away, print on papers that are not mechanically strong enough to withstand fast scanning by the vote counting equipment, etc) Remember this stuff has to work in conditions that range from 0% to 100% humidity and with power that is downright awful delivered through building wiring that may date from days of Edison and Tesla.
But overall, I agree with you that the right approach is to consider the voting machines to be ballot marking machines, with variaions to fit the needs of physically disabled voters - and that the paper that is generated is "the" ballot and becomes valid only when physically inserted into a ballot box.
Well, it's hard to believe you.
For one thing, the A root server isn't at ICANN, it's at Verisign, in Virginia.
Secondly, the L root server, which is claimined by ICANN is actually part of IANA and is one server out of about 130 root servers, so it's hardly singularly important.
And the L root server itself is not in Marina del Rey.
There is an urban legend that ICANN has something to do with keeping the internet running.
That's not true. ICANN imposes business, economic, and legal policies (largely trademark friendly ones) onto the net, but ICANN does very little that has any contact with the actual ability of DNS servers to transform DNS query packets into DNS reply packets.
If ICANN were to vanish in a poof of green (money colored) smoke, it would be hard to say whether anybody except the trademark lawyers would notice.
On the other hand, a lot of people do believe that ICANN is some sort of FEMA protecting the upper tier of DNS from some kind of internet Katrina. ICANN has abrogated any such protective duties.
Come to think of it, yes, ICANN is the FEMA of the internet - and just like FEMA it will let us down when things technically wobble.
I wonder whether google's lawyers have considered that even when someone submits original material that the person might not be of sufficient age to legally enter into a binding agreement of that nature.
Actually the DNS root servers are a fairly resiliant target.
.com and .org, are too large to cache and the access is sparse. So if a TLD stops responding almost everyone will perceive the outage almost instantly.
.net is the home to many of the servers themselves - so there is a cross-TLD dependency.
The reason is that their data is so small - only about 250 names, the whole thing compresses down to less than 20K bytes - that it is well cached (and privately replicated.)
I've traced root server queries and most sites that don't reboot their resolvers will generate usually no more than a few hundred queries to the roots per month. If root servers stopped responding, most people would live out of their ISP's resolver caches for a long time, many people might not even notice unless root servers were inoperable for days.
On the other hand, the large top level domains (TLDs), such as
And
So a DDoS attack on TLD servers is more likely to cause trouble than a DDoS to root servers.
This is not anything new - several folks (such as Bruce Schneier) have written about this for years.
And I've been trying for years to get ICANN to actually get concerned. But they only pay attention to attacks on trademarks, prices, and whether accurate "whois" data.
A couple of quick points - Yes, various good ideas have been floating about for a while. For example, David Chaum has some really good ideas about this stuff with regard to ballot receipts that are split into two parts that are individually meaningless but together can be used to verify, even at a later date, that the voter's vote has been properly tallied.
As for receipts - In pretty much every state it is illegal to generate a receipt that says how the voter voted.
Why? Because there are folks out there who want to coerce voters - coerce as in "do physical violence to" - to cast their votes in desired ways. Such folks would require that the voter hand over a receipt proving that the voter followed their "advice". This isn't hypothetical - a goodly number of voting rules are based on real-life experience.
By-the-way, I and others have concerns about bar codes - people can not directly read 'em. That raises questions in people's minds about what is in the bar code and whether it is recording someing incorrectly or that should not be recorded at all (like the voter's name). Given the mistrust of voting these days it's probably not a terrific idea to do things that might inflame that mistrust.
Oh, and one more thing - voting officials find touch screens sexy. But from the point of view of sight impaired voters they are very useful. Don't underestimate the need to handle folks with physical impairments.
I'm part of the Open Voting Consortium and we've been proposing a system in which the voter uses a machine to produce a paper ballot. That ballot *is* the ballot, not some copy, not some receipt, but the actual ballot. And it isn't good until stuffed into a ballot box.
The paper ballot is the core - it's in a form and font easy for machine readers to read, but it can also be read by people.
Now, that vote-printer machine can be any machine that has an interface appropriate to the needs of the voter - such as audio driven for sight impaired voters. (A ballot reader would be available to do an audio readback.)
Our proposal is to do this, plus a canvassing system (that's the part that aggregates the precinct counts into the grand totals.)
And we feel that *all* code, and all machinery, should be inspectable and testable by anybody who wants to run a test (and they should be able to publish their test results.) That's one step short of full open source - which doesn't mean that the code couldn't also be open source under one of the licenses.
It is a mistake to think of these things as a software issue - it involves machines (even if they look and smell like PC's, although I personally tend to prefer smaller/lower power engines like the WRAP or Soekris machines) and procedures, lots and lots of procedures (like what to do if a voter walks out in the middle of casting his/her vote - there are laws that say what to do, and they, of course, vary from state to state and even county to county.)
But it is harder to do than one thinks - the machines themselves can't just be any old junk PC. They need to be robust in the face of voter use and tampering behind the scenes. And they need to have lots and lots of places where they can be locked-down (often using things as simple as lead-and-wire tamper seals) to prevent hanky-panky by warehouse or precinct people.
They need to be power-conserving (imagine a precinct with a single circuit breaker/fuse and a flakey or non-existant ground, and that the voting is occuring during a thunderstorm.) UPS's are a pain - they have a high failure rate and given that they often contain a lead-acid battery, are neither lightweight nor quite innocent should they leak. And it's important to keep the fire marshall happy.
And printers are a pure pain in the rear - they can draw a lot of power and are generally the most failure prone part of the system.
And there are lots of legal requirements - like protecting the privacy of the vote. You can, for example, potentially reconstruct which voter voted which way by looking at things like sequencial files used for audit/error-detection or for ballot tallies.
And the stuff has to be easily configurable en masse - counties tend to need hundreds, thousands of these things, and they better all be the same. And they need to be able to be transported by folks who aren't necessarily gentle and set up by people who make your grandmother look like a tech support wizard.
We were planning on doing a project to produce a reference model for such a system via the University of California (multi-campus project with UC Santa Cruz in the project lead position) but we got cut out of California's HAVA (Federal voting act) funding when the previous California Sect'y of State got caught up in a brouhaha on other matters. It's still worth doing - every state would benefit.
You've asked a very good question - which, to my mind as a person who writes and creates software and stuff, is "how in the world would I design a DRM scheme" that knows when to disable itself, and how do I do that so that a sneeky user can't simply change the apparent date and bypass the protection during the copyright period?"
My answer is this: I dunno.
But my response is that the onus of answering the question ought to be on those who want to impose EDRM (Eternal DRM). If they can't come up with an answer then they ought not to be allowed DRM.
You allude to another issue that I think is not often raised: What happens when historians of the future want to see what our world was like - DRM will still be DRM. There might be amazing devices to crack 21st century DRMs, but then again maybe we've now gotten good enough at cryptography that we really can create things that will be hard to unlock even in the future.
(I do have this mental image of some 25th century RIAA lawyer suing an historian of the early 21st century under the, by-then quite hoary, DMCA anti-circumvention provision, for cracking the DRM on a copy of Disney's Snow White found in some archeological excavation of what was once called "LA".)
The copyright clause in the Constitution allows Congress to enact laws to protect the work of authors only for limited periods of time.
Now, in the Mickey Mouse case, the court said that protection periods on the order of 100 years are OK, but the Court kinda hinted that it might not go along with this much further.
Anyway, the technique of leveraging DRM protections in via a copyright and then having them live forever is rather a slap in the face of the Constitutional limitation on the duration of copyrights.
Of course, Congress does have a weasel-way out: they might say, "oh, we allow DRM to exist forever as part of our powers over commerce among the states."
But in practical terms, DRM forever transforms what is supposed to be a copyright of limited duration into a copyright that lasts for all eternity. And that, is contrary to the purpose, a purpose actually stated in the US Constitution, to promote the arts and sciences, for copyright and patents.
See my note "The Rule Against Digital Perpetuities". It's short, so I'll just copy it here:
The Rule Against Digital Perpetuities
It seems to me that in the fight over copyright and digital rights management few have considered what happens in the distant future when the material being protected is no longer covered by copyright. That thought led me to propose the following rule and accompanying pledge.
The Rule Against Digital Perpuities:
No Digital Rights Management (DRM) limitation or anti-copying mechanism may endure longer than the original copyright in the protected work.
The Pledge:
I pledge to neither specify nor standardize nor implement any system that does not conform to the Rule Against Digital Perpetuities.
Don't read too much into this contract. It is really only a purchase by the gov't from ICANN of a very few, limited services.
What is important to understand is that this contract does *not* include all of the controversial stuff.
This contract does *not* include ICANN's role as arbiter of who gets to put a new top level domain into the root zone. Nor does this contract deal with ICANN's right to impose its regulatory system onto the domain name registries, registrars, and domain name buyers. Nor does this deal with ICANN's operation of the L-root server.
All that this contract does, in the DNS space, is to obligate ICANN to do some clerical work, according to a prescribed procedure and schedule, to handle requests to update name server (NS) records in the root zone and to update the TLD whois records accordingly.
All-in-all, this leaves ICANN in a precarious legal situation - ICANN is most clearly a combination that restrains trade. And most countries have laws about that sort of thing. As soon as the US government lift's its hand from ICANN's shoulder - and that hand is not to be found in this contract - then folks around the world might begin to ask whether ICANN's combination in restraint of trade passes legal muster under their national laws.
ICANN, presumably gets its authority to do all the stuff that is controversial via a separate document, a Memorandum of Understanding (MoU) with the US gov't. That has not yet been renewed.
I use CF with a pair of ext-3 filesystems on the PC-Engines WRAP boards, consequently this article was useless for me.
And using Windows via a USB based reader/writer, and timing it with a stopwatch - sheesh, how much noise do they want to introduce into their measurements.
They could have eliminated the USB factor by using a PCMCIA based adaptor.
Does ICANN need to be replaced or reformed into something almost entirely new? You Betcha!
.com to Verisign. But when I decided to look at how ICANN spends its money, they decided to unlawfully block me, forcing me to sue 'em (I won) - ICANN reacted by erasing public seats on the board of directors.
.com customers into Verisign's bank account (this is based on an estimate of the cost of about $0.03 to deliver the service that ICANN allows Verisign to charge $7.00 for.)
A few years back I was elected to the ICANN board - and I voted against all the junk that is today being recognized as a disaster, such as the perpetual grant of
Today, ICANN has erased virtually all forms of public participation - to the degree that you and I can't even observe how ICANN makes its decisions. Yet, at the same time the dns registries (Verisign et al), all the big telcos, and the intellectual property get the red carpet treatment - to the degree that ICANN is now gifting some on the order $300,000,000 per yer out of the pockets of captive
ICANN, with the help of NTIA, is really nothing more than a mideavel guild - it sets product descriptions, terms of sale, and choses who can be a member of the guild. In modern terms it is a combination in restraint of trade. Those are often illegal in the US and elsewhere, but few are willing to play hardball and ask that question in court because of the hand of the US government agency, NTIA, that rests on ICANN's shoulder. Yet NTIA, like many of the actions of todays US gov't are based on rather fancyful readings of the constitution or statutes and may, when reviewed, be found to be excessive claims.
So it is quite appropriate that people remember that tomorrow is the 4th of July - and should remember that just as the Declaration of Independence cited grievances against King George III, you should send your concerns and complaints to NTIA by the 7th.
It sounds like the *nix VM world is moving along the track established by Multics and IBM's CP/67 (later VM/370) projects.
It seems to me that the differences in the *nix approaches are mainly whether the abstract machine seen by user written code resembles a hardware machine or some nicer abstract machine.
In all VM approaches the idea that one can freeze an entire system and look at it, or isolate it, or migrate it, is a very valuable one. It's done well for IBM on their mainframes.
As for adding resources on the fly - way, way back (mid 1980's) Robin O'Neil and I did a System V based kernel for the Cray's out at Livermore. We had to run on top of the real OS, so we gave each user his/her own copy of Unix and create a file system that could grow or contract, adding, or removing inodes on the fly. And some of those inodes could reference files held by the underlying OS, thus making strange things, like "df" showing less space on the file system than was shown by a "du" summation of the file sizes in the file system. We published a paper on this at one of various Unix gatherings of the time.
So if we could expand file systems on the fly 20 years ago I don't see why it should be so hard to do today.
Now if we'd just get serious about capability architectures... (Much of the secure OS work of the '70's was done with capability architectures with hardware support such as the old Plessy machines.)
You are in luck - the Open Voting Consortium design does, in fact, produce a paper ballot that shows, in human readible form, the voter's choices. It's not a receipt, it's the actual ballot and has to be put into a ballot box to be counted. And it won't go into the ballot box until you, the voter, have a chance to review it to ensure that it reflects your choices.
The OVC system is very much the traditional paper ballot system but with computer systems added to help voters (including voters with physical impairments) create the paper ballots and to help voting administrators count the paper ballots.
The idea of having open or disclosed/inspectable source is to help you, me, and everyone gain faith that the system is relatively bug free and free of trojan horses. You can look to see that some naive programmer hasn't tried to stuff the vote counts into a 16-bit integer, you can look to see that the vote counting software won't get confused if there are two candidates with the same name.
Also, voting systems are not just software - there is a big procedural component (like ensuring that the vote counters are zero before counting starts, like making sure that voters only get to vote once, like knowing how to handle a voter who spoils his/her ballot or walks out in the middle of filling out the ballot). And there is a big hardware task - this stuff has to run in garages with ungrounded circuits from circa 1903 and a penny stuffed into the fuse box, etc. The software is perhaps the easier part.
Disclosure: I'm on the OVC Board of Directors.
Way back in 1995 I wrote the real time core of "IP/TV". We sold the company to Cisco in 1998 and Cisco still holds the US registered trademark "IP/TV".
In any event, even way back a decade ago we were thinking how to move entertainment grade video - but there some things that people should be aware of. The first is that in the minds of many the entertainment stream is merely a container for advertising. The ability to do personalized, fast-cut, commercial inserts was one of the holy grails. One of the others was to do customized product placements (e.g. change a generic can into a can of Pepsi or Coke on a per-viewer basis.)
Good video and audio does take a goodly chunk of bandwidth - more than comes in to most US homes even with cable or DSL. And if the typical home scenerio plays out, many homes will be taking several parallal feeds at the same time.
The old Palantir scanners - mid 1980s- would play Wagner's Ride of the Vulkuries on the stepper motors during the self-test. It was really amazing and went on for quite a long time increasing in intensity and complexity.
But along with the original Internet toasters (two implementations in 1987) the Palantir scanners seem to have vanished.
Theories?
.com. And with that shift we moved from having that information available to people who you reciprically (sp) knew to a system in which domain names became one of the few non-dangerous instrumentalities, apart from land, that required the purchasor to publish his/her name, address, phone number, affiliation, and e-mail to the world 24x7.
m l
You obviously have missed the fact that privacy of whois has been one of the big issues of internet governance ever since the latter 1990's.
Just the other day I listened to a person from the FTC say, in essence that to protect privacy they have to eliminate it.
As for whois being public - I'm in the 1974 ARPAnet directory, something that evolved into whois, so I'm hardly unfamiliar with its history. The rules of acquisition of domain names shifted from being a clubby kind of thing where you'd call up Susan or Joyce at the NIC at SRI and ask for a name to a pay-for and subject-to-contract commercial mass system with now 44 million names in
Ever heard of Megan's law, where the names of predators are published to parents? The current regime of domain name whois is Megan's Law in reverse - where we publish the names of the potential victims to the predators, whether those predators be spammers or stalkers.
I have suggested several times that there be safeguards, such as requiring anyone who wants to look at whois to state, and prove, their identity, state the reason why they claim they need to look and give supporting facts, that the list of people making such inquiries be given to the domain name registrants, and that there be a yearly publication of how many whois queries each person made.
Right now I'm working on the code for an anonymous domain name registration system that uses public keys to indicate ownership. See http://www.cavebear.com/cbblog-archives/000159.ht
Perhaps a lot of those names with bogus contact info are being used in the domain parking business - that's where people register thousands of names and monitor the traffic for a couple of days to deside which ones are getting hits and which are not. The good ones might then be paid-for and updated with better contact info while the poor ones are released without payment.
But there is a bigger issue: Why should those of use who buy domain names be forced to reveal our contact information to the world?
The reason is that the intellectual property industry, which dominates ICANN, forced this down our throats.
It is an ICANN rule that is in violation of the privacy laws of many countries.
Some lazy law enforcement types claim that they need an open "whois" to enforce the law. That is not true. Law enforcement types have tools (subpoenas) to open closed databases, and, moreover, allowing access to law enforcment does not require that the public be granted the same access 24x7x365.
There is a claim that "whois" data for DNS has operational value, yes it has some, but it is of much lower value operationally than the value of the whois data for IP addresses, a separate and disinct database.
The other week I met an attorney for a large company (very large) who routinly registers domain names anonymously - so as to avoid giving notice of the company's actions. Yet at the same time he watches new registrations and has a tool that automatically sends out cease and desist letters to names that offend his regular expression. Fair? Not really. An exercise in economic bullying? Yes.
Since the European Union (.eu) is a federation of states not all that different in the gross sense from the United States (.us), consistency argumes that the members of .eu should relinquish their individual top level ccTLDs, such as .uk, and .de.
.cal for California.
.berlin and .nyc (New York City). And ICANN has granted a top level domain for speakers of the Catalonian language. (Why not ones for English, Mandarin, or Boontling?)
Otherwise the US, Canada, and other countries that are formed using a model with overall sovreignty split between an overall federal government and several component states, should obtain top level domains for the individual states, such as
At the recent ICANN meeting in Vancouver there were demands for names such as