gxti

How about criticizing the article instead of the person? Hero worship gets us nowhere.

Yes, in order to validate the chain of trust the TLD must be signed but sibling 2LDs have nothing to do with whether a particular 2LD can be signed. If wikipedia.org wants to sign, they can do so, because their parent (.org) is signed, but it doesn't matter whether widgets.org is signed.

Phreebird isn't critical in any way to the arguments he makes, it's simply offered as an example of online signing with DNSSEC. It's right there in the first paragraph, mentioned alongside existing, well-known servers which are purportedly adopting more online-signing-like features.

Which would be only marginally more specific. Humans have been eating "artificial", "synthetic" foods for thousands of years, and all of these things are made from "natural" ingredients because matter can't be conjured from thin air. Can you really come up with a test to distinguish between a just-invented stabilizing agent with unknown long-term effects on health and, say, flour?

You could use a Diffie-Hellman exchange to get a shared secret so things are "obscured by default" but not trusted, then let higher layers deal with trust validation. For example, the TLS certificate handshake could just be a matter of constructing a blob containing the two endpoints' DH public keys and signing it to prove that a man-in-the-middle hasn't intercepted the channel. All the actual encryption would be handled by the IP stack and offloaded to hardware, while the application-layer TLS bits would be used once at startup (and maybe subsequently if the lower layer re-keys) then get out of the way.

Key and cipher negotiation could easily be shoehorned into the three-way-handshake already used to establish connections. AES with a CTR block mode would be the obvious cipher choice since each packet would be handled separately. With TCP you could even just use the sequence number as the counter, although this would be harder at the IP layer.

But yeah, none of this would have been available at the time. Still, given today's technology it would not be difficult to future-proof, especially if the trust machinery is left to the application.

I use my own MX rubber-banded together with Postfix, SpamAssassin, and dovecot IMAP. I also have bucket.mydomain pointed to mailinator.com so I can use addresses under that domain as throwaways without the site I'm signing up for knowing about it, although I also use Postfix aliases for long-term throwaways.

My coworker runs his own MX, but bounces all his mail through Google just for the spam filtering.

Apple adopted H.264 years ago -- it's basically all they use.

They're not sitting around a conference table in an underground bunker, stroking their beards and cackling maniacally while trying to screw the open source community as hard as possible. Microsoft is a business. What business sense does it make to release this plugin?

That is, until it starts taking over the target computers and clicking the links itself. Any naive utility function will produce undesired side effects:

http://wiki.lesswrong.com/wiki/Paperclip_maximizer

> The author's whole premise is that dropping out is universally bad and should be discouraged, and that staying in school is universally good.

No, the entire premise is in the title: Don't encourage kids to drop out. If they want to do it, they'll do it, and good on them for it. The last paragraph even argues against "extreme points of view" which would suggest that interpreting the article as "they say drop out, don't do it" is totally wrong.

> Where might we be if some of the 'usual celebrity dropouts' hadn't dropped out?

Worthless speculation. We'd be somewhere different, yes, but no less interesting and no worse off.

Clarify? Collision attacks by definition do not feature an existing digest as input so they are not useful for breaking into a system secured with a digest.

You are right, of course. I wrote that as 'ideal digest' instead of MD5 then rewrote it. Specific digests always lose a few bits in real life, or in MD5's case, most of the bits...

The Quebecois are particularly fond of religious imagery as a basis for cursing:

http://en.wikipedia.org/wiki/Quebec_French_profanity

Actually you can (almost surely) stop cracking at 16 bytes, because that's how long MD5 digests are and any more bits than that are going to give you hashes you've already seen. You won't get back the original string but you don't need the original string.

You can upgrade passwords when the user logs in. The sanest thing to do seems to be to store all the public variables (work factor, salt) alongside the digest so each password can be handled separately.

> is it possible, given the ciphertext, to know roughly how much work is required to test a password?

The work factor is an input to the digest function, both when creating and when validating the password. Normally it should be stored alongside the digest itself so you can increase the work factor over time without disrupting existing passwords. So you are correct. It might theoretically be possible to correctly balance the work factor to counter variation in password info entropy so that all passwords take about the same time to crack, and this would be very cool and impress members of the opposite sex, but it would not improve security at all.

Making a probabilistic password checker is also a superficially interesting idea. Maybe my mind is too small to explore it completely, but it seems that at best it would be no better than just increasing the work factor.

To nitpick, the topic at hand is pre-image attacks, not collision attacks. Pre-image is where you know the hash and want the plaintext, collision is where you create two plaintexts with the same hash but don't care about the actual hash value. The former is recovering information, the latter is falsifying trust and almost always involves signatures.

Collision attacks don't apply to many situations but are much easier to execute, for example a MD5 pre-image attack requires approximately 2^128 steps but a collision attack requires only about 2^64 steps. This is why MD5 is totally unsuitable for collision resistance, and in fact has already been successfully exploited to fabricate a real-world CA certificate, but still puts up mild resistance to password cracking. Not that I'm recommending you use it or anything -- do what the nice gentleman says and just use bcrypt already!

Why does the font size change randomly throughout the article?

You didn't explain why rewriting local, private history breaks any of those things unless you keep your local, private branches around indefinitely in un-rewritten form. If I rebase, it replaces my previous branch, not extends it. `git rebase` only breaks bisection if you are using it incorrectly (on public commits).

The answer to a question in a headline is always the null hypothesis. In this case, "no".

> How does one revert this without physical access to the drive?

I know this was a rhetorical question, but I'll answer anyway: It isn't possible. Not only is there no way to read latent data normally from a drive that has been zeroed (drives that fail this test are called "defective"), but it is currently understood that recovering data from a modern drive that has been overwritten with a single pass of random data is impossible at any expense.

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html#E...

However, data can still leak out of cloud stores in the same way that it leaks out of solid-state disks and even magnetic disks: there's no guarantee that a given logical block will always be mapped to the same underlying hardware. A mirrored drive may be fail and thrown in the trash with data still on it, or written blocks might be mapped to different places in an array for any number of reasons. This shouldn't result in leakage to other customers although it is up to the vendor to make sure this doesn't happen.

Depending on the implementation, vendor-supplied encryption may or may not mitigate this risk, but customer-supplied encryption always will because the customer knows where the dividing line stands.

If I were writing a block provisioning system I would keep a map of what blocks have not yet been written to and always read zero for those blocks. Then the first time it is written, allocate a block that has already been zeroed out. This way I don't waste time and electricity zeroing entire volumes before they are allocated or after they are deleted because there is just one pool of same-sized blocks to draw from. Choosing the block size to strike a balance between allocation delay and cost of blanking is an exercise left to the reader.

Individual streams aren't parallelizable, but if you have many streams open at once you could hypothetically process them together in parallel instead of separately in parallel as it is with a CPU.

Also, there are block modes that are seekable and thus could be parallelized if you had a big enough backlog, CTR mode in particular, but parallelizing individual streams is not likely to reap big enough rewards to justify the complexity.

I would downvote if I could even though it's now at 5 points. Topical or not, it's still a content-free post.

"copies of the Software"

Doesn't say anything about the name. Trademark law and copyright law are related but very distinct. If Oracle owns and enforces the trademark "Hudson" in the context of continuous integration software, and they say "Stop using the name Hudson", you must comply regardless of any copyright licensing in effect.

Compare Firefox which has a free software license but prohibits use of the Firefox name if any modifications are made to the code. This is why it's called Iceweasel on Debian -- as I understand it, even a security patch is technically enough to violate the contract.

There are two nice things that you get with an explicit "self":

* You can nest classes and methods. This is ugly, so I never use it except in testsuites where declaring a mock class right in the test method is the best way to do it, but it's great to have "self" be the testcase and "xself" be the mocked method.

* There's no such thing as a magic variable. Every name you can reach is declared somewhere, either locally, globally, or from `__builtins__`. If self were automatic, then it would be invisible like the builtins, but it would change depending on where you used it from. The consistency is worth the minor inconvenience, IMHO.

I'm currently building a high-quality zener diode-based RNG. There's a dearth of good information on the internet about these things, everyone seems to offer a schematic but their explanations don't really show any sort of understanding of the process.

In any case, I think this design qualifies as "quantum" because zener diodes at 5.6V and less work through quantum electron tunneling ;)

> So you don't believe in property rights

The right to keep people OFF my property and do with it what I like.

> the right to an attorney; the right to a trial by jury; the right of a speedy trial; protection from unreasonable search and seizure; the right to confront your accuser?

The right NOT to be hassled or detained by the government unnecessarily.

Oversimplified explanations yes, but I don't see any of those as requiring others to step up and fulfill my own rights. Police keep people off my property using the implied threat of violence not because that is the only way to fulfill it, but because the alternative -- me enforcing it with overt violence -- is less palatable both to myself and to the police.

Whether the proposal by this website falls does fall under "positive rights" depends on the interpretation but I gave up on trying to read it so I can't say. If they call for the right to obtain access to the internet without interference (censorship, etc.) then I respect that although I don't necessarily stand behind it. If they call for the right to have free WiFi across every square millimeter of Earth then I don't think anyone who gave more than a cursory thought would agree.

This is a perfect example of why one must use the utmost caution in allowing a choice to become part of one's identity. When the time comes for that belief to be challenged you will fight not because it is true, but because it is perceived as an attack on the self. You will ignore reason and fight to save that piece of yourself from annihilation like a feral animal cornered by a predator.

You are not a vegan. You are not an atheist. You are not the car you drive or the contents of your wallet. You are a human being, and nothing that is within your power to change should be exempt from introspection.

> Ports over 1024 are unprivileged ports

Good point, but

> they could start up a counterfeit one and collect your password.

you missed the part where I disable password logins on all of my boxes :-) The important point was that the system was already secure enough due to the key requirement, and moving the port was indeed just to stop the "doorknob rattling". If I suddenly find that a box I control is asking me for a password, I'm not going to just type my social security number in and hope for the best.

One could argue that using a port < 1024 makes it easier for the scanners to find, but frankly anything other than 22 (or a frequently scanned port) would work well enough.