Just to clarify: A language does not need to be context-free in order to be parsed by a recursive descent parser, because you can augment the recursive functions with extra arguments that provide, well, context. For instance:
[exp]::= x | let [dec] in [exp] end | n | print [exp]
[dec]::= val x = [exp]
(where x is the set of variables and n is the set of integer constants)
This language is context-free, but the following restriction isn't: We say that strings are only in this language if variables aren't used before being declared. Legal:
let
val x = 3 in
print x end
Illegal:
let
val x = 3 in
print y end
This language isn't context-free (in the usual sense) but can be parsed easily by a recursive function. That function simply takes with it a list of all the declared variables. (In fact, you can pull this same sort of hack with lex/yac by having the lexer make a call into your code, which keeps a symbol table of variables it has seen as it runs.)
(If I understand the problem with C and C++ correctly, the difficulty parsing has to do with recognizing a token as a type name or an identifier, so I think this is relevant.)
Great... that will make using C++ templates and stuff a bit nicer... (Of course, SML and O'Caml (and related languages) have had much more sophisticated type inference for 30 years!)
There are about x / (ln x - 1) primes less than x, so there are about
227744933553988775903557975254897476817787897601 94 13955752667049156071539032268561888456759092523852 26840859485002804929486395765683516004898436591870 67148076554529504792809085095276779696724529102225 25608461421302099522103073978587867378036538137453 88172275208148731803295108467519843612456324165778 22681833625323037116520381032399426754453484747128 98895442005502311885787951105899116301208615827545 04419427244140970531796034937268154702619069093754 03532933958584374295760895574495930343271125392053 18511525199482501616282311294457575661607859419759 65027029905582349776107150425077368604313940757969 37005679771832.. primes less than 2^2048. That's a lot. Just for comparison, there are just 4294967296 memory addresses on a 32-bit computer.
I've been told that the checksum isn't actually checked by windows -- apparently, my program updates it incorrectly (using an 8-bit sum instead of a 32-bit one) and doesn't update some other global header checksum. I haven't fixed the program in case I ever end up going to court over it (where it might matter that I haven't touched the page in 6 years), and because it works anyway...
> But isn't one of the "advantages" of Palladium that your friendly neighborhood viruses can no longer run and erase your > MP3s/JPGs/etc, because they are not "trusted" code? I'm not sure how that will relate to unsigned VB scripts. It's designed > to protect the consumer from themselves... and legislate what (Microsoft's, I assume) programmers could not implement > properly.
No, Palladium won't help with that. Most viruses and trojans today are just memory resident processes like any other. There is no easy way to separate a "good" program from a "virus" program. (Seriously, how would it? And how would it be able to tell if a "good" program had an exploitable backdoor or buffer-overflow in it?) It's true that palladium might protect you against, say, boot sector viruses, but there are ways a properly implemented operating system can do this, too.
We already have all the hardware we need to provide computer security (namely, protected memory). Palladium's only purpose is removing the ability for users to inspect and modify their own computers (in an attempt to make DRM schemes fly), so don't listen to what they tell you!
Uh, then I think you understand. Palladium is designed essentially to prevent you from using debugging hardware or software to circumvent copy-control mechanisms. It is a key ingredient in the enslavement of the media consumer. What do you think it's for, and how do current OS techniques not address that?
I told AMI (link in the article: marketing@ami.com) that I don't think of this as a "feature". Computer manufacturers have backed down on much less invasive technologies (Pentium III's unique ID, for instance) before; I'm still a little bit hopeful that with all the competition in the mainboard scene we might be able to convince manufacturers not to adopt consumer-hostile technology like this.
I wouldn't say SSH1 is "easily cracked". All ettercap does is a man-in-the-middle attack, something which the default configuration of openssh, at least, provides a huge warning about.
That said, there have been a number of much worse bugs in openssh and other ssh implementations, mostly because they wrote them in C!
I've been using face="Verdana,Arial,Helvetica" size=-1 for a few years, and that seems to work right in the default install of all the computers I use. (My school's sun lab included.) Arial looks really bad in Mozilla on linux.
Also, do yourself a favor and use CSS. I use this, which also displays text at the right size on Macs (which like to make fonts smaller when browsing the web):
P { font: 11px Verdana,Arial,Helvetica }
I can't say much for what the "right way" to do this is without offending those folks who believe the web should not have any markup for design.
I agree with you, but I think better would be "hereditary" or "inherited." "Dominant" sounds bad and isn't really accurate, either (as others have pointed out).
It's fine that you did what you did, and for the most part I'm sure it works well for you. What I'm taking issue with is with calling this a "viable system for micropayments," which it isn't. It's just a series of flawed suggestions about configuring apache.
> The solution to payments is a lump sum of micropayments.
Well, I don't think that's true. What you describe in your page is essentially just metered subscriptions. Just because you divide out the subscription cost over many page views and the result is small doesn't make it "micropayments" -- micropayments require that the user be able to pay very small amounts (cents or less) to many *different* recipients.
> If you want to run through all the possibilities of RND in 7 letter > combinations be my guest. It's going to take a lot of tries to get > one right and the password will be changed long before you succeed. > And you'll be reported to your ISP.
I think you missed the point here... there are a lot fewer possibilities than you think when using Rnd to generate 7 letters in a row. Because VB's rnd uses a linear congruential generator (correct me if I'm wrong, but I'm pretty sure that's what it does), its output is quite predictable. At best, you have one password for each of the 32-bit seeds that timeGetTime can return (these can easily be brute-forced if someone got his hands on your unprotected htaccess file). At worst, since you use the time as a seed, the range of possible passwords is much much smaller -- if the attacker knows what day the password was generated, there are many, many fewer possibilities.
By the way, "ridiculous" is spelled with an 'i', like "ridicule." You made this error in your page, too.
> Does anyone know why interfaces have data members at all?
It's so that you can define constants (you know, MAX_SET_SIZE), because Java has no preprocessor. I'm not sure why constants in interfaces are so important, but my guess it is the language's answer to some whiny C/C++ programmer on the design team who couldn't express his favorite idiom without it.
Was this article written by a thirteen year-old? All this does is show you how to configure apache to make people type in usernames to browse your site, and then suggest that you charge the people who are using it. Well, the porn industry (and everyone else) has been doing this for years! The difficulty in setting up a micropayment scheme is not in configuring apache and writing visual basic scripts, but in making the payment mechanism convenient and non-intrusive. Also, there is a difficult social problem in convincing people to pay for web content. None of that is covered here, and that's what's needed in order to have a viable micropayment system.
Anyway, here are some obvious problems with what is there, even:
- Why change the name of the htaccess file? Apache by default makes sure that nobody can download a file called.htaccess. At least use those same controls to limit access to the crazily-named one.
- It's a really bad idea to use Visual Basic's deterministic Rnd function to generate passwords. (!)
- It's easy to use xcmd or bash or perl to make htpasswd read from a file, just like his program does.
- No programs around that analyze apache logs?? Holy crap, are you serious?? (http://www.google.com/search?hl=en&ie=UTF-8&oe=UT F-8&q=apache+log+analyzer)
OK, I'll take the bait, using the terminology from Applied Cryptography.
Let p = 4 and q = 9, as suggested.
Then, n = 36.
Choose e=65537 as the encryption key. (Common practice is to use a fixed e; (p-1)(q-1) and 65537 are relatively prime.)
Now we need d such that ed === 1 (mod (3*8)), so 65537*d === 1 mod 24. d = 17.
Now let's encrypt m = 6. c = 6^65537 mod 36 = 0 (!)
Now, let's decrypt.
t = 0^17 mod 36 = 0 (!)
The process will often fail in keygen as well (inability to find a decryption key, for instance), but encryption and decryption require that p and q are prime in order to work. Why would you say something like this? It's claims like yours that make slashdot a breeding ground of misinformation.
No, DeCSS was found to be a "circumvention device" because it's a program you can use to circumvent the access control. The judge found (if I recall correctly) that a description of the algorithm is NOT a device, so it's not illegal. Similarly, the private key itself would probably not be found to be a "circumvention device." So distributing the private key would not be illegal under the DMCA. (It might be illegal for other reasons, I don't know.)
If the numbers aren't prime then they won't work for RSA signing/encryption. Coming up with keys for RSA is pretty easy. (Common mistakes, as I understand, involve the randomness used to generate the keys not being very random!)
Why would it? The relevant section of the DMCA only bans the circumvention of mechanisms that control access to a copyrighted work. The private key itself isn't such a mechanism, as far as I know, though programs that use it probably would be. The DMCA is a bit vague, but it isn't so vague that it outlaws every possible kind of "hacking."
It's a good idea to read the DMCA (http://www4.law.cornell.edu/uscode/17/1201.html), because in fact Microsoft or someone probably would make DMCA threats against this kind of activity. In that case it's good to understand the law, because such a letter often sounds pretty convincing and scary!
The best thing about the DRM game is that all the involved parties are really serious, and draconian, about intellectual property. Everybody wants to own the technology, and I bet that will be its eventual downfall. (How many useless proprietary "secure audio" formats are there, now?)
Yes, and ISPs are the ones to do it.
on
ISP Chief on Spam
·
· Score: 2
The last people who should be complaining about this are the ISPs, for they are the ones who can actually cause new mail technologies to be commonly used.
I don't think micropayments are the right way; I think just having authentication would go a long way. (Authentication acts as a sort of "hash cash" itself, since cryptographic signing is not a cheap operation.) The technology has been here for ages; we just need a coalition of ISPs to actually roll it out.
Fortunately, the US Copyright Code (I can't say much for Holland) has exceptions to the exclusive rights of copyright holders ("Fair Use"). Fair use is not an implied permission given by the copyright holder, it's a limitation of the copyright holder's exclusive right. I don't think this is really a copyright issue, because harvesting e-mails (unless the original page was just a list of e-mail addresses) captures such a small fraction of the copyrighted content, is obviously transformative, and doesn't interfere with the copyright holder's ability to sell the original work. The only thing that is at issue here is the license that the crawler bots did not accept.
Let's put this in a different light: Slashdot users were up-in-arms when fatwallet recently received legal threats (Copyright) from retailers like Wal-mart for posting price details on their site.
Other than being something that annoys us rather than helps us, what's the difference?
I think there is a vast untapped market for "B2B portals." Basically, you create a World-Wide-Web page that businesses will want to use as their "start page" (sometimes called a "home page") on the Internet. This page connects together businesses with great links and technologies like XML! With the new top-level-domains, you can create an Internet name that's memorable and lasting. For instance, ULTIMATEB2BPORTAL.BIZ is available right now!!
The only thing is, portal sites usually need more than two people (usually 20 or 30) to run them. You guys had better get ready to work hard!
I don't think there's anything good about this. What if the next they rule it's illegal to to download an entire site for off-line browsing, or to crawl a web site to create an index of it? What if you were harvesting e-mails for a scientific study? This kind of regulation of technology is negative, and I'm thankful it didn't happen in the US. I guess the primary issue in this case was a "breach of contract" rather than something fundamental about e-mail address harvesting, but it's scary to see that kind of enthusiasm in a slashdot headline. (Who else cares about on-line freedoms?)
In this case I would have much rather seen e-mailgids just deploy technological solution to make it difficult for NTS to harvest e-mails. Seriously, as annoying as spam may be, it's not as annoying as losing my freedom on the internet. Be careful what you wish for!
Slashdot Mirror
Just to clarify: A language does not need to be context-free in order to be parsed by a recursive descent parser, because you can augment the recursive functions with extra arguments that provide, well, context. For instance:
::= x | let [dec] in [exp] end | n | print [exp]
::= val x = [exp]
[exp]
[dec]
(where x is the set of variables and n is the set of integer constants)
This language is context-free, but the following restriction isn't: We say that strings are only in this language if variables aren't used before being declared. Legal:
let
val x = 3
in
print x
end
Illegal:
let
val x = 3
in
print y
end
This language isn't context-free (in the usual sense) but can be parsed easily by a recursive function. That function simply takes with it a list of all the declared variables. (In fact, you can pull this same sort of hack with lex/yac by having the lexer make a call into your code, which keeps a symbol table of variables it has seen as it runs.)
(If I understand the problem with C and C++ correctly, the difficulty parsing has to do with recognizing a token as a type name or an identifier, so I think this is relevant.)
Great... that will make using C++ templates and stuff a bit nicer...
(Of course, SML and O'Caml (and related languages) have had much more sophisticated type inference for 30 years!)
I know. My response was supposed to be a haiku but the formatting got screwed up. ;)
There are about x / (ln x - 1) primes less than x, so there are about
1 94 13955752667049156071539032268561888456759092523852 26840859485002804929486395765683516004898436591870 67148076554529504792809085095276779696724529102225 25608461421302099522103073978587867378036538137453 88172275208148731803295108467519843612456324165778 22681833625323037116520381032399426754453484747128 98895442005502311885787951105899116301208615827545 04419427244140970531796034937268154702619069093754 03532933958584374295760895574495930343271125392053 18511525199482501616282311294457575661607859419759 65027029905582349776107150425077368604313940757969 37005679771832 .. primes less than 2^2048. That's a lot. Just for comparison, there are just 4294967296 memory addresses on a 32-bit computer.
22774493355398877590355797525489747681778789760
Read the truetype spec:
it's at microsoft.com
I've been told that the checksum isn't actually checked by windows -- apparently, my program updates it incorrectly (using an 8-bit sum instead of a 32-bit one) and doesn't update some other global header checksum. I haven't fixed the program in case I ever end up going to court over it (where it might matter that I haven't touched the page in 6 years), and because it works anyway...
> But isn't one of the "advantages" of Palladium that your friendly neighborhood viruses can no longer run and erase your
> MP3s/JPGs/etc, because they are not "trusted" code? I'm not sure how that will relate to unsigned VB scripts. It's designed
> to protect the consumer from themselves... and legislate what (Microsoft's, I assume) programmers could not implement
> properly.
No, Palladium won't help with that. Most viruses and trojans today are just memory resident processes like any other. There is no easy way to separate a "good" program from a "virus" program. (Seriously, how would it? And how would it be able to tell if a "good" program had an exploitable backdoor or buffer-overflow in it?) It's true that palladium might protect you against, say, boot sector viruses, but there are ways a properly implemented operating system can do this, too.
We already have all the hardware we need to provide computer security (namely, protected memory). Palladium's only purpose is removing the ability for users to inspect and modify their own computers (in an attempt to make DRM schemes fly), so don't listen to what they tell you!
Uh, then I think you understand. Palladium is designed essentially to prevent you from using debugging hardware or software to circumvent copy-control mechanisms. It is a key ingredient in the enslavement of the media consumer. What do you think it's for, and how do current OS techniques not address that?
I told AMI (link in the article: marketing@ami.com) that I don't think of this as a "feature". Computer manufacturers have backed down on much less invasive technologies (Pentium III's unique ID, for instance) before; I'm still a little bit hopeful that with all the competition in the mainboard scene we might be able to convince manufacturers not to adopt consumer-hostile technology like this.
I wouldn't say SSH1 is "easily cracked". All ettercap does is a man-in-the-middle attack, something which the default configuration of openssh, at least, provides a huge warning about.
That said, there have been a number of much worse bugs in openssh and other ssh implementations, mostly because they wrote them in C!
I've been using face="Verdana,Arial,Helvetica" size=-1 for a few years, and that seems to work right in the default install of all the computers I use. (My school's sun lab included.) Arial looks really bad in Mozilla on linux.
Also, do yourself a favor and use CSS. I use this, which also displays text at the right size on Macs (which like to make fonts smaller when browsing the web):
P { font: 11px Verdana,Arial,Helvetica }
I can't say much for what the "right way" to do this is without offending those folks who believe the web should not have any markup for design.
I agree with you, but I think better would be "hereditary" or "inherited." "Dominant" sounds bad and isn't really accurate, either (as others have pointed out).
It's fine that you did what you did, and for the most part I'm sure it works well for you. What I'm taking issue with is with calling this a "viable system for micropayments," which it isn't. It's just a series of flawed suggestions about configuring apache.
> The solution to payments is a lump sum of micropayments.
Well, I don't think that's true. What you describe in your page is essentially just metered subscriptions. Just because you divide out the subscription cost over many page views and the result is small doesn't make it "micropayments" -- micropayments require that the user be able to pay very small amounts (cents or less) to many *different* recipients.
> If you want to run through all the possibilities of RND in 7 letter
> combinations be my guest. It's going to take a lot of tries to get
> one right and the password will be changed long before you succeed.
> And you'll be reported to your ISP.
I think you missed the point here... there are a lot fewer possibilities than you think when using Rnd to generate 7 letters in a row. Because VB's rnd uses a linear congruential generator (correct me if I'm wrong, but I'm pretty sure that's what it does), its output is quite predictable. At best, you have one password for each of the 32-bit seeds that timeGetTime can return (these can easily be brute-forced if someone got his hands on your unprotected htaccess file). At worst, since you use the time as a seed, the range of possible passwords is much much smaller -- if the attacker knows what day the password was generated, there are many, many fewer possibilities.
By the way, "ridiculous" is spelled with an 'i', like "ridicule." You made this error in your page, too.
> Does anyone know why interfaces have data members at all?
It's so that you can define constants (you know, MAX_SET_SIZE), because Java has no preprocessor. I'm not sure why constants in interfaces are so important, but my guess it is the language's answer to some whiny C/C++ programmer on the design team who couldn't express his favorite idiom without it.
Was this article written by a thirteen year-old? All this does is show you how to configure apache to make people type in usernames to browse your site, and then suggest that you charge the people who are using it. Well, the porn industry (and everyone else) has been doing this for years! The difficulty in setting up a micropayment scheme is not in configuring apache and writing visual basic scripts, but in making the payment mechanism convenient and non-intrusive. Also, there is a difficult social problem in convincing people to pay for web content. None of that is covered here, and that's what's needed in order to have a viable micropayment system.
.htaccess. At least use those same controls to limit access to the crazily-named one.T F-8&q=apache+log+analyzer)
Anyway, here are some obvious problems with what is there, even:
- Why change the name of the htaccess file? Apache by default makes sure that nobody can download a file called
- It's a really bad idea to use Visual Basic's deterministic Rnd function to generate passwords. (!)
- It's easy to use xcmd or bash or perl to make htpasswd read from a file, just like his program does.
- No programs around that analyze apache logs?? Holy crap, are you serious?? (http://www.google.com/search?hl=en&ie=UTF-8&oe=U
OK, I'll take the bait, using the terminology from Applied Cryptography.
Let p = 4 and q = 9, as suggested.
Then, n = 36.
Choose e=65537 as the encryption key. (Common practice is to use a fixed e;
(p-1)(q-1) and 65537 are relatively prime.)
Now we need d such that ed === 1 (mod (3*8)),
so 65537*d === 1 mod 24.
d = 17.
Now let's encrypt m = 6.
c = 6^65537 mod 36 = 0 (!)
Now, let's decrypt.
t = 0^17 mod 36 = 0 (!)
The process will often fail in keygen as well (inability to find a decryption key, for instance), but encryption and decryption require that p and q are prime in order to work. Why would you say something like this? It's claims like yours that make slashdot a breeding ground of misinformation.
No, DeCSS was found to be a "circumvention device" because it's a program you can use to circumvent the access control. The judge found (if I recall correctly) that a description of the algorithm is NOT a device, so it's not illegal. Similarly, the private key itself would probably not be found to be a "circumvention device." So distributing the private key would not be illegal under the DMCA. (It might be illegal for other reasons, I don't know.)
If the numbers aren't prime then they won't work for RSA signing/encryption. Coming up with keys for RSA is pretty easy. (Common mistakes, as I understand, involve the randomness used to generate the keys not being very random!)
Why would it? The relevant section of the DMCA only bans the circumvention of mechanisms that control access to a copyrighted work. The private key itself isn't such a mechanism, as far as I know, though programs that use it probably would be. The DMCA is a bit vague, but it isn't so vague that it outlaws every possible kind of "hacking."
, because in fact Microsoft or someone probably would make DMCA threats against this kind of activity. In that case it's good to understand the law, because such a letter often sounds pretty convincing and scary!
It's a good idea to read the DMCA (http://www4.law.cornell.edu/uscode/17/1201.html)
The best thing about the DRM game is that all the involved parties are really serious, and draconian, about intellectual property. Everybody wants to own the technology, and I bet that will be its eventual downfall. (How many useless proprietary "secure audio" formats are there, now?)
The last people who should be complaining about this are the ISPs, for they are the ones who can actually cause new mail technologies to be commonly used.
I don't think micropayments are the right way; I think just having authentication would go a long way. (Authentication acts as a sort of "hash cash" itself, since cryptographic signing is not a cheap operation.) The technology has been here for ages; we just need a coalition of ISPs to actually roll it out.
Mail it to yourself, registered mail style.
While you're at it, mail yourself some empty unsealed envelopes, "just in case"...
Fortunately, the US Copyright Code (I can't say much for Holland) has exceptions to the exclusive rights of copyright holders ("Fair Use"). Fair use is not an implied permission given by the copyright holder, it's a limitation of the copyright holder's exclusive right. I don't think this is really a copyright issue, because harvesting e-mails (unless the original page was just a list of e-mail addresses) captures such a small fraction of the copyrighted content, is obviously transformative, and doesn't interfere with the copyright holder's ability to sell the original work. The only thing that is at issue here is the license that the crawler bots did not accept.
Let's put this in a different light: Slashdot users were up-in-arms when fatwallet recently received legal threats (Copyright) from retailers like Wal-mart for posting price details on their site.
Other than being something that annoys us rather than helps us, what's the difference?
I think there is a vast untapped market for "B2B portals." Basically, you create a World-Wide-Web page that businesses will want to use as their "start page" (sometimes called a "home page") on the Internet. This page connects together businesses with great links and technologies like XML! With the new top-level-domains, you can create an Internet name that's memorable and lasting. For instance, ULTIMATEB2BPORTAL.BIZ is available right now!!
The only thing is, portal sites usually need more than two people (usually 20 or 30) to run them. You guys had better get ready to work hard!
I don't think there's anything good about this. What if the next they rule it's illegal to to download an entire site for off-line browsing, or to crawl a web site to create an index of it? What if you were harvesting e-mails for a scientific study? This kind of regulation of technology is negative, and I'm thankful it didn't happen in the US. I guess the primary issue in this case was a "breach of contract" rather than something fundamental about e-mail address harvesting, but it's scary to see that kind of enthusiasm in a slashdot headline. (Who else cares about on-line freedoms?)
In this case I would have much rather seen e-mailgids just deploy technological solution to make it difficult for NTS to harvest e-mails. Seriously, as annoying as spam may be, it's not as annoying as losing my freedom on the internet. Be careful what you wish for!