I don't know why you were modded funny. The NRA is widely perceived in the gun rights community as far too willing to compromise.
I think that perception is largely wrong, too. It used to be that the NRA was eager to compromise, but they've toughened up quite a bit. Their stance these days is almost acceptable -- though they bear close watching to ensure they don't backslide.
Chances are what they really mean here is that they've compromised the certificate authorities that are trusted by default by most web browsers.
That would be noticed. Very quickly, actually. When DigiNotar was compromised and someone issued themselves some certs in various sites' names it was very quickly noticed that although the certs appeared valid, they weren't the same ones served up by the real site.
Turns out self signed certificates really are more secure.
Only if the attacker starts the MITM after you've already added the site's certificate to your browser. If the attacker is there from the beginning, you'll have no idea.
GPG and SSH are probably safe as you generate your own keys on the local machine.
They rely on different trust models, but aren't necessarily any harder to subvert. With the web of trust, an attacker has to compromise some key that you trust. That's hard when your web is on a small scale, but any attempts to scale it up beyond small circles of people makes it easy (e.g. you end up with keyservers, or widely-trusted signers -- the equivalent of CAs). With SSH you have basically the same situation as self-signed SSL certificates, unless you have some other mechanism for verifying the server key fingerprint. You just have to trust it the first time you see it, though you do have protection against attacks that begin later.
Heh... there's a thought: that the occasional HTTPS site you visit without a signed cert -- y'know, when your browser gives you a big, nasty security warning -- could actually be *more* secure.
No, it couldn't. MITM attacks are trivial with self-signed certs.
Theoretically, in practice average Joe buy their certificate and private keys from a third party.
Um, no, Joe average does not. Joe doesn't understand where his keys come from, but the CA doesn't provide them.
The public/private key pair is generated on Joe's computer. Most CA's issue certificates through a web-based form, and that form triggers the browser to generate the key pair locally. Then the public key is placed in a certificate request and uploaded to the CA. Some time later the CA signs the public key and produces the resulting public key certificate, which is downloaded.
The private key never leaves the user's computer until they move it somewhere else (e.g. to install it in their web server).
I don't actually know, but I don't think most symbols are indexed. There are a few, but I don't think the others are present in the index, so searching on them isn't possible. They could be indexed, certainly, but I'm sure plenty of testing has been done, and it works better for more people the way it is.
I was also amazed at the relevance of the hits, but I still missed AltaVistas "near"-operator. It allowed you to find only results where one term was close to another.
Google does support wildcard searches. You can search for "foo * bar" (the quotation marks are part of the search string) and you'll get pages that have "foo" followed by some stuff followed by "bar". In that order, so it's not exactly the same as "near", but pretty close. You can also use OR, so:
You don't, actually. That version of Google was way too susceptible to gaming, er, SEO.
It now ignores all kinds of information and meaningful symbols.
Have you tried verbatim mode? That doesn't help with searches that include less-common symbols, but it does help with a lot of searches. AFAIK, Google always stripped special characters from searches and from its index, though, so I think you may be remembering an engine that didn't actually exist.
and looking up related terms (you ask for "secured lending" and also get pages that say "mortgage") made a real difference.
Google does that now, but it didn't originally. It seemed like it did, though, because if there were a lot of pages with "secured lending" on them which all referred to one page about mortgages, giving it a high pagerank score, then that mortgage page was likely to be in the results.
How many people bother to react or even notice the weak sound coming from a horn?
In countries I've driven in where such use of the horn is widespread... everyone notices and reacts, because failure to do so will result in being in a collision, fairly quickly.
This is similar to my gripe about people who think that a horn is a useful safety device
A horn is a useful safety device, just not for the scenario you described. It's useful to alert others of your presence in situations where they might not notice you and where they do have time to react. I'll grant that horns aren't that useful in the US, but some other countries have driving styles which make them essential equipment, because everyone expects that if you're coming around a blind turn that you'll hit the horn to warn any oncoming traffic so that both of you can act appropriately -- and everyone expects that if no sound is heard that there is no oncoming traffic.
Avoiding foreign investment and involvement makes sense (in some situations, likely including this one). Ignoring a potential short-term revenue stream does not.
I don't have any links handy, but I've read a couple of articles about the book Schneier's working on and what research he's doing for it, and much of it is precisely in the area you mention. He didn't go into it in this blog post, but I think he likely has read the relevant literature. You'll probably have to read the book when it comes out to decide if you agree with his conclusions.
But why not take the money you can get now, while tooling up? In fact, use the cash you get from selling lithium to fund construction of battery manufacturing industry. There's no good reason to accept the risk of C, unless your lithium resources are so slight that you'll deplete them before you can start making batteries, but that's not the case.
No, Bolivia's just squandering its opportunities to no benefit.
A) Zero pennies now, for getting big profits in the future by controlling its own Lithium production.
B) Small profits now, letting the corporations get the lionshare forever.
Or maybe C) Zero pennies ever, if some other battery tech replaces Li-ion before they get spun up.
The smart move would be to sell lithium now for its raw material value while setting up battery production for the future. Don't leave money on the table now while preparing to step up the food chain.
As far as I can tell there isn't any other way to do it. If Javascript needs access to that encryption key then of course it is possible to send that key anywhere else.
At present, this is true. There's a W3C WebCrypto spec in progress (being developed by Google and Mozilla, IIRC) that will change it, though. It will not only provide native implementations of ciphers accessible from Javascript (rather than performing expensive calculations in Javascript), but will also provide a client-side key store so Javascript code can create and use keys without ever seeing their value, and hence be unable to send the values anywhere.
I think the Javascript code would still have access to the decrypted data.
Caveat: It's been a while since I looked at the in-progress spec. It may have changed, and I guarantee my memory is faulty in at least some respect.
Most likely this is crap, just political gamesmanship, but the sad thing is that US actions and policies have given the country such a shady reputation that everyone has to at least give it a good look.
Another interesting side to the "tech as magic" notion is the work of authors who define rigorous frameworks for their fictional magic. Then magic becomes technology, just technology that's based on different (and fictional) physical principles. Much of golden age sci-fi was about exploring the impact of logical extensions of technology on social structures. Today there's a lot of fantasy that postulates interesting magic and explores its impact on social structures.
Of course, at the end of the day all good stories are about people. I love good stories that use really innovative and mind-twisting technology/magic as a backdrop, but while great ideas add spice great storytelling is about emotional reaction, and that means people.
If the pattern file has N lines and the e-mail has M lines, and if we count comparing one line of the pattern file against one line of the e-mail as one operation, then for each of the N lines of the file, we have to do M comparisons.
There are better algorithms than this obvious one, though, and it would surprise me if egrep didn't use one of them when given the whole list of patterns at once.
Because the ocean isn't perfectly even. Tidal forces, wind and waves, currents, plate activity, volcanoes, it's constantly flowing every which way. I'd be surprised if the sea level rose exactly the same amount in Oahu and Cardiff.
Strictly speaking, if the ocean is constantly moving then you can't actually measure if it's rising or falling. Because it would need to stop moving to measure it.
Sqlite, or anything that uses an index, will be screaming fast.
Your statement of your current solution makes me wonder, though.. are you using "egrep -F -f pattern_file e_mail_message"? Or are you running egrep many times, once per line of the pattern file, or once per line of the message? I would think that given a pattern file egrep would be smart enough to do something better than repeatedly scanning the input, but based on the time it's taking, it sounds like that's happening.
Slashdot Mirror
I don't know why you were modded funny. The NRA is widely perceived in the gun rights community as far too willing to compromise.
I think that perception is largely wrong, too. It used to be that the NRA was eager to compromise, but they've toughened up quite a bit. Their stance these days is almost acceptable -- though they bear close watching to ensure they don't backslide.
Chances are what they really mean here is that they've compromised the certificate authorities that are trusted by default by most web browsers.
That would be noticed. Very quickly, actually. When DigiNotar was compromised and someone issued themselves some certs in various sites' names it was very quickly noticed that although the certs appeared valid, they weren't the same ones served up by the real site.
Turns out self signed certificates really are more secure.
Only if the attacker starts the MITM after you've already added the site's certificate to your browser. If the attacker is there from the beginning, you'll have no idea.
GPG and SSH are probably safe as you generate your own keys on the local machine.
They rely on different trust models, but aren't necessarily any harder to subvert. With the web of trust, an attacker has to compromise some key that you trust. That's hard when your web is on a small scale, but any attempts to scale it up beyond small circles of people makes it easy (e.g. you end up with keyservers, or widely-trusted signers -- the equivalent of CAs). With SSH you have basically the same situation as self-signed SSL certificates, unless you have some other mechanism for verifying the server key fingerprint. You just have to trust it the first time you see it, though you do have protection against attacks that begin later.
Heh ... there's a thought: that the occasional HTTPS site you visit without a signed cert -- y'know, when your browser gives you a big, nasty security warning -- could actually be *more* secure.
No, it couldn't. MITM attacks are trivial with self-signed certs.
Certificate authorities never see private keys
Theoretically, in practice average Joe buy their certificate and private keys from a third party.
Um, no, Joe average does not. Joe doesn't understand where his keys come from, but the CA doesn't provide them.
The public/private key pair is generated on Joe's computer. Most CA's issue certificates through a web-based form, and that form triggers the browser to generate the key pair locally. Then the public key is placed in a certificate request and uploaded to the CA. Some time later the CA signs the public key and produces the resulting public key certificate, which is downloaded.
The private key never leaves the user's computer until they move it somewhere else (e.g. to install it in their web server).
I don't actually know, but I don't think most symbols are indexed. There are a few, but I don't think the others are present in the index, so searching on them isn't possible. They could be indexed, certainly, but I'm sure plenty of testing has been done, and it works better for more people the way it is.
I was also amazed at the relevance of the hits, but I still missed AltaVistas "near"-operator. It allowed you to find only results where one term was close to another.
Google does support wildcard searches. You can search for "foo * bar" (the quotation marks are part of the search string) and you'll get pages that have "foo" followed by some stuff followed by "bar". In that order, so it's not exactly the same as "near", but pretty close. You can also use OR, so:
"foo * bar" OR "bar * foo"
is pretty close to "foo near bar".
https://support.google.com/websearch/answer/136861?hl=en&ref_topic=3081620
I wish I could use the Google I first found.
You don't, actually. That version of Google was way too susceptible to gaming, er, SEO.
It now ignores all kinds of information and meaningful symbols.
Have you tried verbatim mode? That doesn't help with searches that include less-common symbols, but it does help with a lot of searches. AFAIK, Google always stripped special characters from searches and from its index, though, so I think you may be remembering an engine that didn't actually exist.
and looking up related terms (you ask for "secured lending" and also get pages that say "mortgage") made a real difference.
Google does that now, but it didn't originally. It seemed like it did, though, because if there were a lot of pages with "secured lending" on them which all referred to one page about mortgages, giving it a high pagerank score, then that mortgage page was likely to be in the results.
Brin and Page were the ones who made a profitable search engine.
Yahoo, Lycos, even Altavista (in its way) were all profitable search engines before Google.
Brin and Page just created a search engine that was an order of magnitude better than its competitors.
How many people bother to react or even notice the weak sound coming from a horn?
In countries I've driven in where such use of the horn is widespread... everyone notices and reacts, because failure to do so will result in being in a collision, fairly quickly.
This is similar to my gripe about people who think that a horn is a useful safety device
A horn is a useful safety device, just not for the scenario you described. It's useful to alert others of your presence in situations where they might not notice you and where they do have time to react. I'll grant that horns aren't that useful in the US, but some other countries have driving styles which make them essential equipment, because everyone expects that if you're coming around a blind turn that you'll hit the horn to warn any oncoming traffic so that both of you can act appropriately -- and everyone expects that if no sound is heard that there is no oncoming traffic.
Avoiding foreign investment and involvement makes sense (in some situations, likely including this one). Ignoring a potential short-term revenue stream does not.
I don't have any links handy, but I've read a couple of articles about the book Schneier's working on and what research he's doing for it, and much of it is precisely in the area you mention. He didn't go into it in this blog post, but I think he likely has read the relevant literature. You'll probably have to read the book when it comes out to decide if you agree with his conclusions.
I don't see how selling lithium to foreign corporations gives them "control".
But why not take the money you can get now, while tooling up? In fact, use the cash you get from selling lithium to fund construction of battery manufacturing industry. There's no good reason to accept the risk of C, unless your lithium resources are so slight that you'll deplete them before you can start making batteries, but that's not the case.
No, Bolivia's just squandering its opportunities to no benefit.
A) Zero pennies now, for getting big profits in the future by controlling its own Lithium production.
B) Small profits now, letting the corporations get the lionshare forever.
Or maybe C) Zero pennies ever, if some other battery tech replaces Li-ion before they get spun up.
The smart move would be to sell lithium now for its raw material value while setting up battery production for the future. Don't leave money on the table now while preparing to step up the food chain.
As far as I can tell there isn't any other way to do it. If Javascript needs access to that encryption key then of course it is possible to send that key anywhere else.
At present, this is true. There's a W3C WebCrypto spec in progress (being developed by Google and Mozilla, IIRC) that will change it, though. It will not only provide native implementations of ciphers accessible from Javascript (rather than performing expensive calculations in Javascript), but will also provide a client-side key store so Javascript code can create and use keys without ever seeing their value, and hence be unable to send the values anywhere.
I think the Javascript code would still have access to the decrypted data.
Caveat: It's been a while since I looked at the in-progress spec. It may have changed, and I guarantee my memory is faulty in at least some respect.
Most likely this is crap, just political gamesmanship, but the sad thing is that US actions and policies have given the country such a shady reputation that everyone has to at least give it a good look.
Another interesting side to the "tech as magic" notion is the work of authors who define rigorous frameworks for their fictional magic. Then magic becomes technology, just technology that's based on different (and fictional) physical principles. Much of golden age sci-fi was about exploring the impact of logical extensions of technology on social structures. Today there's a lot of fantasy that postulates interesting magic and explores its impact on social structures.
Of course, at the end of the day all good stories are about people. I love good stories that use really innovative and mind-twisting technology/magic as a backdrop, but while great ideas add spice great storytelling is about emotional reaction, and that means people.
O(L(1+N+NM)) = O(NM)
If he's using egrep -F, the patterns are fixed strings.
O(NM).
If the pattern file has N lines and the e-mail has M lines, and if we count comparing one line of the pattern file against one line of the e-mail as one operation, then for each of the N lines of the file, we have to do M comparisons.
There are better algorithms than this obvious one, though, and it would surprise me if egrep didn't use one of them when given the whole list of patterns at once.
Because the ocean isn't perfectly even. Tidal forces, wind and waves, currents, plate activity, volcanoes, it's constantly flowing every which way. I'd be surprised if the sea level rose exactly the same amount in Oahu and Cardiff.
Strictly speaking, if the ocean is constantly moving then you can't actually measure if it's rising or falling. Because it would need to stop moving to measure it.
Dude. Math. Learn some.
(In particular, very, very basic statistics)
Sqlite, or anything that uses an index, will be screaming fast.
Your statement of your current solution makes me wonder, though.. are you using "egrep -F -f pattern_file e_mail_message"? Or are you running egrep many times, once per line of the pattern file, or once per line of the message? I would think that given a pattern file egrep would be smart enough to do something better than repeatedly scanning the input, but based on the time it's taking, it sounds like that's happening.
And the ideas existed before MAC as well. This sort of stuff used to be standard for operating systems.
Good point. Mainframes had in-depth security architectures long ago. I'm not very familiar with how they worked, though.