Silk Road Kingpin or not, I'm rooting for Ross here.

I wonder what the people he attempted to have murdered think about all this?

If we follow the arguments in the article to their logical conclusion, then you're talking about an accusation coming from a bunch of criminals. Indeed, one might argue that it's a criminal conspiracy against him.

If they're going to act like criminals, then the government has no credibility in any accusation they make against Mr. Ulbricht.

Now, he likely is a criminal scumbag who did some very stupid and/or shady things, but given the choice between going after one shady guy or an entire organization of criminals, which do you think is a better use of law enforcement resources?

Changes require systematic, reliable evidence, not emotional expressions . . . In the wake of more than 3 million comments...

3 million people having a coherent opinion on the subject is as systematic, reliable evidence as any other survey of public opinion. That the bulk of those 3 million are likely saying that network neutrality is a really good idea should be considered a fairly reliable data point. I'm not sure it would be a good idea for the FCC to just brush it off.

You implied that some manufacturers don't drop support prematurely.

Hm. True. I could've phrased that better, although the definition of "premature" in this case might be debatable. I like to think that everyone will agree that "while the device is still being sold in stores" definitely counts as "premature", and I'm of the opinion that anything less than 2 years after introduction is pushing it.

Outside of the Nexus line, I'm not sure any device would get a pass.

Even Google drops support for Nexus devices after 2 years.

They suggest it'll typically be 18 months, but I'm not sure they've released enough Nexus devices to establish any kind of solid track record. At the moment, the 1st gen Nexus 7 is over the 2 year mark and appears to still be seeing updates. The Nexus 4 and 10 are still being sold, so I doubt you'll see Google stop supporting them soon even though they're comfortably at the 2 year mark.

Google is just in a snit that CyanogenMod is fantastically better than stock android, BECAUSE it gives power back to users.

So does Xposed, and far deeper than CM ever contemplated.

More likely Google is looking at CM because CM effectively helps to solve the Android "fragmentation" problem, namely getting the latest version onto devices where the manufacturers drop support prematurely. All they'd have to do is officially brand CM as their "Android legacy support" service and just kinda step back.

Even if the US changed every single speed limit sign tomorrow to from MPH to KPH, how hard is it to match a number on a guage in front of you to the sign posted on the road?

US cars have mph as the main unit and km/h as the secondary. Canadian cars, for example, have km/h as the primary and mph as the secondary.

I would never have thought this was an issue until that stretch of time where I was switching between a Canadian and US vehicle for a period of time... it's not rocket science, but it's definitely an extra cognitive load when you're driving, and if you're not used to a particular vehicle then the difference between 55mph and 55km/h isn't as obvious as you'd expect.

It's a bit like what happens when the instrument cluster is put in the center of the dash (fuck the Nissan X-Trail) or the speedometer range is substantially different from what you're used to (if you're used to 100km/h being right at the top of the dial and you move to a vehicle where 80km/h is at the top, you *do* drive slower until you compensate).

As I said, not rocket science, and individually it's not a big issue, but with the sheer quantity of marginal drivers on the roads... I don't expect the transition would be bloodless.

The wrong mechanism (a semi-persistent environment) is being used to transfer what should have transient data. That is a vulnerability in the spec.

Hm. Okay, I'll buy that argument.

In practice, if the CGI developer follows best security practices it shouldn't be a more significant problem than any other "untrusted input" path, and whatever invokes the CGI does have the option of cleaning up the environment instead of accepting the default, but it's fair to say there's a flaw in the spec.

The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.

Well, it's not that it allows external entities to poison the environment, it's that it gives the finger to that basic secure programming practice where you should just assume that externally provided input is tainted data.

(you could say that there is a design vulnerability in CGI - and I would agree about that).

Debatable.

There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved. And, aside from security, the performance hit of invoking a shell just to launch another program makes it a bit silly to do it any other way.

And I'd point out that it's possible to explicitly control the environment of a subprocess (i.e. execle()), so anything calling a CGI program can at least sanitize things to minimize any damage. Not that the CGI should depend on the caller to sanitize things, of course.

On the other hand, the environment is a perfectly stupid way to pass code around.

Valet mode also locks storage compartments, and disables the stereo.

Missed opportunity, there. It should turn the stereo on, and shuffle play Celine Dion's Greatest Hits at loud volume. Guaranteed to discourage joyriding, or any other kind of joy.

Given the massive increase in CCTV installs in places like parking areas, can a valet make a convincing claim that they have an expectation of privacy on the job site?

The only communication mechanism for talking to the subshell is the environment.

Well, the easy communication mechanism is the environment. And, quite frankly, I don't have a particular problem with bash treating stuff that bash intends to be a chunk of code as code. It's just random other bits of the environment that aren't intended for bash that are the problem.

It's *nix, though, so there's many more ways to pass data around between processes than just the environment. Even if you've gotta use the environment, why not go with a env variable namespace, like "BASH_FUNCTION_FOO=()"?

Try to understand, this is not about executing bash scripts as cgi, and it's not about sanitizing input. Period. It is about httpd setting environment variables from unsanitized user input when calling ANY cgi.

Well... no. The root of the problem is bash treating something which really should only be considered data as code.

When I hear the words "Environment Variables", I don't think "well, some random bozo is going to look at those and just up and execute 'em". For bash to be treating the contents of the environment as anything other than dumb strings is, quite frankly, a Very, Very Bad Thing. For variables being set within a shell script, sure, they're intended for bash. But for data passed from program to program and not really even intended for interpretation by any specific script engine (which is fundamentally what environment variables are for), it's incredibly dumb.

Personally, I like the idea of that. It encourages and funds a lot of Canadian artists that might otherwise get swamped out of the market by monied American interests.

Personally, I would much, much, much rather the CRTC enforce rules for true network neutrality for Canadian internet users and find some other way to promote Canadian content.

Or, more accurately, for someone else to force the CRTC to go that way, because there's pretty much zero probability that they'll do it without coercion.

The problem with relying for support for separation from the younger generation...

Well, yes. It still takes at least a generation for them to work it out of their system. 40 years might do it, but seeing where we are now in Canada I think it's going to take another 20 or so before we can really feel comfortable that separation is truly dead.

The reality is that there's more people in the RoC (Rest of Canada) who would vote to kick Quebec out than there are Quebecers willing to pull the trigger on separation.

Oh, definitely. And to some degree, I think the growing understanding that Quebec wouldn't be able to unilaterally dictate the terms of a separation actually proceeded is one of the biggest factors in killing the movement.

Apple also sells music in its lossless format, and there it's hard to get "robust" without annoying the listener.

No argument that it's hard.

But if Apple (I highly doubt U2 is directly involved in the research itself) did manage to develop a robust audio watermark that doesn't suck, it's understandable how someone would get the impression that it might result in an "unpiratable" format, at least within the bounds of the Apple walled garden.

The separatist movement here has burned itself out, the generation who were pushing for it being seen as burned-out old farts. Go back to the UK in 40 years and tell me that everyone lost.

From what I read of the demographics, it's mainly the younger generation of Scots that supported separation. They're pretty much at the stage of Quebec in the 70's.