They didn't say it is terrorism, they said they would use the same tools as for terrorism. That is, they know it's not terrorism, but think that the same tools would be useful.
The light saber fights in the first 3 (eps 4,5,6) were clunky and slow and looked planned. It looks like they rehearsed once and then filmed.
Whereas the last 3 (eps 1,2,3) were wonderfully choreographed - they looked real - the choreographed "mistakes" looked great. The last 3 actually looked like the actors spent many many hours practicing (they did) and it showed.
The first part of the Trilogy did the saber fighting much better than the second part of the Trilogy (eps: 4,5,6)
As a former fencer, I completely agree on the fight quality. During the lightsaber battles in the original three movies, the actors' movements were relatively slow and often didn't actually threaten their opponents. They're somewhat painful to watch: I keep thinking "stop thrust, stop thrust!" The actors in the newer trilogies look like they're mostly actually trying to fight each other. Although even in the new series, there still are plenty of moments when someone leaves themselves open to do something showy (i.e. swing their saber backwards) and their opponent doesn't press the advantage.
That said, in terms of fight choreography, what looks good isn't always what's most realistic.
If the tower of Babel story equates to a Babylonian tower, it would seem that suggests that the book of Genesis, which presents itself as having been written thousands of years before Babylon, actually dates to the era of Babylon (or perhaps parts of Genesis actually are older, but someone 'inserted' the Tower of Babel story much later)?
The stele is about the reconstruction of the tower, not its initial construction. The original construction of the tower/ziggurat would have been considerably earlier.
Genesis is the first of the five books of Moses. It was legendarily attributed to Moses. That would make the legendary time of its writing less than a thousand years before the writing of the stele, when Babylon did already exist. [Of course, if you agree with modern scholarship, then Genesis was written/collated considerably after the time of Moses.]
There is also no linguistic connection between the tower of "balal" (Hebrew) and the ziggaurat of "babili" (Akkadian).
The Hebrew is not "balal", it's BBL (two "bet" characters followed by a "lamed".) Hebrew is normally written without most vowels, and ancient Hebrew was always written without most vowels; the "nikud" dot systems used to teach Hebrew vowels are no more than 1500 years old. I don't know where you got your Akkadian transliteration from. If your Akkadian is as bad as your Hebrew, it's worthless. But if your Akkadian source was better than your Hebrew source, then it's interesting that Hebrew BBL is quite close to "babili". If you were going to write "babili" in Hebrew, it would look either like "BBL" or BBLY" (the Hebrew yud character can double as a vowel.)
And the linguistics are irrelevant, anyway. Hebrew BBL has long been considered a reference to Babylon. Even if the Hebrew and Akkadian place names were linguistically disparate, BBL would still have been an exonym referencing Babylon. Sort of like Japan vs. Nippon. A modern English article that describes a site in Japan is not incorrect or mythical just because the local name is "Nippon"/"Nihon" rather than "Japan". "BBL means "Babylon" just as "Japan" means "Nippon".
[Disclaimer: I personally don't believe in the Bible. However, that doesn't change the fact that it is an interesting collection of ancient documents that reference other antiquities.]
The summary reads like an angry teenager implying that they could do better.
The Russians had a reputation for rocket reliability. They previously marketed based on that reputation, releasing press releases after successful launches trumpeting how much more reliable they were. They are now rapidly losing that reputation. This will impact their competitiveness in the launch market.
but at least they are trying in the face of failure, instead of giving up and whining about for a decade like the US did after the shuttle disasters.
This is robotic spacecraft, not manned space. The US has not even paused in launching robotic spacecraft -- we did plenty of launches this year, and we have plenty more scheduled. And I would disagree on manned as well. The US didn't give up manned launches: we kept flying the shuttle until earlier this year, and we're on track to resume manned launches in a few years. US manned launches are paused, not stopped.
usually when an American rocket "fails" it tends to explode horribly but I guess that is the down side of using two huge solid boosters on your rockets.
"Usually"? The recent US rocket failures have not been explosions, either. For example, the failure with Glory was a fairing separation problem.
If I dislike (or like) all candidates in an election equally, not voting is a (even the) proper choice.
Most elections have a bunch of offices and decisions, each with a bunch of candidates/options. How is it possible that you are consistently seeing equivalence between the various sets of candidates and options? I could understand if, in some small fraction of individual line items, your research turned up that the options were equally bad. But how can you not be voting at all?
Far more likely: you aren't doing adequate research. The options seem equivalent to you because, with minimal information about the candidates, you are unable to substantively differentiate between them. So get off your butt and do your homework.
0-day refers to the time when the bug is first exploited relative to when it is patched by the vendor. It has nothing to do with whether or not the exploit yield unauthorized access. It is entirely possible to have a 0-day DoS attack.
There was no evidence on whether or not the bug was triggered deliberately. Hence why the summary referred to it as a "potential" 0-day, and said the problem "is believed to be" a 0-day vulnerability.
At the time crashes were initially occuring, no patch existed. That made it a 0-day, assuming
SANS is a well-known security organization. Hopefully folks who care about this sort of thing are aware that isc.sans.edu is not the same entity as isc.org.
This is a "news for nerds" site. Plenty of folks aren't running BIND 9 directly from isc.org at their workplaces. Perhaps they are using distribution-bundled BIND, or they're running BIND 9 at home, or they're not running BIND 9 at all and are just curious about major vulnerabilities. I know I like to read about flaws in major Internet software even for packages I'm not running.
The intent is not "in open source, the burden is on users to fix issues." Rather, the intent is "in open source, frustrated users have a potential recourse other than relying on the developers."
Unfortunately, the usual phrasing does not make this clear.
In the closed source world, it's perfectly normal when filing a bug report to get back a polite "we acknowledge that issue, but it isn't affecting much of the user community. In the interest of prioritizing our scarce development resources, we will not be addressing that issue on our current roadmap, unless it impacts a significantly larger fraction of our paying customer base."
In the open source world, I think the intent of "use the source, Luke" is to be shorthand for something similar:
"We acknowledge that issue, but it has not been reported by much of our user community. In the interest of prioritizing our scarce development resources, we will not be addressing that issue on our current roadmap, unless it impacts a significantly larger fraction of our user base. Please continue to report other bugs; all bug reports are valuable feedback, and we do fix many user-reported bugs based on our triage and prioritization processes. Note that, if this bug is sufficiently problematic for you, and you have the necessary skills and resources, you have the source! So you are welcome to fix this for yourself, should you be so inclined."
Unfortunately, frazzled developers are far more likely to give a curt response rather than spending the time to write up something more polite. FWIW, I'd be happy for anyone who wishes to use the wording I just used.
Again FWIW, my own experience is that both closed source and open source developers vary widely in their support level. As a for-instance, I found a problem with a certain closed-source device vendor's product not being RFC compliant, and therefore failing to properly inter-operate with an open-source management program. A coworker contacted the vendor as a (paying) customer, while I contacted the mailing list for the open-source software. The author of the open-source software emailed me a workaround within hours. My coworker is still waiting for a useful response from the vendor.
Conversely, we had several interoperability problems between a different vendor and a different open-source program. The vendor actually had already made a patch for one of the issues, but we couldn't deploy it. The maintainer of the open-source program refused to workaround one of the issues on their end, because the vendor had patched it, and we should just install the patch. While I didn't like the situation, this was a major problem for us, so I was motivated to hit the source. Because I had source, I was able to write my own patch.
This reminds me that computing is unique in that a fair number of the pioneers are alive, or were until very recently. My list of major computer names is a lot longer: Alan Turing, Von Neumann, Claude Shannon, Doug Engelbart, Vint Cert, Bob Metcalfe, Ken Olsen, Steve Jobs, Steve Wozniak, Bill Gates, Bill Joy, Linus Torvalds, Larry Wall, Guido van Rossum, James Gosling, Grace Hopper, Ken Thompson, Dennis Ritchie, Tim Berners-Lee, John McCarthy. Of those names, quite a few are still alive right now. It's actually possible to travel around and meet them. This is a feature of computing that differentiates it from many other fields. In Math, Physics, Biology, etc., most of your heroes died hundreds of years ago.
If however, this is just a bunch of poorly trained "enthusiasts" claiming to be crytpozoologists, but lacking any measure of proper scientific method, then this expidition is a colossal waste, and I hope they get frostbite of the penis for wasting resources and time.
Even if they're just enthusiasts, they don't necessarily need to follow the scientific method to produce value. They can prove their claims conclusively by capturing one live specimen and bringing it back to civilization.
I agree with most of what you wrote, but please note that most of the Dead Sea Scrolls are in Hebrew rather than Aramaic. Also please note that ancient Hebrew is surprisingly readable to people who can read "modern" Hebrew. For the last 2000 or so years, Hebrew has mostly been a dead language used only for ritual and study, so it hasn't changed all that much. I haven't personally seen any of the Aramaic parts of the Dead Sea Scrolls, but I wouldn't be surprised if they were relatively easy to read as well.
About 18 years ago, I stood in the Shrine of the Book in Jerusalem and read from the Dead Sea Scroll copy of Isaiah. I'm no longer a religious individual, but it's still awe inspiring to be able to piece together the familiar words from the ancient, unfamiliar lettering. Now it can be done anywhere, for free, rather than requiring a 15 hour flight.
Because releasing damaging information about current religious denominations is dangerous not only to the releasers but also to the psyche of their followers.
Israeli Jewish culture is mostly secular -- about 80% of Israeli Jews. There is a lot of conflict between the secularists and the 20% or so of the religious minority. The academics are usually from the secular side. If the concern were about upsetting religious folks, the secularist majority would not have had a problem with releasing the material.
A lot of folks think that the delay for currently unpublished scrolls is academics wanting to be the first to be able to publish papers based on the material. I'm in this camp. Greed makes a lot more sense to me than a vast conspiracy.
It's not about what the people make, it's about what the people cost. Remember that when the government hires a contractor, there is usually a contracting company. The company gets a lot more money per employee than the employee sees. Some of that is fair per-employee costs such as payroll taxes and employer-funded health care. Some of that is overhead -- the company's HR, payroll, accounting, contract offices, and profits come out of charging more per-employee.
Any new SSL cert validation scheme needs to interoperate with the CA-based SSL cert validation scheme. The existing SSL cert validation scheme does have cert expiration, needed or not. Your bank is not going to switch to a self-signed perpetual cert when the overwhelming majority of its customers are relying on CA-based schemes that will claim the bank's site is unsafe. So certs are going to keep changing. For a new cert validation scheme to succeed, it must be able to accommodate this during the transition.
Meanwhile, DNSSEC-based cert validation can interoperate with the current CA system without an interoperability problem during transition. And when the transition is over, you no longer need to pay a CA.
And I would argue that certs -- or more correctly, private keys -- should periodically expire. People occasionally change jobs. Backup media get misplaced. As keys age, they are more likely to have been compromised, or to be based on unacceptable legacy algorithms or key lengths. Changing encryption keys periodically is a general best practice in the IT industry. The lack of a built-in key aging and key distribution method in ssh is, IMHO, its biggest weakness.
. . . and I appear to have misunderstood Moxie's system. It does not implicitly trust DNS at all. It does rely on SSL certs not to change, which I find odd, given that SSL certs tend to be replaced (either shortly before expiration or after a private key compromise.)
Both the current CA model and Moxie Marlinspike's proposed notary system already implicitly trust DNS registration data. When someone requests example.com, how does the CA (or notary) know that the requestor owns it? In a few rare cases, the CA (or notary) knows the requestor personnally, but that's rare, and doesn't scale to the Internet. In the normal case, the CA (or notary) has no information other than DNS. The CA (or notary) will either check that the requestor's contact data matches the DNS whois data (implicitly trusting the current DNS/whois data) or will instruct the requestor to post a file to their site (implicitly trusting the current DNS records.)
In either case, DNS is trusted implicitly.
Subtlety: note that this is not saying that DNS data is trustworthy. DNS data is definitely not trustworthy. Rather, it's saying that any entity looking to validate a DNS domain needs to rely on DNS data, so there cannot be any entity more trustworthy than DNS.
As an example, suppose a site's DNS registrar was Joe the used car salesman. You don't trust Joe. Your buddy happens to be both the Pope and a Moxie-style notary, so you figure you'll get the Pope to check out the site's SSL. What is the Pope going to do? The Pope doesn't know the site personally. The only information available about the site is in the DNS registry database. So the Pope is going to check the site's DNS database entry -- written by Joe the used car salesman -- contact the site, verify that they do indeed match what Joe wrote in whois, and issue a signature. You now have the Pope's guarantee that the site matches what Joe said it matches. The trouble is that the Pope is just saying "yes, it matches what Joe said" -- you have gotten no more of a guarantee than if you just gotten Joe to tell you that to begin with.
That's why DNSSEC, if it actually could be deployed, would be the best system for traditional SSL certs. Traditional SSL certs are statements about DNS data. There cannot be anyone more authoritative on what the DNS contains than the registrars that generate that data.
Of course, EV certs are another story, in that they make a statement about something different than just the domain name. However, that's another story.
The correct solution to all this is to move certs to DNSSEC or some other DNS-based approach. If you combine several facts about SSL, it should be obvious why a DNS solution is correct:
(1) SSL is about tying certificates to hostnames. Your browser (or other SSL client) connects to an SSL server at some hostname H. The server responds with public key X. The job of SSL's authentication component is to verify that public key X is really owned by hostname H.
(2) The only information anyone has about who owns which hostname is the information associated with DNS records and related whois registry.
So TFA's concerns about not trusting DNS registrars, and wanting trusted notaries misses the point. Even if your DNS registrar is Joe the Used Car Salesman, and your notary is the Pope, how does the notary know who the server really is? Why, the notary has to look into the databases provided by the registrar! So if any notary has to rely on the registrars' data, how can the notary ever be more trusted than the underlying registrars? Any process more complex than somehow relying on the DNS registrar is security theatre. The DNS registrar creates your DNS identity, so is in the best position to authenticate it.
Put differently, if an untrusted entity can mess with DNS registration data, that same entity is in a position to convince any notary of their DNS identity. No process, no matter how convoluted, can fix this.
Doom 1 contained three "episodes", with the first episode released as the shareware version. Doom 1 episode 1 was on Phobos, episode 2 was on Deimos, and episode 3 was on Mars itself.
Neil's Armstrong's autograph is worth more than Buzz Aldrin's autograph. Two reasons: Armstrong is much more reclusive (i.e. he stopped signing in the 1990s, so there is less supply), and Armstrong stepped on the moon first (so he is more of a celebrity, and there is more demand.)
NASA only has so much funding to go around. Shuttle operations are expensive -- each launch costs hundreds of millions of dollars. Development of manned spacecraft is also expensive. So the theory was that NASA would discontinue shuttle, freeing up lots of funding to build shuttle's replacement, and after a few years, we would have a replacement, without need to temporarily increase NASA's budget. In different terms, the gap between shuttle and its replacement was very much a feature. This is the same way that the transition from Apollo to Shuttle was funded, to include the same sort of gap between Apollo-Soyuz and STS-1.
Slashdot Mirror
They didn't say it is terrorism, they said they would use the same tools as for terrorism. That is, they know it's not terrorism, but think that the same tools would be useful.
The light saber fights in the first 3 (eps 4,5,6) were clunky and slow and looked planned. It looks like they rehearsed once and then filmed.
Whereas the last 3 (eps 1,2,3) were wonderfully choreographed - they looked real - the choreographed "mistakes" looked great. The last 3 actually looked like the actors spent many many hours practicing (they did) and it showed.
The first part of the Trilogy did the saber fighting much better than the second part of the Trilogy (eps: 4,5,6)
As a former fencer, I completely agree on the fight quality. During the lightsaber battles in the original three movies, the actors' movements were relatively slow and often didn't actually threaten their opponents. They're somewhat painful to watch: I keep thinking "stop thrust, stop thrust!" The actors in the newer trilogies look like they're mostly actually trying to fight each other. Although even in the new series, there still are plenty of moments when someone leaves themselves open to do something showy (i.e. swing their saber backwards) and their opponent doesn't press the advantage.
That said, in terms of fight choreography, what looks good isn't always what's most realistic.
You see, from the very beginning ducks have ruled the world.
Yes, a lot of folks just read the first part of the comment and the conclusion. But some people do read the entire comment before replying.
"If the tower of Babel story equates to a Babylonian tower,"
it doesn't, but every at the peak of 'stupid mountain' thinks it is.
What is so preposterous about one Middle Eastern culture referencing another culture's actual uncompleted building in their legends?
If the tower of Babel story equates to a Babylonian tower, it would seem that suggests that the book of Genesis, which presents itself as having been written thousands of years before Babylon, actually dates to the era of Babylon (or perhaps parts of Genesis actually are older, but someone 'inserted' the Tower of Babel story much later)?
The stele is about the reconstruction of the tower, not its initial construction. The original construction of the tower/ziggurat would have been considerably earlier.
Genesis is the first of the five books of Moses. It was legendarily attributed to Moses. That would make the legendary time of its writing less than a thousand years before the writing of the stele, when Babylon did already exist. [Of course, if you agree with modern scholarship, then Genesis was written/collated considerably after the time of Moses.]
There is also no linguistic connection between the tower of "balal" (Hebrew) and the ziggaurat of "babili" (Akkadian).
The Hebrew is not "balal", it's BBL (two "bet" characters followed by a "lamed".) Hebrew is normally written without most vowels, and ancient Hebrew was always written without most vowels; the "nikud" dot systems used to teach Hebrew vowels are no more than 1500 years old. I don't know where you got your Akkadian transliteration from. If your Akkadian is as bad as your Hebrew, it's worthless. But if your Akkadian source was better than your Hebrew source, then it's interesting that Hebrew BBL is quite close to "babili". If you were going to write "babili" in Hebrew, it would look either like "BBL" or BBLY" (the Hebrew yud character can double as a vowel.)
And the linguistics are irrelevant, anyway. Hebrew BBL has long been considered a reference to Babylon. Even if the Hebrew and Akkadian place names were linguistically disparate, BBL would still have been an exonym referencing Babylon. Sort of like Japan vs. Nippon. A modern English article that describes a site in Japan is not incorrect or mythical just because the local name is "Nippon"/"Nihon" rather than "Japan". "BBL means "Babylon" just as "Japan" means "Nippon".
[Disclaimer: I personally don't believe in the Bible. However, that doesn't change the fact that it is an interesting collection of ancient documents that reference other antiquities.]
The summary reads like an angry teenager implying that they could do better.
The Russians had a reputation for rocket reliability. They previously marketed based on that reputation, releasing press releases after successful launches trumpeting how much more reliable they were. They are now rapidly losing that reputation. This will impact their competitiveness in the launch market.
And it isn't just US media saying it. After the Phobos-Grunt launch failure, Medvedev threatened to punish those responsible.
but at least they are trying in the face of failure, instead of giving up and whining about for a decade like the US did after the shuttle disasters.
This is robotic spacecraft, not manned space. The US has not even paused in launching robotic spacecraft -- we did plenty of launches this year, and we have plenty more scheduled. And I would disagree on manned as well. The US didn't give up manned launches: we kept flying the shuttle until earlier this year, and we're on track to resume manned launches in a few years. US manned launches are paused, not stopped.
usually when an American rocket "fails" it tends to explode horribly but I guess that is the down side of using two huge solid boosters on your rockets.
"Usually"? The recent US rocket failures have not been explosions, either. For example, the failure with Glory was a fairing separation problem.
If I dislike (or like) all candidates in an election equally, not voting is a (even the) proper choice.
Most elections have a bunch of offices and decisions, each with a bunch of candidates/options. How is it possible that you are consistently seeing equivalence between the various sets of candidates and options? I could understand if, in some small fraction of individual line items, your research turned up that the options were equally bad. But how can you not be voting at all?
Far more likely: you aren't doing adequate research. The options seem equivalent to you because, with minimal information about the candidates, you are unable to substantively differentiate between them. So get off your butt and do your homework.
Submitter here. Comments:
0-day refers to the time when the bug is first exploited relative to when it is patched by the vendor. It has nothing to do with whether or not the exploit yield unauthorized access. It is entirely possible to have a 0-day DoS attack.
There was no evidence on whether or not the bug was triggered deliberately. Hence why the summary referred to it as a "potential" 0-day, and said the problem "is believed to be" a 0-day vulnerability.
At the time crashes were initially occuring, no patch existed. That made it a 0-day, assuming
SANS is a well-known security organization. Hopefully folks who care about this sort of thing are aware that isc.sans.edu is not the same entity as isc.org.
This is a "news for nerds" site. Plenty of folks aren't running BIND 9 directly from isc.org at their workplaces. Perhaps they are using distribution-bundled BIND, or they're running BIND 9 at home, or they're not running BIND 9 at all and are just curious about major vulnerabilities. I know I like to read about flaws in major Internet software even for packages I'm not running.
China's certainly moving at a brisk pace.
NASA:
First manned flight: 1962
First orbital rendevouz: 1965
First orbital docking: 1966
Last manned flight 2011
Most recent manned flight: 2011
Next planned manned flight: 2014
SpaceX says they'll be ready to launch people to LEO in 2014. So far they've hit their schedule targets.
The intent is not "in open source, the burden is on users to fix issues." Rather, the intent is "in open source, frustrated users have a potential recourse other than relying on the developers."
Unfortunately, the usual phrasing does not make this clear.
In the closed source world, it's perfectly normal when filing a bug report to get back a polite "we acknowledge that issue, but it isn't affecting much of the user community. In the interest of prioritizing our scarce development resources, we will not be addressing that issue on our current roadmap, unless it impacts a significantly larger fraction of our paying customer base."
In the open source world, I think the intent of "use the source, Luke" is to be shorthand for something similar:
"We acknowledge that issue, but it has not been reported by much of our user community. In the interest of prioritizing our scarce development resources, we will not be addressing that issue on our current roadmap, unless it impacts a significantly larger fraction of our user base. Please continue to report other bugs; all bug reports are valuable feedback, and we do fix many user-reported bugs based on our triage and prioritization processes. Note that, if this bug is sufficiently problematic for you, and you have the necessary skills and resources, you have the source! So you are welcome to fix this for yourself, should you be so inclined."
Unfortunately, frazzled developers are far more likely to give a curt response rather than spending the time to write up something more polite. FWIW, I'd be happy for anyone who wishes to use the wording I just used.
Again FWIW, my own experience is that both closed source and open source developers vary widely in their support level. As a for-instance, I found a problem with a certain closed-source device vendor's product not being RFC compliant, and therefore failing to properly inter-operate with an open-source management program. A coworker contacted the vendor as a (paying) customer, while I contacted the mailing list for the open-source software. The author of the open-source software emailed me a workaround within hours. My coworker is still waiting for a useful response from the vendor.
Conversely, we had several interoperability problems between a different vendor and a different open-source program. The vendor actually had already made a patch for one of the issues, but we couldn't deploy it. The maintainer of the open-source program refused to workaround one of the issues on their end, because the vendor had patched it, and we should just install the patch. While I didn't like the situation, this was a major problem for us, so I was motivated to hit the source. Because I had source, I was able to write my own patch.
Obviously, YMMV.
This reminds me that computing is unique in that a fair number of the pioneers are alive, or were until very recently. My list of major computer names is a lot longer: Alan Turing, Von Neumann, Claude Shannon, Doug Engelbart, Vint Cert, Bob Metcalfe, Ken Olsen, Steve Jobs, Steve Wozniak, Bill Gates, Bill Joy, Linus Torvalds, Larry Wall, Guido van Rossum, James Gosling, Grace Hopper, Ken Thompson, Dennis Ritchie, Tim Berners-Lee, John McCarthy. Of those names, quite a few are still alive right now. It's actually possible to travel around and meet them. This is a feature of computing that differentiates it from many other fields. In Math, Physics, Biology, etc., most of your heroes died hundreds of years ago.
If however, this is just a bunch of poorly trained "enthusiasts" claiming to be crytpozoologists, but lacking any measure of proper scientific method, then this expidition is a colossal waste, and I hope they get frostbite of the penis for wasting resources and time.
Even if they're just enthusiasts, they don't necessarily need to follow the scientific method to produce value. They can prove their claims conclusively by capturing one live specimen and bringing it back to civilization.
It won't happen, but it's possible.
Aramaic paleography skills.
I agree with most of what you wrote, but please note that most of the Dead Sea Scrolls are in Hebrew rather than Aramaic. Also please note that ancient Hebrew is surprisingly readable to people who can read "modern" Hebrew. For the last 2000 or so years, Hebrew has mostly been a dead language used only for ritual and study, so it hasn't changed all that much. I haven't personally seen any of the Aramaic parts of the Dead Sea Scrolls, but I wouldn't be surprised if they were relatively easy to read as well.
About 18 years ago, I stood in the Shrine of the Book in Jerusalem and read from the Dead Sea Scroll copy of Isaiah. I'm no longer a religious individual, but it's still awe inspiring to be able to piece together the familiar words from the ancient, unfamiliar lettering. Now it can be done anywhere, for free, rather than requiring a 15 hour flight.
Thanks, google.
Because releasing damaging information about current religious denominations is dangerous not only to the releasers but also to the psyche of their followers.
Israeli Jewish culture is mostly secular -- about 80% of Israeli Jews. There is a lot of conflict between the secularists and the 20% or so of the religious minority. The academics are usually from the secular side. If the concern were about upsetting religious folks, the secularist majority would not have had a problem with releasing the material.
A lot of folks think that the delay for currently unpublished scrolls is academics wanting to be the first to be able to publish papers based on the material. I'm in this camp. Greed makes a lot more sense to me than a vast conspiracy.
It's not about what the people make, it's about what the people cost. Remember that when the government hires a contractor, there is usually a contracting company. The company gets a lot more money per employee than the employee sees. Some of that is fair per-employee costs such as payroll taxes and employer-funded health care. Some of that is overhead -- the company's HR, payroll, accounting, contract offices, and profits come out of charging more per-employee.
Any new SSL cert validation scheme needs to interoperate with the CA-based SSL cert validation scheme. The existing SSL cert validation scheme does have cert expiration, needed or not. Your bank is not going to switch to a self-signed perpetual cert when the overwhelming majority of its customers are relying on CA-based schemes that will claim the bank's site is unsafe. So certs are going to keep changing. For a new cert validation scheme to succeed, it must be able to accommodate this during the transition.
Meanwhile, DNSSEC-based cert validation can interoperate with the current CA system without an interoperability problem during transition. And when the transition is over, you no longer need to pay a CA.
And I would argue that certs -- or more correctly, private keys -- should periodically expire. People occasionally change jobs. Backup media get misplaced. As keys age, they are more likely to have been compromised, or to be based on unacceptable legacy algorithms or key lengths. Changing encryption keys periodically is a general best practice in the IT industry. The lack of a built-in key aging and key distribution method in ssh is, IMHO, its biggest weakness.
. . . and I appear to have misunderstood Moxie's system. It does not implicitly trust DNS at all. It does rely on SSL certs not to change, which I find odd, given that SSL certs tend to be replaced (either shortly before expiration or after a private key compromise.)
Both the current CA model and Moxie Marlinspike's proposed notary system already implicitly trust DNS registration data. When someone requests example.com, how does the CA (or notary) know that the requestor owns it? In a few rare cases, the CA (or notary) knows the requestor personnally, but that's rare, and doesn't scale to the Internet. In the normal case, the CA (or notary) has no information other than DNS. The CA (or notary) will either check that the requestor's contact data matches the DNS whois data (implicitly trusting the current DNS/whois data) or will instruct the requestor to post a file to their site (implicitly trusting the current DNS records.)
In either case, DNS is trusted implicitly.
Subtlety: note that this is not saying that DNS data is trustworthy. DNS data is definitely not trustworthy. Rather, it's saying that any entity looking to validate a DNS domain needs to rely on DNS data, so there cannot be any entity more trustworthy than DNS.
As an example, suppose a site's DNS registrar was Joe the used car salesman. You don't trust Joe. Your buddy happens to be both the Pope and a Moxie-style notary, so you figure you'll get the Pope to check out the site's SSL. What is the Pope going to do? The Pope doesn't know the site personally. The only information available about the site is in the DNS registry database. So the Pope is going to check the site's DNS database entry -- written by Joe the used car salesman -- contact the site, verify that they do indeed match what Joe wrote in whois, and issue a signature. You now have the Pope's guarantee that the site matches what Joe said it matches. The trouble is that the Pope is just saying "yes, it matches what Joe said" -- you have gotten no more of a guarantee than if you just gotten Joe to tell you that to begin with.
That's why DNSSEC, if it actually could be deployed, would be the best system for traditional SSL certs. Traditional SSL certs are statements about DNS data. There cannot be anyone more authoritative on what the DNS contains than the registrars that generate that data.
Of course, EV certs are another story, in that they make a statement about something different than just the domain name. However, that's another story.
The correct solution to all this is to move certs to DNSSEC or some other DNS-based approach. If you combine several facts about SSL, it should be obvious why a DNS solution is correct:
(1) SSL is about tying certificates to hostnames. Your browser (or other SSL client) connects to an SSL server at some hostname H. The server responds with public key X. The job of SSL's authentication component is to verify that public key X is really owned by hostname H.
(2) The only information anyone has about who owns which hostname is the information associated with DNS records and related whois registry.
So TFA's concerns about not trusting DNS registrars, and wanting trusted notaries misses the point. Even if your DNS registrar is Joe the Used Car Salesman, and your notary is the Pope, how does the notary know who the server really is? Why, the notary has to look into the databases provided by the registrar! So if any notary has to rely on the registrars' data, how can the notary ever be more trusted than the underlying registrars? Any process more complex than somehow relying on the DNS registrar is security theatre. The DNS registrar creates your DNS identity, so is in the best position to authenticate it.
Put differently, if an untrusted entity can mess with DNS registration data, that same entity is in a position to convince any notary of their DNS identity. No process, no matter how convoluted, can fix this.
[I'm about to give up a mod point. Feh]
Doom 1 contained three "episodes", with the first episode released as the shareware version. Doom 1 episode 1 was on Phobos, episode 2 was on Deimos, and episode 3 was on Mars itself.
Neil's Armstrong's autograph is worth more than Buzz Aldrin's autograph. Two reasons: Armstrong is much more reclusive (i.e. he stopped signing in the 1990s, so there is less supply), and Armstrong stepped on the moon first (so he is more of a celebrity, and there is more demand.)
NASA only has so much funding to go around. Shuttle operations are expensive -- each launch costs hundreds of millions of dollars. Development of manned spacecraft is also expensive. So the theory was that NASA would discontinue shuttle, freeing up lots of funding to build shuttle's replacement, and after a few years, we would have a replacement, without need to temporarily increase NASA's budget. In different terms, the gap between shuttle and its replacement was very much a feature. This is the same way that the transition from Apollo to Shuttle was funded, to include the same sort of gap between Apollo-Soyuz and STS-1.