Umm, have anybody (outside insane project like the Danish NemID) been doing applet programming for the last 10 years?

Serverside Java is still pretty strong, and I don't expect it will go away for a long time - and JVM-based stuff will last even longer, unless whOracle manage to screw up bigtime.

Well, HELLO there, internets!

It'll be interesting to see why that company could not be named. Banking, perhaps?

"Nobody wants to play those games". Like, nobody would want to play anything with an inferior non-DRM experience. Catch my drift?

Do keep in mind that you're talking about one specific technology stack here.

Really? I might be misunderstanding things, but the general browser engine is going to be C/C++ code, whereas all the famo.us stuff will be javascript. Sure thing, JS engines have become a lot more performant lately, but they still don't beat native code.

But sure, if you offer more limited layouting, you might be able to outperform the native browser engines with JS+WebGL. HTML+CSS is a pretty horribly bloated beast.

I would seriously love to know which value they extracted from grabbing his tamagotchis (and other devices). All in all, my impression is that the Norwegian police gained NOTHING from raiding him (except US-bitch creds), because everything relevant was in the open, anyway. It's been several years since I spoke with Jon, anyway, but he was doing well back then - he moved to the .us and attacked FairPlay. Before that, he had went under hiding to avoid the .no army... dunno how it is now, but back then, to avoid conscription, you had to claim you were homosexual (or at least that's what he told me).

I hope he's doing well nowadays, he was definitely a happy influx in our IRC channels back then :)

Mod parent up - I'm replying here, so can't use mod points :-)

Passing the decryption keys around in BIOS-style boot is somewhat dirty - haven't perused the TC source, so I don't know how they specifically do it, but it'd probably be along the lines of leaving the key at some fixed memory location, and let the Windows boot-time driver read it from there. UEFI drivers have a whole new way of booting the system, so you'd need to adapt to that. It's probably doable, and probably doesn't even need big voodoo - but if you've been working on a codebase for ~10 years, don't need UEFI support yourself, and probably have a family to look after now... it'd be a darn big task implementing. While UEFI stuff can be programmed in C rather than assembly and has SDK and documentation, it's quite a different world.

If we ignore (or postpone) encrypted boot volumes, however, I'm pretty sure that very large parts of the TrueCrypt codebase could be re-used - and at the same time, the really archaic build environment requirements could be dropped.

This sounds like over-the-top paranoia to me.

I'm a developer, and I used the phrase "impossible" quite often (though often softening it with "without spending way too much effort"). In the case of TC, I'd be far more inclined to believe that "impossible" either means due to license/copyright issues or because the build process requires really arcane versions of arcane tools rather than it's backdoored all the way to hell.

If anybody worth their salt forked (and audited) the code, they'd find the flaws that aren't deep-math problems in the core crypto code. And it'd probably still be easier to do fork-and-major-cleanup rather than rewrite-with-original-as-base - just look at what the OpenBSD guys are doing wrt. OpenSSL->LibReSSL - rewrite from scratch would likely introduce new security problems, and irregardless of whether you rewrite from scratch or "just" clean up the code, you need to go through every friggin' source file anyway.

You're missing the "it was already backdoored" vector, though. I don't personally believe this is the case, but it's a possible scenario - "OK, code audit is ongoing, they'll find it sooner or later, let's bail".

Dunno about "lack of interest" - TrueCrypt is pretty feature-complete. Genuine question: are there any major bugs or lacking features in 7.1a?/

Assuming, of course, that the C&D letter comes from the original authors, and not shills set up (and funded by) whatever TLAs.

/me polishes the tin-foil hat :-)

Please provide evidence that they didn't :-)

No, the audit didn't show that - the matching build was done by somebody else. A later goal of the audit project is to produce "repeatable, deterministic build", though.

The backdoors you have to worry about in Real Life isn't of the "if (nsa_are_connecting) { ... }" type - it's very subtle things that look like late-night coding errors, buffer overflows that allow remote code execution, or really obscure mathy stuff in crypto algorithms (like the wonky Dual_EC_DRBG stuff - that required hard math analysis, and wouldn't have been exposed during a code audit). In other words: you wouldn't discover backdoors from commit logs unless you were a world-class programmer and cryptographer, and you did hardcore analysis of all core-crypto related commits.

IMHO, any buffer-overflow or other "ability to run code on target machine" flaws aren't indicative of backdoors, merely human errors, and it's not critical to the security of TrueCrypt (or any other encryption software) - what we need 100% security against is cold attacks on encrypted volumes. Of course other flaws should be fixed, crypt-key material should be burned as soon as not needed, et cetera - but as long as you have an encrypted volume mounted, you are going to have the encryption key loaded in memory, and if anybody is able to execute code with root/admin/ring0/CallItWhatYouWill, they will be able to snatch your encrypion keys, and you're game over.

For something as potentially annoying as an opensource, audited, cryptographically (and code-exploitability wise) secure system, do you really believe NSA wouldn't be able to affect people in other countries? Just look at what happened to Jon Lech Johansen when he published the DeCSS code - he was in Norway, did nothing that was illegal according to Norwegian law... yet the .us media industry flexxed their muscles, and his home was raided and all electronic gadgets (including cellphones and a tamagotchi) were raided.

Now, I'm (honestly!) not really sure who are most powerful, the NSA or the .us media industry. But I'd wager that the NSA are willing & capable to do some really nasty things against civilian not-very-well-publicly-known targets.

I somehow kinda doubt that there's any blatant backdoors or crypto vulnerabilities in BitLocker - it would be very, very stupid of Microsoft to do something like that; there's a lot of eyes on MS, and a lot of people (including very skilled Reverse Engineers) who'd like to see MS burn.

On the other hand, given a Court/NSA order and a target, I'm also pretty sure that there's very easy ways for MS to retrieve crypto keys from a running system and handing them over - complying, but keeping the overall BitLocker integrity intact.

Cold attacks against a powered-down system? I'd actually be surprised. MS have done a lot of evil, but it's evil of a different kind.

It's nice to see that there's still people interested in the *original* XCOM games - and not the utter junk that's been released since TFTD.

Some 13 years ago (wow, time flies), I was delighted to see a Windows re-release of the XCOM games (the "Collectors Edition"), since the DOS version was indeed pretty troublesome to get running under Windows - this was before the luxury of DOSBox. However, the fine developers who did the port didn't know the difference between "pitch" and "width", and thus it was unplayable (on a wide range of graphics cards, apparently). I was put down by this, but my friend who was visiting that evening said "well, you usually fix... bugs... in programs, so can't you fix this?".

One frantic night of reverse engineering and beer-drinking and reminiscing about chryssalids and tentaculats laters, I had a bugfix loader running. XCOM once again! The CE port in general wasn't perfect, the XCOM1 intro only had MIDI music but not the muton screams and other sound effects, there were stall-for-a-second issues when changing soundtrack on many soundcards, et cetera.

When XCOM1+2 were re-released on STEAM, they initially used my bugfix loaders (I'm told they use DOSBox nowadays - that's a more authentic experience). Didn't even contact me about it. When I reached out to the people in charge (took a while, the rights to the brand had been shifted around quite a bit), I was told that the source code no longer existed - apparently, at the end of days, it had existed on a single laptop that had been stolen or destroyed or whatever.

So, with the above in mind, it's nice to see that people are trying to re-create the legacy of one of the best games I've ever spent countless hours with.