I'm probably the same way. Got to milk my 3 digit UID for all its worth. :)

I've never gone to a meetup. I'd be self-conscious, feel out of place, and so on. Add travel, and forget it. If there was one here in Detroit, i'd at least consider it.

I did meet one slashdotter though. He got me an interview in Toledo. Though i don't remember who it was, i remember his smile when i came through the door and feeling good about meeting someone else.

Touche!

I feel the same ways about JEs.

Whoa! You're getting aggressive and want to shoot four people?

Thanx.

Now why don't you post something. We haven;t read any JEs from you in a year and a half! :)

YouTube hasn't been tied to flash for a couple of months, with HTML5 the default video play mechanism since late January. Not all browsers will pick that up, apparently, since I've recently had Flash crash in Firefox during a YouTube playback.

There are plenty of sites still tied to Flash, and that includes internal corporate sites. Those will be even harder to dig out, and Chrome is about the only means of Linux users to access Flash these days (at least in a vaguely secure fashion, since Flash for Linux hasn't been supported by Adobe in some time).

The Chrome dev team has been trying to eliminate cruft from the code base for a while now, as is visible if you spend some time in the bug tracker. This may be a case where they got overzealous in trying to not have legacy code remain when they implemented a new feature. But given the number of distros running 3.17 or later, it should have been obvious that backports would be required for many (most?) distros, and that backporting is often seen as more work that distro devs would rather avoid so they can concentrate on standard code-bases.

I see both sides of this: Google wants the most secure environment possible, and Debian has a development freeze for good reason. It's easy to overlook a flag like TSYNC if it's not being mandated by something major when the review is done, which may be the case here. But Debian may have to fold on this because they're not a big enough slice of the user pie to force Google to back down.

Presumably, you're running RHEL/CentOS 6. If so, that's cool if it works for you--the stability is probably greater than just about any other major distro--but I think the expectation is that most who run Linux for their notebooks/workstations will run something newer and more flexible, and run something like that in a VM. But there's always the reality that RHEL/CentOS 6 isn't going to run the latest software in many cases (unless you go with non-standard repos), and here's a case where a browser has become one of those cases.

It's probably also surprising that you run a six-year-old notebook in a corporate environment. Even the fiscally conservative companies tend to upgrade notebooks at least every four years, even if they are Fortune-100 companies.

At some point, having a server (like Linode) becomes well worth it. As long as you have a network connection, you can connect to your one development box.

No, those who want perfect solutions want the impossible. I want a framework that can be improved over time.

What's the goal? With maybe a handful of exceptions, everyone does something that can compromise their security. HTTPS relies on a trust architecture that we're being reminded recently (Superfish, PrivDog) is actually extremely fragile. And yet it's being encouraged to make the job of the average surveillance tool more difficult. It's very much letting The Other Guy(TM) (remember, three caps minimum on the TM'ed stuff) handle security. It has flaws, but it raises the bar.

That's what we need for end-to-end crypto. It can have flaws, but it needs to raise the bar, and be able to keep raising the bar.

As for understanding how it happens, how many people can describe how an RSA key is generated, much less how a proper PRNG produces a suitably random number and then how AES/Blowfish/whatever encrypts the data? Does the average person need to know that? Not really. And even if they did, they don't care, which is why they don't use it now.

Right now, we have options where you can let a CA provide you your TLS certificate (usually 2048-bit and SHA1). If you know what you're doing, you can roll your own with better security. We need something with that flexibility (though I recognize the flaws of that exact model) for end-to-end crypto, too. We need clients that auto-update, that add or deprecate algorithms as they arrive or are broken without the user having to worry about it, and that can provide safe (and revocable) storage for the keys so they survive a catastrophic loss or be deleted with near-absolute certainty if the user wishes. We need common libraries or protocols that can allow new or existing clients to safely implement connections to these services without having to build them from scratch, thereby preserving and encouraging competition.

These don't lead to a perfect system. They lead to a good enough system with room to grow and improve. But I would argue (as I think Moxie does) that what we have now is far from a perfect system because it's too difficult to use.

Not remotely. He's encouraging good encryption, but calling for some updates (it hasn't significantly changed since the mid-'90s) and a better wrapper. GPG is still largely by geeks, for geeks. I couldn't get my parents to use GPG because they'd dismiss it as too hard, even if one of them is happy to stick it to the man. The suggested minimum settings vary based on where you look and when they were posted.

Example: An RSA key size of 2048 bits is largely considered secure, but NIST recommends 3072 bits for anything that one would want to keep secure into the 2030s. People still often see their e-mail as their private papers and may be concerned over who can read them well past the 2030s. But does that mean they use 3072, or go with the random crypto weblog guy who says to always go with 4096? And why can't I create 8192- or 16384-bit keys like that software claims to over there?

And what to hash to use? Plenty of sites still say MD5, but they were written years ago. Some have updated to SHA1, but others point out weaknesses there. OK, SHA2, then. But then there's SHA256, which must be better, right? (I know SHA256 is a subset of the SHA2 family, but those unfamiliar with crypto will not.)

Until GPG-style crypto becomes relatively automated, it won't be embraced by more than a handful of people. HTTPS is widely used because people don't have to think much about it. This has some downsides for poorly-configured servers and Superfish/Comodo-style backdoors, but browsers and other software help take up the slack by rejecting poor configurations. PGP/GPG were designed to reach near-perfect levels of encryption, but that bar is clearly too high for significant uptake. We should instead be looking for something that encourages end-to-end encryption that is good enough. We can build on if the underlying structure is properly designed, and as people get more accustomed to crypto in their lives, they'll be able to adjust to improvements.

When the majority of communications are relatively well-secured, it makes it far more difficult for a surveillance state to conduct its operations. Perfect security can still be a long-term goal, but we need more realistic goals to encourage uptake in the meantime.

The law is generally stated that for two vehicles traveling in the same lane with no immediate changes before a collision, the trailing driver is at fault in case of a collision. However, it's a valid defense if the leading driver performed an unsafe maneuver prior to the collision, such as changing lanes with insufficient spacing.

Weirdly enough, women were quite well represented in technology before the 80s. Clearly there was an interest - so what's changed?

Women in other countries are somewhat more well represented in technology and more likely to go into STEM fields - so what are those other countries doing differently?

There are a number of things that make a strong case for the reasons women aren't well represented in tech being related to artificial issues rather than natural tendencies.

Tech isn't singled out as the one and only important field, by the way. I'm not sure where you get that idea from, but if you look at most any field with a lopsided gender ratio you'll see concern about the gender imbalance and efforts to remedy it. Nursing programs will aggressively pursue male candidates, same for elementary teaching, for example.

In any case, my guess as to why tech is singled out is not that tech is singled out, but that you're probably primarily reading tech sites where this gets discussed, so it just seems that way.

A willingness to give partial credit for work shown, even if the ultimate answer was wrong, and other things like that. They may be more willing, in this case, to assume that the boy with the wrong answer was on the right track, while the girl with the wrong answer was just flailing around and guessing, even when the provided answers and work were the same.

RMS hasn't been an active developer in years by his own admission. His role is largely advocacy and philosophy, and that appears to be the sole issue here. However, he doesn't seem, based on a reading of the thread, to have any formal ability to block the patch.