Trust me, you do not want this behavior changed. You see, Mozilla and IE used to allow this. Then the bad guys figured out that you could ferret out the local filenames things were cached under, load your own malicious code into the cache in an innocuous way, then refer to it as a local resource in a dangerous way. Since it was a local resource it could do things a remote resource wouldn't be allowed to do. So Mozilla drew a one-way wall: local resources can refer to remote resources, but remote resources aren't allowed to refer to local resources directly. They looked at being type-selective, but concluded that if they did someone would always be able to finagle a way to turn that into arbitrary access, so the only safe thing was to block across the board based on the local/remote nature of the protocol.
IE tried to avoid this and be more selective. The result has been a fairly steady stream of zone-escalation exploits for it. To put it plainly, you can't open just one hole.
And frankly, if your page is remote, why are you assuming a local file exists at a particular location? You should be referring to your own resources, not someone else's.
I don't think it was considered, or if it was it was hand-waved away. For example, in section 3 they list the reasons a registrar of record may deny a transfer, then explicitly say that those are the only reasons. Lack of response is explicitly not a reason to block the transfer. If they'd considered the situation, then lack of response (contact/registrant on vacation or somesuch) would be reason to block the transfer until the contact/registrant could authorize it. Also note that in section 6, the first condition for reversal of a transfer, the one speaking to mistakes, requires the gaining registrar to agree that it was a mistake. If the registrar of record and the original registrant both agree that no transfer was authorized (and the registrant should know whether they authorized it) and the gaining registrar (who in the case of an unscrupulous registrar stands to benefit from the transfer) refuses to agree, the transfer doesn't get reversed. Again, if my scenario had been considered significant, the gaining registrar would be the one party who wouldn't have a say in whether authorization was given.
The only protection seems to be in section 5 for those gTLDs that use EPP. There an authorization code has to be obtained from the registrar of record and then presented by the gaining registrar before the transfer is approved. That's the only part of the rules I like, since the AuthInfo code could only have gotten to the gaining registrar if the registrant gave it to them. This or the equivalent should be the rule for all TLDs, all registrars.
IMHO this policy is a step backwards. Where under the old rules I could have a problem with a party with whom I have a legally-binding agreement (which may be a bad one, but at least I knew the terms) and some leverage in court if worst comes to worst, under this policy my problems will come from a party I don't even know was causing a problem and with whom I have no legal leverage at all beyond the (completely ineffectual IMO, or we wouldn't have had balking-registrar problems in the first place) ICANN dispute processes. Better the devil I know than the devil I don't.
Not all "registrants" are honest. If they were, we wouldn't have seen some of the games we've seen played with domain registrations in recent years).
Not all registrars are conscientious or ethical. If they were, we wouldn't see those "invoices" from registrars claiming you have to pay them to keep your domain even though it's registered with a completely different registrar, or registrars balking at making legitimate and correctly authorized transfers.
ICANN doesn't seem to enforce the rules very well. If they did, the whole problem of registrars balking at legitimate transfers wouldn't have been a problem after the first registrar or two lost their credentials over it.
Given the above, I can easily envisage a situation where either a "registrant" gave false information to a not-too-conscientious registrar or a flat-out unscrupulous registrar simply sent in a transfer order for a domain they wanted. In some TLDs I believe there's some authorization going on, but in most the new rules put the trust in the gaining registrar, the one party we don't know has a contractual relationship with the actual registrant, to be honest and conscientious.
My opinion is that any transfer rules should include one principle: a transfer may only occur upon notice from the registrant or admin contract for the domain to the registrar of record that they're transferring the domain. If balking registrars of record is the problem, define a standard for reasonable authorization and revoke the certification of any registrar who balks at a transfer after receiving authorization that meets the standard.
Time for me to add a domain transfer lock to my domains. I suspect this'll be a popular option from here on out. I'm sorry, ICANN, but I want the default to be that nobody orders or executes changes to my domains without explicit authorization from me, preferably in writing with my signature on it (yes, I'm willing to FAX authorizations as needed).
But is it good business? They're looking at 20% of their customer base being "bad". Assuming 5% of those are "referrers" like me, that's 1% of their customer base. Except that, suppose I'm referring 10 people to them. Not just any 10 people, but usually 10 "good" customers by their profile. If I calculate that right, chasing away that 1% that contains me costs them another 10% of their customer base and 12.5% of their "good" customers. Those don't sound like winning numbers to me.
As you said, the market will decide in the end. I figure it'll take a few years but BB'll eventually end up going out of business, still wondering what happened to all their customers.
I fit the profile of a "bad" customer: I watch the rebates and advertised prices and make sure I'm not paying more than I have to. They probably want to be rid of me. But, when it comes to computer parts and systems, a lot of my friends who fit the "good" BB profile come to me for a recommendation. If BestBuy's been pushing me out, you can bet I'm not going to recommend going to them. End result: annoying me, the "bad" customer, causes "good" customers to end up somewhere else.
That's pretty much what I did to them. I had about $60 worth of assorted stuff, nothing big in itself but it added up. I was paying cash, not by check or card, so there wasn't any actual need to see my ID. The clerk insisted I had to give them my address and phone number before he could complete the sale. This was in a mall store, lots of customers, and being I was just getting off of work I was wearing pretty nice business clothes. I raised my voice so the whole store could hear and said:
"I want to buy these items. I'm paying in cash. If you don't want my money don't give me the runaround about needing my address, just say so and I'll go somewhere else.".
It was amusing how fast the clerk could close the sale without my address and phone number after that.:)
I would be upset if a company used this kind of database to refuse service to people who only bought things on sale. Yes, companies take losses on sale items. It's not the customer's job to insure they buy enough other things that the company makes a profit in the end, though. If the company doesn't want the risk of people buying only what the company is losing money on, then they should adjust their prices so they aren't losing money on it.
I can think of a way to prevent it. We've got public-key encryption hardware, and it's going to get cheaper. Suppose you have a video format that's got a slot in every frame for a cryptographic signature of that frame, and the video hardware itself is cryptographically signing the video as it records it. The private key for each camera is burned into a secured chip in the camera, and the public key is in the documentation along with the serial number and suchlike.
You can still make faked video, but you can't make faked video coming from a particular camera that'll stand up to a check of the signatures. Well, technically it's possible to do so, but you'd have to posit the ability to create a secured chip with contents of your choosing and put it into the camera without any indication of tampering and fudge the matching of the serial number and assigned key in the manufacturer's records. And of course there's also the question of numbers: if several people with no other connection to each other all have video showing the same thing, how likely is it that they all went through that trouble to fake their video and all came up with exactly the same scene on their own?
Or I could block the setTimeOut() function used to delay the thing. Again, no legit site needs to be delaying things. But I agree with others, the real fix is to tie dialogs tightly to the window/tab that opened them. I'm almost tempted to say that the prompt() function should simply fail with an error if the page it's called from isn't in the active window or tab.
I note the vulnerability Secunia found in Mozilla et. al. is easy enough to block. It depends on onMouseOver triggers and the launchTimedPrompt() function. Block either of those via the capability.policy.* settings and the problem ceases. I'm tempted to add launchTimedPrompt() blocking across the board simply because no Web site has any business launching a delayed dialog box.
The basic fallacy is that a programmer is similar to a blacksmith. He isn't. A blacksmith is the equivalent of a code-monkey: he takes a known design for an object and does the grunt work of making a physical object. He's the human equivalent of a CNC machine center. He got replaced when we could build machines that could do the actual physical work faster and cheaper than he could.
But who first came up with the designs for the parts that get built? That's the heart of programming: taking a task to be done and figuring out how to get a computer to do it. We don't need blacksmiths to forge tools anymore, but we do need metallurgists and mechanical engineers and the like to create the designs for tools we need that didn't exist before.
All those "codeless development environments" suffer from one flaw: they can't do anything that hasn't already been done. If I need a pie chart drawn and the environment doesn't have a component to draw pie charts, I can't create a pie chart until I step outside the environment and create such a component and put it into the environment. I'm not worried about my job as a programmer going away as long as people keep coming up with new things they'd like to do that nobody's done before.
Maybe it's a matter of perspective. Max's article has a lot of examples from the user's perspective, and almost none from the side of the servers actually doing the work that the user sees. As a sanity check, I recommend reading "His Share of Glory", the collected short stories of C.M. Kornbluth.
I think that some of the non-IndyMedia-affiliated groups whose data was affected by this need to file complaints with the relevant courts/agencies about their data being confiscated without a valid warrant, and file legal action against Rackspace for having turned over their data without a valid warrant for their data being presented. Don't bring IndyMedia into it, don't let the FBI or Rackspace bring them in, make the authorities explain in public why they're seizing the property of people not named in the warrants.
Given the nature of the files they claimed infringed, no reasonable person looking at those files would even have concluded that they were movies, let alone that they were the movies named in the takedown notices. If they're claiming they actually had a human being review the case before sending the letter, wouldn't that make the MPAA's violation of the DMCA knowing and willful? Seems to me that this is a perfect opportunity to tie the MPAA up in a nice double-bind.
Well, there's always user.js and the "system preferences take priority" setting. Any preferences set in user.js override the standard preferences when the browser loads. This is ideal for things like proxy configuration or automatic setup: just put the settings you want in user.js and they'll automatically get loaded when the browser is set up. You can delete user.js after the first run or just leave it there depending on your preference.
To keep users from altering certain preferences, put them in the system preferences file. Then put the setting in user.js that says that the browser should inherit system preferences and they should override user preferences, and lock user.js against user modification/removal.
Of course, as the article pointed out, many of the reasons for centralized administration of IE don't neccesarily apply to Mozilla etc.. Since many of the zone security issues aren't going to exist, you don't need to tightly control zone security settings. For things like filtering, I'd skip client administration entirely. Set up a proxy server with the filters on it, set all browsers to automatically use it, and then at the border block all outgoing traffic to the relevant ports (80, 443, 8080, possibly 20 and 21) unless it's coming from the proxy server. If you just need to block certain advertiser domains, a blackhole webserver (returns a 404 for all requests), a wildcard zonefile pointing to it and a master zone entry for the offending domains pointing to that wildcard zonefile in named.conf makes domains disappear nicely. Again, configure client machines to use your nameservers and block all outgoing DNS at the firewall except for that originating from your nameservers. With this kind of setup you don't care whether the users mess with their configurations. If they use your servers they get you rules applied, and if they try to use anything but your servers they get nothing at all. Remote administration of the clients also becomes irrelevant because all the relevant configuration is on servers you control, not clients.
The problem is that the bnetd guys said they clicked on the "I agree" button and didn't ever say they rejected the license. At that point the judge has to work under the terms of the license, and it said you were just purchasing a license to use. That's why it's critical to start with an explicit rejection of the EULA, forcing things back under the default terms of the UCC. Then you proceed with "Under this clause of the UCC, if the seller attempts to deny me use of the product I bought after the sale I'm allowed to do these things to obtain use of what I've bought.". This is where you'll want a lawyer specializing in the UCC, but in general you can do what you need to make use of the goods you bought so long as you don't damage the seller's property in the process.
True, but his ruling was based on the user's acceptance of the EULA which has terms saying you only bought a license to use. The UCC doesn't have any such language in it, and software companies will have a hard time arguing that they aren't selling copies of the software when what's delivered is a copy of the software. More importantly, there's case law under the UCC to say that the software companies are wrong and it isn't merely a license to use that they're selling when they're accepting money for and turning over physical copies.
Title 117 would also be mostly irrelevant, since such a case wouldn't involve the distribution of more copies of the program, except for the clause that says that copying a program that you legally own a copy of into memory for the purpose of running it is not a violation of copyright.
They already tried changing the rules via the UCITA. Let's haul them back to reality and say "If the state meant the terms of the UCITA to apply, they would've enacted the UCITA into law. They didn't.".
Public-key cryptography. Keys are generated using the private half of a key pair which only Blizzard holds. The checking routine has the public half of the pair needed to validate keys, but since it never needs to generate a key it's got no need for the private half. The whole point of public-key cryptography is that given only the public key it's infeasible to generate the matching private half, so having the source for the checking routine including the neccesary public key doesn't let you generate any new keys.
Not quite. The EULA is a contract. It applies restrictions to you that aren't part of the law, and it claims that if you don't accept it then you don't have any rights including the ones the law normally grants you. The GPL is a true license. It doesn't restrict you, it only grants you rights you wouldn't otherwise have under the law. If you refuse to accept the GPL you retain your rights under the law including the right to use the copy you got, you just can't do what the law normally prohibits you from doing (ie. distributing copies of someone else's copyrighted work without permission).
I think the case that needs brought isn't one based on the enforceability of an EULA. In all but a handful of states sales are governed by the terms of the Uniform Commercial Code and there's no exception for software. If the seller didn't make you sign an agreement before or when they accepted your money and gave you the goods, the UCC defines the terms of the sale and the rights you and the seller have after the sale. What we need is a case brought on the grounds "I bought this software. No other agreement was demanded at the time of the sale, so the terms of sale are those of the UCC. Since I declined the after-the-fact EULA and it's changes to the terms, what it says is irrelevant and the terms of the sale remain the terms of the sale at the time it was made. Judge, either make them justify their case under the terms of the sale or make them stop harrassing me by demanding I adhere to terms that aren't part of the contract.". This would really damage the case of companies like Blizzard, probably fatally. It'd also put them in the position of either having to forget about enforcing those unreasonable terms in the EULAs or require every mass-market sale to be preceeded by paperwork neither the customers nor the stores would find acceptable.
True, but it's hard to make something that's both human-readable and convenient for machine input. Even with computer-printed text I'm uncomfortable with the OCR error rate. But in the end the printed human-readable text takes priority over the barcode, so if the barcode's altered it's just a matter of detecting the mismatch. That can be done, as I said, by random validation. If someone alters any more than a handful of ballots it's going to be hard to avoid having a random validation catch at least a few of them, and given the setup any discrepancy between the barcode and manual counts, even by a single vote, indicates an error.
That's the beauty of an audit trail such as a human-readable ballot: we don't need to depend on the accuracy of the machine, we can check the accuracy. It won't help if we don't check, but if we do we can catch any attempt at fudging the numbers. Same principles as any auditor applies to finding errors in the day's receipts.
He covered that. The barcode is in addition to large, clear printed text. You can check for corruption by picking some ballot boxes at random, hand-tallying the votes based on the printed text and comparing that to the scanned totals for that box. If they differ, you go back and manually re-count the election based on the printed text the same as we do now (except that with computer-printed text you don't have to worry about illegible or unclear ballots).
A more interesting question is whether a takedown notice from a party who does not own the copyright on the material in question and who, given the nature of the material subject to the notice, could not reasonably have believed they owned the copyright constitutes illegal interference with the right of the copyright holder to distribute his works, and if so exactly what civil and criminal penalties does the law prescribe?
The difference lies not in the number of vulnerabilities. All software, open or closed source, will have holes in it. That'll be the case until we have a system in place to write completely bug-free code and a system to insure vulnerability-free specifications (the worst security problems aren't bugs, they're design features which favor convenience over security). The difference lies in what happens when a vulnerability is discovered. In closed-source software, we've seen time and time again that the response by the vendor is almost always to conceal the problem and deny it exists. In open-source software, by contrast, vulnerabilities are almost always published fairly quickly and fixes made available rapidly. That's because nobody is at the mercy of the original author for a fix. The people who discovered the problem can publish a code fix along with the details of the problem. People affected by the problem can patch the code themselves, if it's important enough.
In addition, security holes by design tend to get eliminated from open-source software. In proprietary software, if an insecure design feature benefits the vendor it's unlikely to be removed short of open revolt by the users. In open-source software if there's another way to do it that provides less security exposure and the original author won't change the design, someone else tends to get fed up, make the change and make the patch available. Eventually the original author either has to bow to user preference or find his own version of the software being ignored in favor of one that does.
Slashdot Mirror
Trust me, you do not want this behavior changed. You see, Mozilla and IE used to allow this. Then the bad guys figured out that you could ferret out the local filenames things were cached under, load your own malicious code into the cache in an innocuous way, then refer to it as a local resource in a dangerous way. Since it was a local resource it could do things a remote resource wouldn't be allowed to do. So Mozilla drew a one-way wall: local resources can refer to remote resources, but remote resources aren't allowed to refer to local resources directly. They looked at being type-selective, but concluded that if they did someone would always be able to finagle a way to turn that into arbitrary access, so the only safe thing was to block across the board based on the local/remote nature of the protocol.
IE tried to avoid this and be more selective. The result has been a fairly steady stream of zone-escalation exploits for it. To put it plainly, you can't open just one hole.
And frankly, if your page is remote, why are you assuming a local file exists at a particular location? You should be referring to your own resources, not someone else's.
I don't think it was considered, or if it was it was hand-waved away. For example, in section 3 they list the reasons a registrar of record may deny a transfer, then explicitly say that those are the only reasons. Lack of response is explicitly not a reason to block the transfer. If they'd considered the situation, then lack of response (contact/registrant on vacation or somesuch) would be reason to block the transfer until the contact/registrant could authorize it. Also note that in section 6, the first condition for reversal of a transfer, the one speaking to mistakes, requires the gaining registrar to agree that it was a mistake. If the registrar of record and the original registrant both agree that no transfer was authorized (and the registrant should know whether they authorized it) and the gaining registrar (who in the case of an unscrupulous registrar stands to benefit from the transfer) refuses to agree, the transfer doesn't get reversed. Again, if my scenario had been considered significant, the gaining registrar would be the one party who wouldn't have a say in whether authorization was given.
The only protection seems to be in section 5 for those gTLDs that use EPP. There an authorization code has to be obtained from the registrar of record and then presented by the gaining registrar before the transfer is approved. That's the only part of the rules I like, since the AuthInfo code could only have gotten to the gaining registrar if the registrant gave it to them. This or the equivalent should be the rule for all TLDs, all registrars.
IMHO this policy is a step backwards. Where under the old rules I could have a problem with a party with whom I have a legally-binding agreement (which may be a bad one, but at least I knew the terms) and some leverage in court if worst comes to worst, under this policy my problems will come from a party I don't even know was causing a problem and with whom I have no legal leverage at all beyond the (completely ineffectual IMO, or we wouldn't have had balking-registrar problems in the first place) ICANN dispute processes. Better the devil I know than the devil I don't.
That's all well and good, but for a few things:
- Not all "registrants" are honest. If they were, we wouldn't have seen some of the games we've seen played with domain registrations in recent years).
- Not all registrars are conscientious or ethical. If they were, we wouldn't see those "invoices" from registrars claiming you have to pay them to keep your domain even though it's registered with a completely different registrar, or registrars balking at making legitimate and correctly authorized transfers.
- ICANN doesn't seem to enforce the rules very well. If they did, the whole problem of registrars balking at legitimate transfers wouldn't have been a problem after the first registrar or two lost their credentials over it.
Given the above, I can easily envisage a situation where either a "registrant" gave false information to a not-too-conscientious registrar or a flat-out unscrupulous registrar simply sent in a transfer order for a domain they wanted. In some TLDs I believe there's some authorization going on, but in most the new rules put the trust in the gaining registrar, the one party we don't know has a contractual relationship with the actual registrant, to be honest and conscientious.My opinion is that any transfer rules should include one principle: a transfer may only occur upon notice from the registrant or admin contract for the domain to the registrar of record that they're transferring the domain. If balking registrars of record is the problem, define a standard for reasonable authorization and revoke the certification of any registrar who balks at a transfer after receiving authorization that meets the standard.
Time for me to add a domain transfer lock to my domains. I suspect this'll be a popular option from here on out. I'm sorry, ICANN, but I want the default to be that nobody orders or executes changes to my domains without explicit authorization from me, preferably in writing with my signature on it (yes, I'm willing to FAX authorizations as needed).
But is it good business? They're looking at 20% of their customer base being "bad". Assuming 5% of those are "referrers" like me, that's 1% of their customer base. Except that, suppose I'm referring 10 people to them. Not just any 10 people, but usually 10 "good" customers by their profile. If I calculate that right, chasing away that 1% that contains me costs them another 10% of their customer base and 12.5% of their "good" customers. Those don't sound like winning numbers to me.
As you said, the market will decide in the end. I figure it'll take a few years but BB'll eventually end up going out of business, still wondering what happened to all their customers.
I fit the profile of a "bad" customer: I watch the rebates and advertised prices and make sure I'm not paying more than I have to. They probably want to be rid of me. But, when it comes to computer parts and systems, a lot of my friends who fit the "good" BB profile come to me for a recommendation. If BestBuy's been pushing me out, you can bet I'm not going to recommend going to them. End result: annoying me, the "bad" customer, causes "good" customers to end up somewhere else.
That's pretty much what I did to them. I had about $60 worth of assorted stuff, nothing big in itself but it added up. I was paying cash, not by check or card, so there wasn't any actual need to see my ID. The clerk insisted I had to give them my address and phone number before he could complete the sale. This was in a mall store, lots of customers, and being I was just getting off of work I was wearing pretty nice business clothes. I raised my voice so the whole store could hear and said:
"I want to buy these items. I'm paying in cash. If you don't want my money don't give me the runaround about needing my address, just say so and I'll go somewhere else.".
It was amusing how fast the clerk could close the sale without my address and phone number after that. :)
I would be upset if a company used this kind of database to refuse service to people who only bought things on sale. Yes, companies take losses on sale items. It's not the customer's job to insure they buy enough other things that the company makes a profit in the end, though. If the company doesn't want the risk of people buying only what the company is losing money on, then they should adjust their prices so they aren't losing money on it.
I can think of a way to prevent it. We've got public-key encryption hardware, and it's going to get cheaper. Suppose you have a video format that's got a slot in every frame for a cryptographic signature of that frame, and the video hardware itself is cryptographically signing the video as it records it. The private key for each camera is burned into a secured chip in the camera, and the public key is in the documentation along with the serial number and suchlike.
You can still make faked video, but you can't make faked video coming from a particular camera that'll stand up to a check of the signatures. Well, technically it's possible to do so, but you'd have to posit the ability to create a secured chip with contents of your choosing and put it into the camera without any indication of tampering and fudge the matching of the serial number and assigned key in the manufacturer's records. And of course there's also the question of numbers: if several people with no other connection to each other all have video showing the same thing, how likely is it that they all went through that trouble to fake their video and all came up with exactly the same scene on their own?
Or I could block the setTimeOut() function used to delay the thing. Again, no legit site needs to be delaying things. But I agree with others, the real fix is to tie dialogs tightly to the window/tab that opened them. I'm almost tempted to say that the prompt() function should simply fail with an error if the page it's called from isn't in the active window or tab.
I note the vulnerability Secunia found in Mozilla et. al. is easy enough to block. It depends on onMouseOver triggers and the launchTimedPrompt() function. Block either of those via the capability.policy.* settings and the problem ceases. I'm tempted to add launchTimedPrompt() blocking across the board simply because no Web site has any business launching a delayed dialog box.
The basic fallacy is that a programmer is similar to a blacksmith. He isn't. A blacksmith is the equivalent of a code-monkey: he takes a known design for an object and does the grunt work of making a physical object. He's the human equivalent of a CNC machine center. He got replaced when we could build machines that could do the actual physical work faster and cheaper than he could.
But who first came up with the designs for the parts that get built? That's the heart of programming: taking a task to be done and figuring out how to get a computer to do it. We don't need blacksmiths to forge tools anymore, but we do need metallurgists and mechanical engineers and the like to create the designs for tools we need that didn't exist before.
All those "codeless development environments" suffer from one flaw: they can't do anything that hasn't already been done. If I need a pie chart drawn and the environment doesn't have a component to draw pie charts, I can't create a pie chart until I step outside the environment and create such a component and put it into the environment. I'm not worried about my job as a programmer going away as long as people keep coming up with new things they'd like to do that nobody's done before.
Maybe it's a matter of perspective. Max's article has a lot of examples from the user's perspective, and almost none from the side of the servers actually doing the work that the user sees. As a sanity check, I recommend reading "His Share of Glory", the collected short stories of C.M. Kornbluth.
I think that some of the non-IndyMedia-affiliated groups whose data was affected by this need to file complaints with the relevant courts/agencies about their data being confiscated without a valid warrant, and file legal action against Rackspace for having turned over their data without a valid warrant for their data being presented. Don't bring IndyMedia into it, don't let the FBI or Rackspace bring them in, make the authorities explain in public why they're seizing the property of people not named in the warrants.
Given the nature of the files they claimed infringed, no reasonable person looking at those files would even have concluded that they were movies, let alone that they were the movies named in the takedown notices. If they're claiming they actually had a human being review the case before sending the letter, wouldn't that make the MPAA's violation of the DMCA knowing and willful? Seems to me that this is a perfect opportunity to tie the MPAA up in a nice double-bind.
Well, there's always user.js and the "system preferences take priority" setting. Any preferences set in user.js override the standard preferences when the browser loads. This is ideal for things like proxy configuration or automatic setup: just put the settings you want in user.js and they'll automatically get loaded when the browser is set up. You can delete user.js after the first run or just leave it there depending on your preference.
To keep users from altering certain preferences, put them in the system preferences file. Then put the setting in user.js that says that the browser should inherit system preferences and they should override user preferences, and lock user.js against user modification/removal.
Of course, as the article pointed out, many of the reasons for centralized administration of IE don't neccesarily apply to Mozilla etc.. Since many of the zone security issues aren't going to exist, you don't need to tightly control zone security settings. For things like filtering, I'd skip client administration entirely. Set up a proxy server with the filters on it, set all browsers to automatically use it, and then at the border block all outgoing traffic to the relevant ports (80, 443, 8080, possibly 20 and 21) unless it's coming from the proxy server. If you just need to block certain advertiser domains, a blackhole webserver (returns a 404 for all requests), a wildcard zonefile pointing to it and a master zone entry for the offending domains pointing to that wildcard zonefile in named.conf makes domains disappear nicely. Again, configure client machines to use your nameservers and block all outgoing DNS at the firewall except for that originating from your nameservers. With this kind of setup you don't care whether the users mess with their configurations. If they use your servers they get you rules applied, and if they try to use anything but your servers they get nothing at all. Remote administration of the clients also becomes irrelevant because all the relevant configuration is on servers you control, not clients.
The problem is that the bnetd guys said they clicked on the "I agree" button and didn't ever say they rejected the license. At that point the judge has to work under the terms of the license, and it said you were just purchasing a license to use. That's why it's critical to start with an explicit rejection of the EULA, forcing things back under the default terms of the UCC. Then you proceed with "Under this clause of the UCC, if the seller attempts to deny me use of the product I bought after the sale I'm allowed to do these things to obtain use of what I've bought.". This is where you'll want a lawyer specializing in the UCC, but in general you can do what you need to make use of the goods you bought so long as you don't damage the seller's property in the process.
True, but his ruling was based on the user's acceptance of the EULA which has terms saying you only bought a license to use. The UCC doesn't have any such language in it, and software companies will have a hard time arguing that they aren't selling copies of the software when what's delivered is a copy of the software. More importantly, there's case law under the UCC to say that the software companies are wrong and it isn't merely a license to use that they're selling when they're accepting money for and turning over physical copies.
Title 117 would also be mostly irrelevant, since such a case wouldn't involve the distribution of more copies of the program, except for the clause that says that copying a program that you legally own a copy of into memory for the purpose of running it is not a violation of copyright.
They already tried changing the rules via the UCITA. Let's haul them back to reality and say "If the state meant the terms of the UCITA to apply, they would've enacted the UCITA into law. They didn't.".
Public-key cryptography. Keys are generated using the private half of a key pair which only Blizzard holds. The checking routine has the public half of the pair needed to validate keys, but since it never needs to generate a key it's got no need for the private half. The whole point of public-key cryptography is that given only the public key it's infeasible to generate the matching private half, so having the source for the checking routine including the neccesary public key doesn't let you generate any new keys.
Not quite. The EULA is a contract. It applies restrictions to you that aren't part of the law, and it claims that if you don't accept it then you don't have any rights including the ones the law normally grants you. The GPL is a true license. It doesn't restrict you, it only grants you rights you wouldn't otherwise have under the law. If you refuse to accept the GPL you retain your rights under the law including the right to use the copy you got, you just can't do what the law normally prohibits you from doing (ie. distributing copies of someone else's copyrighted work without permission).
I think the case that needs brought isn't one based on the enforceability of an EULA. In all but a handful of states sales are governed by the terms of the Uniform Commercial Code and there's no exception for software. If the seller didn't make you sign an agreement before or when they accepted your money and gave you the goods, the UCC defines the terms of the sale and the rights you and the seller have after the sale. What we need is a case brought on the grounds "I bought this software. No other agreement was demanded at the time of the sale, so the terms of sale are those of the UCC. Since I declined the after-the-fact EULA and it's changes to the terms, what it says is irrelevant and the terms of the sale remain the terms of the sale at the time it was made. Judge, either make them justify their case under the terms of the sale or make them stop harrassing me by demanding I adhere to terms that aren't part of the contract.". This would really damage the case of companies like Blizzard, probably fatally. It'd also put them in the position of either having to forget about enforcing those unreasonable terms in the EULAs or require every mass-market sale to be preceeded by paperwork neither the customers nor the stores would find acceptable.
True, but it's hard to make something that's both human-readable and convenient for machine input. Even with computer-printed text I'm uncomfortable with the OCR error rate. But in the end the printed human-readable text takes priority over the barcode, so if the barcode's altered it's just a matter of detecting the mismatch. That can be done, as I said, by random validation. If someone alters any more than a handful of ballots it's going to be hard to avoid having a random validation catch at least a few of them, and given the setup any discrepancy between the barcode and manual counts, even by a single vote, indicates an error.
That's the beauty of an audit trail such as a human-readable ballot: we don't need to depend on the accuracy of the machine, we can check the accuracy. It won't help if we don't check, but if we do we can catch any attempt at fudging the numbers. Same principles as any auditor applies to finding errors in the day's receipts.
He covered that. The barcode is in addition to large, clear printed text. You can check for corruption by picking some ballot boxes at random, hand-tallying the votes based on the printed text and comparing that to the scanned totals for that box. If they differ, you go back and manually re-count the election based on the printed text the same as we do now (except that with computer-printed text you don't have to worry about illegible or unclear ballots).
A more interesting question is whether a takedown notice from a party who does not own the copyright on the material in question and who, given the nature of the material subject to the notice, could not reasonably have believed they owned the copyright constitutes illegal interference with the right of the copyright holder to distribute his works, and if so exactly what civil and criminal penalties does the law prescribe?
The difference lies not in the number of vulnerabilities. All software, open or closed source, will have holes in it. That'll be the case until we have a system in place to write completely bug-free code and a system to insure vulnerability-free specifications (the worst security problems aren't bugs, they're design features which favor convenience over security). The difference lies in what happens when a vulnerability is discovered. In closed-source software, we've seen time and time again that the response by the vendor is almost always to conceal the problem and deny it exists. In open-source software, by contrast, vulnerabilities are almost always published fairly quickly and fixes made available rapidly. That's because nobody is at the mercy of the original author for a fix. The people who discovered the problem can publish a code fix along with the details of the problem. People affected by the problem can patch the code themselves, if it's important enough.
In addition, security holes by design tend to get eliminated from open-source software. In proprietary software, if an insecure design feature benefits the vendor it's unlikely to be removed short of open revolt by the users. In open-source software if there's another way to do it that provides less security exposure and the original author won't change the design, someone else tends to get fed up, make the change and make the patch available. Eventually the original author either has to bow to user preference or find his own version of the software being ignored in favor of one that does.
Proof once again that this sign is appropriate. In this case we need to s/use the Internet/design secure hardware/, but you get the picture. :)