I haven't played it, but in my uninformed opinion, if it can evoke such strong emotions, ie. "I couldn't bring myself to push the buttons to continue", it has something to it. I can't bring myself to play it, but for the same reason as I can't bring myself to watch movies or documentaries about concentration camps and similar horrors.
I suppose in one sense, the designers of the game failed, in that they didn't evoke enough empathy with the characters to get the player to react in the same way as the people did. But in another respect, they certainly garnered enough empathy for the victims. And that's what art is all about; evoking emotions.
Patents are the copyright for physical objects. DRM is a technologically enforced copy limitation. Patents and copyright are legally enforced. A technological DRM for physical objects might be some kind of shape that 3D printers are legally required to recognize and not print without a cryptographically signed token of some sort.
More along these lines, create a seed password, set it in the source and in the database. Have the application randomly (this is the hard part) change the password in a non deterministic manner, changing it first in a backup config file, then on the database server, then in the main config file. (In case of failure, the admin can copy the password from the backup config file to the main config file.) Possibly have the application rotate the password every so often. This protects the password from someone who has access to the source in some repository, but not to the machine the app is running on.
Of course, I may be answering the wrong question. If the application has access to the database, and a person has admin access to the machine the application is running on, there is no way that you can stop a determined adversary from getting access to the database with the same credentials as the application. (This can be logically proven quite simply.) At best, you can make it more difficult with obfuscation techniques all along the path the password must travel. (Obfuscate the password on disk, and obfuscate the unobfuscation code. Keep the password in memory for the shortest amount of time possible. When sending the password to the network, encrypt it in some form first. And using something like a dynamicly linked libssl means you send the password in plaintext to the library, which is then trivial to capture. Not to mention this violates the shortest amount of time possible in memory rule.)
If the person you are hiding the password from has access to the machine the app is running on, but does not have admin access, the answer is trivial. Put the password someplace they don't have access. Of course, then you must secure the machine, but that's an entirely different story.
In addition, I would try to attack the methodology in terms of the code used to obtain the IP address. How would you prove that the IP address in question is not a product of a bug in the software? And more importantly, how can I verify your claims? This brings up interesting (to me) open source/access to closed source binaries issues.
I'd also recommend avoiding WebTrends. Where it would take 12-18 hours to process log files, Analog runs in a fraction of the time (under an hour).
My issues with Analog are that I haven't discovered how to make it only parse each log file only once, and I haven't discovered any way to have it display stats for different time periods (ie. daily/weekly/monthly/quarterly/annually) all on one page. I'm not sure if these are real faults with the program, or if I just didn't figure out how to do it yet,so YMMV.
Incidentally, a subdomain under blackboxvoting.org such as www2.blackboxvoting.org instead of an entirely new domain would belay quite a bit of suspicion, albeit we slashdotters are generally a paranoid bunch.
I was disputing the "evidence" that paypalsucks.com is run by a competitor. I don't know if it is or not, but "anonymous" domain registrations are extremely common, and 995merchantaccounts.com looks like just like a standard commercial merchant account. Identification of your contact as "Administrator" is common in that typically in a large organization, a role is responsible for the domain rather than a person. So, the Administrator is responsible rather than George in IT.
Paypal is evil in that they act like a bank yet don't obey the banking rules. One example is if there is a dispute, they hold on to the money from both ends, but there are other issues I've heard about.
Merchant processors are evil in that they charge both ends, and if there is any dispute, they almost always side with the consumer rather than the merchant. Even if the dispute is resolved in the merchant's favour, they are still charged a hefty sum simply because the dispute occured. That's from the merchant's point of few. The evils of credit cards from the consumer's point of view should be readily apparent.
Finally, a real merchant account may be more expensive than a paypal account for processing credit cards, but considering Paypal's track record, I sleep better at night with the real thing. And that's one of the prime decision making factors for many small business owners, considering how easy it is to make a mistake and go under.
Hackers tend to use quotes as balanced delimiters like parentheses, much to the dismay of American editors. Thus, if "Jim is going" is a phrase, and so are "Bill runs" and "Spock groks", then hackers generally prefer to write: "Jim is going", "Bill runs", and "Spock groks". This is incorrect according to standard American usage (which would put the continuation commas and the final period inside the string quotes); however, it is counter-intuitive to hackers to mutilate literal strings with characters that don't belong in them. Given the sorts of examples that can come up in discussions of programming, American-style quoting can even be grossly misleading. When communicating command lines or small pieces of code, extra characters can be a real pain in the neck.
Consider, for example, a sentence in a vi tutorial that looks like this:
Then delete a line from the file by typing "dd".
Standard usage would make this
Then delete a line from the file by typing "dd."
but that would be very bad -- because the reader would be prone to type the string d-d-dot, and it happens that in vi(1), dot repeats the last command accepted. The net result would be to delete two lines! [...]
Interestingly, a similar style is now preferred practice in Great Britain, though the older style (which became established for typographical reasons having to do with the aesthetics of comma and quotes in typeset text) is still accepted there. Hart's Rules and the Oxford Dictionary for Writers and Editors call the hacker-like style 'new' or 'logical' quoting. This returns British English to the style many other languages (including Spanish, French, Italian, Catalan, and German) have been using all along.
In this case, the voting package is not being distributed, therefore the GPL (2 or 3) would not give the voters any extra rights to the source code.
In the particular case of the voting machine manufacterer giving the machine to the elections board, they would also have to provide the source code and signing keys to the elections board as well, and I see this as a good thing. The elections board would not be obligated (by the GPL) to hand out the keys to anyone, (or even to request them from the manufacturer, if they don't trust their own security.)
(This is how I understand it anyway. I may have missed some points.)
Similar story. A customer would call every day at about the same time complaining that "My email isn't working!" Naturally, she'd be extremely upset and argumentative, making everything take longer than necessary. "Are you connected to the Internet?" "No, should I be?" "Yes. Your email won't work if you aren't connected to the Internet." "Oh, OK, it's working now." *click* Eventually she cancelled her account with us because we were so unreliable.
Ideally, you'd have some kind of barrier between the programmers and those who wish to influence the design process. Maybe a person. Let's call that barrier person a "manager" for the sake of convenience. Let's formalize his responsibility to include filtering outside requests into a managable format for the developers, and maintaining a vision for the project. That'd be a pretty slick way to run things.
Hrmmm, it seems you may have a point. At first I thought that the DMCA(b) may apply, but it specifically states: no copy of the material made by the service provider in the course of such intermediate or transient storage is maintained on the system or network in a manner ordinarily accessible to anyone other than anticipated recipients, and no such copy is maintained on the system or network in a manner ordinarily accessible to such anticipated recipients for a longer period than is reasonably necessary for the transmission, routing, or provision of connections
Actually, fair use can include making a copy of an entire work. There are different types of fair use. Quoting for the sake of review is probably the one you're thinking of. Making a copy for the sake of having a backup copy is also considered fair use, and involves making a duplicate of the entire work. Copying data in the process of using it (ie. a temporary copy of software into memory) is also fair use.
And please, no strawman arguments involving distribution. I'm just talking about copying.
You can use p2p as a distribution method and retain central control if you use public key encryption to sign any "official" directives.
DNS is a lousy verification procedure anyway. SSL is decent, but has flaws as currently implemented IMO. (Specifically in trust delegation, sometimes keys are sent via email. Email addresses are only as trustworthy as dns, and you can also have eavesdroppers intercept those emails on the wire as well.)
A good p2p distribution method would let you choose which public keys you trust to sign directives, allowing multiple authorities. Thus if one authority is compromised, other authorities can step up. The difficult part is choosing who you can trust, but that is always difficult.
Double encrypting data with different cyphers and different keys gives you the security of the stronger of the two algorithms plus a percentage (from 0 to 100%) of the security of the weaker algorithm, depending on the mathematical interactions of the two cyphers.
If you get decreased security from double encrypting with different keys, the algorithm is broken, and you have to redefine the strength of the cypher to take that into account, and everything remains true.
Double encrypting data with different cyphers with the same key potentially destroys the security of both cyphers.
Slashdot Mirror
IANAL, as most people aren't, but I would think mistake would have no intent, and misidentification may have intent.
I haven't played it, but in my uninformed opinion, if it can evoke such strong emotions, ie. "I couldn't bring myself to push the buttons to continue", it has something to it. I can't bring myself to play it, but for the same reason as I can't bring myself to watch movies or documentaries about concentration camps and similar horrors.
I suppose in one sense, the designers of the game failed, in that they didn't evoke enough empathy with the characters to get the player to react in the same way as the people did. But in another respect, they certainly garnered enough empathy for the victims. And that's what art is all about; evoking emotions.
Patents are the copyright for physical objects. DRM is a technologically enforced copy limitation. Patents and copyright are legally enforced. A technological DRM for physical objects might be some kind of shape that 3D printers are legally required to recognize and not print without a cryptographically signed token of some sort.
More along these lines, create a seed password, set it in the source and in the database. Have the application randomly (this is the hard part) change the password in a non deterministic manner, changing it first in a backup config file, then on the database server, then in the main config file. (In case of failure, the admin can copy the password from the backup config file to the main config file.) Possibly have the application rotate the password every so often. This protects the password from someone who has access to the source in some repository, but not to the machine the app is running on.
Of course, I may be answering the wrong question. If the application has access to the database, and a person has admin access to the machine the application is running on, there is no way that you can stop a determined adversary from getting access to the database with the same credentials as the application. (This can be logically proven quite simply.) At best, you can make it more difficult with obfuscation techniques all along the path the password must travel. (Obfuscate the password on disk, and obfuscate the unobfuscation code. Keep the password in memory for the shortest amount of time possible. When sending the password to the network, encrypt it in some form first. And using something like a dynamicly linked libssl means you send the password in plaintext to the library, which is then trivial to capture. Not to mention this violates the shortest amount of time possible in memory rule.)
If the person you are hiding the password from has access to the machine the app is running on, but does not have admin access, the answer is trivial. Put the password someplace they don't have access. Of course, then you must secure the machine, but that's an entirely different story.
In addition, I would try to attack the methodology in terms of the code used to obtain the IP address. How would you prove that the IP address in question is not a product of a bug in the software? And more importantly, how can I verify your claims? This brings up interesting (to me) open source/access to closed source binaries issues.
Like any other bit of software, if you delete it, stick the CD in and reinstall it.
I'd also recommend avoiding WebTrends. Where it would take 12-18 hours to process log files, Analog runs in a fraction of the time (under an hour).
My issues with Analog are that I haven't discovered how to make it only parse each log file only once, and I haven't discovered any way to have it display stats for different time periods (ie. daily/weekly/monthly/quarterly/annually) all on one page. I'm not sure if these are real faults with the program, or if I just didn't figure out how to do it yet,so YMMV.
Incidentally, a subdomain under blackboxvoting.org such as www2.blackboxvoting.org instead of an entirely new domain would belay quite a bit of suspicion, albeit we slashdotters are generally a paranoid bunch.
It seems to me that by putting the files up, they are giving permission to distribute them. Hence, no copyright infringement occurs.
I think we're losing sight of the big picture. What are their IPs, so I can block them on my mail server directly and indefinitely?
Printer Friendly link for those of us who hate clicking next every 2 seconds.
t ent&task=view&id=3962&Itemid=2&pop=1&page=0
http://www.next-gen.biz/index2.php?option=com_con
I was disputing the "evidence" that paypalsucks.com is run by a competitor. I don't know if it is or not, but "anonymous" domain registrations are extremely common, and 995merchantaccounts.com looks like just like a standard commercial merchant account. Identification of your contact as "Administrator" is common in that typically in a large organization, a role is responsible for the domain rather than a person. So, the Administrator is responsible rather than George in IT.
Paypal is evil in that they act like a bank yet don't obey the banking rules. One example is if there is a dispute, they hold on to the money from both ends, but there are other issues I've heard about.
Merchant processors are evil in that they charge both ends, and if there is any dispute, they almost always side with the consumer rather than the merchant. Even if the dispute is resolved in the merchant's favour, they are still charged a hefty sum simply because the dispute occured. That's from the merchant's point of few. The evils of credit cards from the consumer's point of view should be readily apparent.
Finally, a real merchant account may be more expensive than a paypal account for processing credit cards, but considering Paypal's track record, I sleep better at night with the real thing. And that's one of the prime decision making factors for many small business owners, considering how easy it is to make a mistake and go under.
That looks like a pretty standard merchant account. Authorize.net is nearly identical.
Merchant accounts are their own particular brand of evil, but less evil than Paypal, as they have their own particular rules that they follow.
http://catb.org/jargon/html/writing-style.html has a pretty good explanation.
Hackers tend to use quotes as balanced delimiters like parentheses, much to the dismay of American editors. Thus, if "Jim is going" is a phrase, and so are "Bill runs" and "Spock groks", then hackers generally prefer to write: "Jim is going", "Bill runs", and "Spock groks". This is incorrect according to standard American usage (which would put the continuation commas and the final period inside the string quotes); however, it is counter-intuitive to hackers to mutilate literal strings with characters that don't belong in them. Given the sorts of examples that can come up in discussions of programming, American-style quoting can even be grossly misleading. When communicating command lines or small pieces of code, extra characters can be a real pain in the neck.
Consider, for example, a sentence in a vi tutorial that looks like this:
Then delete a line from the file by typing "dd".
Standard usage would make this
Then delete a line from the file by typing "dd."
but that would be very bad -- because the reader would be prone to type the string d-d-dot, and it happens that in vi(1), dot repeats the last command accepted. The net result would be to delete two lines!
[...]
Interestingly, a similar style is now preferred practice in Great Britain, though the older style (which became established for typographical reasons having to do with the aesthetics of comma and quotes in typeset text) is still accepted there. Hart's Rules and the Oxford Dictionary for Writers and Editors call the hacker-like style 'new' or 'logical' quoting. This returns British English to the style many other languages (including Spanish, French, Italian, Catalan, and German) have been using all along.
In this case, the voting package is not being distributed, therefore the GPL (2 or 3) would not give the voters any extra rights to the source code.
In the particular case of the voting machine manufacterer giving the machine to the elections board, they would also have to provide the source code and signing keys to the elections board as well, and I see this as a good thing. The elections board would not be obligated (by the GPL) to hand out the keys to anyone, (or even to request them from the manufacturer, if they don't trust their own security.)
(This is how I understand it anyway. I may have missed some points.)
Similar story. A customer would call every day at about the same time complaining that "My email isn't working!" Naturally, she'd be extremely upset and argumentative, making everything take longer than necessary.
"Are you connected to the Internet?"
"No, should I be?"
"Yes. Your email won't work if you aren't connected to the Internet."
"Oh, OK, it's working now." *click*
Eventually she cancelled her account with us because we were so unreliable.
How to kill yourself with a 9 volt battery:h tml
http://www.darwinawards.com/darwin/darwin1999-50.
I assume a car battery would have an even easier time.
Ideally, you'd have some kind of barrier between the programmers and those who wish to influence the design process. Maybe a person. Let's call that barrier person a "manager" for the sake of convenience. Let's formalize his responsibility to include filtering outside requests into a managable format for the developers, and maintaining a vision for the project. That'd be a pretty slick way to run things.
Hrmmm, it seems you may have a point. At first I thought that the DMCA(b) may apply, but it specifically states:
no copy of the material made by the service provider in the course of such intermediate or transient storage is maintained on the system or network in a manner ordinarily accessible to anyone other than anticipated recipients, and no such copy is maintained on the system or network in a manner ordinarily accessible to such anticipated recipients for a longer period than is reasonably necessary for the transmission, routing, or provision of connections
Actually, fair use can include making a copy of an entire work. There are different types of fair use. Quoting for the sake of review is probably the one you're thinking of. Making a copy for the sake of having a backup copy is also considered fair use, and involves making a duplicate of the entire work. Copying data in the process of using it (ie. a temporary copy of software into memory) is also fair use.
And please, no strawman arguments involving distribution. I'm just talking about copying.
You can use p2p as a distribution method and retain central control if you use public key encryption to sign any "official" directives.
DNS is a lousy verification procedure anyway. SSL is decent, but has flaws as currently implemented IMO. (Specifically in trust delegation, sometimes keys are sent via email. Email addresses are only as trustworthy as dns, and you can also have eavesdroppers intercept those emails on the wire as well.)
A good p2p distribution method would let you choose which public keys you trust to sign directives, allowing multiple authorities. Thus if one authority is compromised, other authorities can step up. The difficult part is choosing who you can trust, but that is always difficult.
You can say you're shipping a one time pad for future communications.
It was Radio Electronics. IIRC, the magazine merged with some other magazine (and died in the process) which merged with Popular Electronics.
Double encrypting data with different cyphers and different keys gives you the security of the stronger of the two algorithms plus a percentage (from 0 to 100%) of the security of the weaker algorithm, depending on the mathematical interactions of the two cyphers.
If you get decreased security from double encrypting with different keys, the algorithm is broken, and you have to redefine the strength of the cypher to take that into account, and everything remains true.
Double encrypting data with different cyphers with the same key potentially destroys the security of both cyphers.
In my experience, start time was a major factor in IE's dominance.