Deregibus

In addition, AFAIK this affects both the ARM and x86 firmware, so a patched binary would imply two separate modifications. Though that would still leave open the possibility that the toolchain was exploited before compilation occurred.

It would have been something that already existed in the string table for the binary, so you would have just been referencing an address and not inserting a string inline.

It'll be interesting to see a more in-depth look at the code surrounding this and some theories on how it could have been implemented in a way that avoided obvious detection. The naive assumption is that someone just added to the code:

    if(!strcmp(password, "<<< %s(un='%s') = %u")) return true;

which is certainly possible, but seems too easily detectable and risky for someone on the inside, and too lazy for someone on the outside that had already gone through the trouble to get write access to the source.

The string itself looks like it's part of some logging system, so my guess is that it already existed and was opportunistically chosen rather than created. If this was passed through a macro, then it's possible that the attacker didn't have to touch the auth code at all and may have been able to implement this by changing only a handful of characters in an area of code that was more amenable to obfuscation.

It's not dereferencing NULL that causes the segfault, its the actual reading or writing of the memory at the invalid address. So, ignoring undefined behavior etc, "* ptr;" doesn't actually generate a load or store since its not really doing anything, but "x = * ptr;" or "* ptr = x;" would. You can also see similar behavior when calling a non-virtual member function on a NULL pointer, the crash doesn't occur until the function actually tries to access some data on "this".

This is all with the caveat that the actual behavior depends on the system and compiler as many others have pointed out.

> Which means the NFL is going to have to find someone else (there is no one else)

Except NBC, CBS, FOX, Yahoo (hah), and the NFL itself via NFL Network, all of which already have contracts with the NFL which are worth more combined than ESPN's. For the NFL, having ESPN drop out would probably be a blip.

Agreed, this seems to conflate sports in general with the specific issues faced by sports-entertainment complex that is ESPN.

The dramatic increase in the valuation of sports is largely due to it being one of the few remaining forms of entertainment that can still reach people with advertisements. Most people watching games want to do it live, which means they cant block or skip through commercials like they would with an everyday TV show.

You're referring to something like?

    objA.funcA().funcB().funcC()

I believe the issue is that it cannot easily be extended with new functionality since all of the methods must be members, whereas operator| can be defined as a free function which allows one to write new chainable functions without altering the base library.

I agree that a function chaining syntax would be preferable. LINQ to Objects in .NET can do something like this because the language(s) support extension methods.

No, I don't think you can extrapolate that, those seem like entirely unrelated issues. Neither of those points imply an overly broad law that only works based on the trust and restraint of the government.

Even assuming the insecure "choose 1 of 3" was for example, I don't really understand how this is better than e.g. a 4-digit numeric code?

It seems like this kind of authentication could be provided by the OS. I'm pretty sure I've used apps that sent a code via SMS to verify identity that detected when the SMS arrived and performed the authentication automatically. Given that you don't want to give every app unnecessary access to your text messages/email/whatever, I would think you could have a fairly secure process like:

1. App requests a unique session code from the OS and registers a callback. 2. App sends the session code to the server. 3. Server sends SMS to the phone # containing the app auth code + session code in a standard format. 4. OS detects that SMS is an auth message, matches the session code with the callback, and sends the auth code to the app. 5. App sends the auth code to the server for verification.

I haven't done any mobile dev so for all I know something like this already exists.

A change pulled into the main codebase is a change that you don't have to merge every time you upgrade. Given the speed and scale of these releases the time saved adds up quick.

FWIW, as part of trying to get some crap Sony laptop drivers working with Windows 10 I installed a clean copy of Windows 8.0, didn't install any updates, then upgraded to Windows 10 via an iso loaded on a USB stick. I didn't even have it connected to a network until well after Windows 10 was installed.

I had already performed the Windows 10 upgrade once on the computer, so it was registered. I would guess if you're doing it for the first time you may have to activate the copy of Win 7/8 first, but maybe just having a valid product key is enough?

For security purposes, it would probably be best to have something that hashes the key and displays it in a more human-parsable format like an identicon for verification. For a terminal, a generated phrase or sentence might be the best way to go; there are some stackoverflow posts about doing just that: https://stackoverflow.com/questions/4683551/generating-a-pse...

For the more general case of analyzing binary data, I could see something like this being useful for other tasks such as visualizing network traffic, or analyzing logs. Basically finding some way to transform the data into an optimal form for human pattern recognition.

Wouldn't this just enforce the existing ad preferences? Say the ad networks determined that you're looking for a car. They then start showing you car ads, this software clicks on them, and now they think that you must really, really want a car. That hasn't messed up the fundamental information, it's just adjusted the scale.

So don't bother trying to make it better because it can never be perfect?

There are multiple orders of magnitude difference in the effort needed to completely rewrite an entire API implementation in this other language vs. adding some annotations to the existing code. Sure it can't catch some really dirty type abuse like that, but it would let you identify when it is happening so you can prioritize your focus accordingly.

Very cool. Anonymous types can be really handy in C#, especially when dealing with LINQ to objects code. This looks like it could be a similar fit.

Cool idea, a couple notes after trying it out.

- Despite the save and delete buttons being big and obvious I looked right past them the first time I entered data and lost all of my entries. I expected that it would just save automatically when the entry fields lost focus. - A 12/24 hour time option would be nice. - I somehow ended up with a duplicate October 23rd. It went away when I refreshed the page.

I think the implication is that since void output(std::string const &msg); takes a const reference, that function cannot change the value of msg. What the function does not know is whether or not anyone else outside of the function could change that value. It doesn't know if the original creation of the object was const or not const.

The example is misleading because there isn't any reason why you would be concerned with such a distinction in this case.

It's a career limiting move in the same sense that my career as a doctor is limited by the fact that I didn't choose to go to medical school. There's no evidence that any of his opportunities outside of making violent shooters have been limited. If he wants to turn down those opportunities then props to him for standing up for something in a way that actually impacts his bottom line. Whether you agree or disagree with his reasons for doing it, this should be applauded. We just shouldn't pretend that he's being persecuted for his choice. He's not a whistle blower that's exposing a conspiracy. People like violent FPS games, they buy them, studios make more of them. That's all there is to it.

Now if you want a conspiracy, you should be looking at gaming addiction and how studios are explicitly engineering games to keep people coming back and spending money. That's where you'll find the real shady stuff.

He originally wrote it back in December: http://www.charlesncox.com/blog/2012/12/why-ill-never-work-o...

He appears to be referring to the writing of benchmarks. Specifically for those in which functional programming excels over imperative (for example undo support), it becomes a significant undertaking to write the C version so it just doesn't get done. This means that there is a selection bias towards benchmarks that can be easily written in C. These simpler benchmarks tend to lack any need for the higher-level constructs that functional programming provides, which FP advocates would argue is exactly where FP gives the greatest gain.

edit: slightly less snark.

That puts the onus on the user to immediately log in after receiving the temporary password. Until they do (which could be months later), they have their password to the site stored in email. The DoS issue that was mentioned in the next paragraph is also a pretty good reason to use a reset link instead.

It's really a question of how time factors into your accounting. If you're spending 10 hours to make $50, then it's tough to claim that as a $50 profit unless your time is worth less than $5 an hour.

Of course there are cases in which your time is worth less than $5 an hour (you don't have any other prospects for making money). Or if you enjoy what you're doing it might only be 1 hour of "work" with 9 hours of enjoyment. The point is that completely ignoring time spent is just bad accounting.

Not at all. When learning any new programming language there's going to be a period where you're working by trial and error. Removing compile-time typing generally means less syntax to learn which makes the feedback loop tighter which I would imagine gets you the point of familiarity quicker. The study seems to back that idea, but not much more.

49 undergraduate students working independently on a small project over the course of a single week using a previously unseen language with no consideration of the performance or maintainability of the resulting code. I can't see how there are any meaningful conclusions to be drawn from this study other than "inexperienced programmers find learning new dynamically typed languages easier".

The Xbox 360 and PS3 processors are very similar, one main difference is the PS3 (ignoring SPUs) is single-core with two hardware threads while the 360 is triple-core with two hardware threads per core. I would imagine that if you locked the affinity of the two threads to the two hardware threads of one of the 360's processors you would see the same behavior. IIRC, The two hardware threads on those CPUs are essentially just duplicate sets of registers that each have their own instruction stream, but execute the instructions in a single shared pipeline (the benefit being that you have more instructions available to fill the rather long CPU pipeline and are less likely to unused cycles while stalled on memory fetches). As far as the actual executing instructions are concerned there would be a single stream of instructions and thus no opportunity for the memory ordering effects that you might see with two distinct cores/processors.

The key argument here is the same as Microsoft's previous issues with undocumented APIs. I think it's fairly clear that Microsoft wants Windows RT to be an iOS and Android competitor, not "Windows 8 on ARM". If you subtract the Classic mode from Windows RT it's in the same OS category as iOS, they just took a different approach to get there by basing it on their desktop OS.

The problem is that Microsoft has turned pretty much the entire Windows API into an undocumented API (AFAIK, please correct me if I'm misunderstanding the technical details here) and completely locked it down so that they're the only ones that can use it. It's not necessarily simple to move a large program like IE or Office over to a new architecture, but it's going to be an order of magnitude easier to do so when you don't have to rewrite it to an entirely new API (in this case Metro) while you're at it. Yes, Firefox can still put out a Metro version, but I would imagine that it would be a significantly greater undertaking than if they had the ability to write to Classic.

The unfortunate thing here is that this isn't necessarily an underhanded plot by Microsoft. There are definitely some benefits to the more sandboxed-style apps pushed by iOS and Android vs. what you can do with a desktop OS, especially when it comes to non-powerusers that just want stuff to work. From that point of view the Classic mode in Windows RT really shouldn't even be there at all, but if you want something like Office on ARM anytime soon then it's probably the only option. The trouble is that Microsoft wants to provide the additional benefits of a few key Classic applications while also trying to avoid having the OS turn into a bunch of poorly-ported desktop applications and I'm not sure they can have it both ways.