Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:The dumbing down is real (Score 1) 170

I couldn't agree more. Most CS graduates can get by writing and maintaining application code, but as soon as it gets to getting their hands dirty and doing library / infrastructure work, i.e. touch real data structures, etc., good luck with that! And that's only foundational stuff... I'm not even mentioning serious aspects like IT security, where a solid mathematical understanding of crypto basics is required nowadays, along with a good base of discrete mathematics, complexity theory and so on. Your typical CS graduate will only have a very superficial understanding of those topics, unless he specialized deeply into that... and even then I wouldn't be the farm on their cognitive skills. That's really sad.

Comment C is slowly being replaced by C++ (Score 4, Insightful) 286

C isn't dying, but I think that it is being slowly replaced more and more by C++. Not all of a sudden, but when new code gets added, it is just more convenient to use std::string, RAII, the whole C++ Standard Library. Especially since C++11, C++ and its library have matured a lot to actually become useful and have you write beautiful and fast/efficient code, thanks to move semantics. So no, C isn't dying, it is morphing into C++11 and later. Even for embedded and kernel-level programming: check out recent projects: many use C++, carefully avoiding features like virtual functions that would slow down running time. It is as good as C can get, only better.

Comment What's the most security-hardened Linux distro? (Score 1) 224

Still relying on OpenBSD, and sometimes also on a trimmed-down FreeBSD with Capsicum for security-related work; but I'm wondering what the most hardened (minimalist) Linux distro you guys are recommending? I understand that the less software, the smaller the attack surface, but I'm also thinking along the lines of SELinux-by-default, settable access policies (not just discretionary access policies but also rules-based access policies), etc...

Comment Re:Roll back surveillance (Score 1) 215

Let me put this file I encrypted with PGP on an anonymous FTP site / dropbox. You can then download it and tell me what's in the file. No wait, you can't, because it's encrypted with an OS-agnostic algorithm and you don't have the key.

I'm not sure you get the point. Are the (private) keys located on the Android device? Do you enter the passphrase to unlock the private keys directly on the Android device? If so, your beloved App's security is toast, because key material is hitting the OS before it even reaches the App.

Comment Re:Roll back surveillance (Score 1) 215

Encryption is out there, and a reality. If the phone manufacturer compromises their full-disk encryption, then app makers start writing un-compromised encryption into their apps.

If it were only so simple! If the underlying OS is compromised and can't be trusted, what's the value of any encryption on top of that?

Let's say Gov't passes an anti-encryption law for smartphones. First thing Apple and Google will (have to) do, is to purge their App Stores from all apps that implement un-snoopable encryption. That's the first step. So no un-compromised encryption in apps for the plebs.

Then, next step, Apple and Google will (have to) remove all encryption libraries and support in the OS (libraries etc.), or cripple them with backdoors, so the Government(s) and other evil-doers can snoop right back in, even if Apps are still allowed to call encryption APIs.

Finally, every I/O in and out of an App has to go through some layer of the OS; and if the OS can't be trusted, what good is solid encryption? You as a user can't listen to encrypted voice, you can't read encrypted messages, you can't watch encrypted photos and videos: you're the analog counterpart that requires decryption, and this is the point where device makers will be compelled by the Gov't to let the snooping start.

Of course, there's still the option of alternative ROMs that you compile yourself out of reliable source code (CyanogenMod et al. come to mind); but here, there are still some binary blobs that are required to drive the modems etc.: same problem as with a regular Linux: do you trust these, if Government were to mandate snooping on a hardware low-level from manufacturers?

Comment Re:Should have stayed with Russia (Score 1) 12

Your politicians took the bribes from the US to part ways with Russia, now you get to enjoy the wonderful world of American IP law.

That's exactly the point. On the other hand, Russia is also cracking down on file sharing sites: remember AllofMP3.{com,ru} folding under US pressure/blackmail, or, more recently, their draconian laws on personal identification for users of Russian-based Internet services?

Comment Slow(er) learning of new application domains (Score 1) 435

As an older programmer (say, 50+), learning new programming paradigms is easy. Hell, absorbing new frameworks, programming languages etc. in a week or two is still a piece of cake. Why? Because that's not too far from the domain you know. BUT, diving into totally new application domains requires a lot more efforts than when you were younger. As an example: if you've never been exposed to an EE education and you suddenly have a project about, say, writing an antennae simulator, you'll have to absorb Maxwell's Equations, and related maths. Even if you've had CS training with maths background in your prime, you'll definitively need a lot more time to wrap your head around this with 50, 60 than if you were in your 30ies. That's not impossible, of course, but the additional time to understand this new domain, and apply it to programming, will slow you down so much that companies will often refrain from hiring you, despite your immense wealth of additional side-knowledge that could be very useful.

Comment Re:What data? (Score 1) 25

You can't be sure if they don't provide the source code. But even if they did... basically, they claim to implement Signal Private Messenger's protocol, which is strong end-to-end encryption. However, even this protocol doesn't hide metadata from WhatsApp's servers. For example, every WhatsApp user needs to keep WhatsApp directory server(s) updated about his/her current IP so she can be found by others WhatsApp users. This alone is already up to a couple of hours pretty accurate meta data that can be invaluable to Facebook... which can target you with better ads, based on your current (network) location.

Comment Explicitly destroying objects (Score 1) 239

I'm working in Unix and Network programming and also Systems programming, and I made an early habit of explicitly destroying / releasing / closing resources that are not needed anymore, even when they are reclaimed by the OS when the program exits. This includes in particular open files, and all kinds of network descriptors. Why? Because most of my code usually ends up repackaged into libraries and reused inside longer running programs (i.e. inside loops); and not being disciplined about releasing resources would result in all kinds of leaks. This is particularly bad when that code gets reused inside device drivers.

Of course, things got a lot easier once I switched from C to C++ and the STL and RAII idiom, but trying to release resources is still ingrained in my muscle memory; it takes a conscious effort in C++ NOT to explicitly release a resource acquired through initialization.

Comment Re:How to escape being compelled to decrypt your d (Score 1) 319

Please help refine this by pointing out shortcomings of this scheme.

The shortcomings is that the encryption is visible to the average guard and unnecessarily raises eyebrows.

How about this (on Android)? You install two operating system images on the phone, say, two instances of CyanogenMod, one encrypted, and the other non-encrypted, and you setup the boot loader TWRP so that it usually boots the unencrypted one. So, if the unsuspecting guard boots the phone, he'll be able to login and see a perfectly regular OS. But if YOU want to access your confidential files, you reboot the phone into TWRP with the usual key combo, and then you boot into the encrypted instance of the OS. Added bonus: you modify TWRP so that it doesn't even display that encrypted OS in the list of available bootable partitions.

Shortcomings: forensics will show that there is an encrypted partition on the phone... if they ghosted it. But if it is just the guard booting up the phone and nosing around a little bit, you're pretty safe.

Comment Always use a "clean" phone when travelling abroad (Score 1) 319

It's worth repeating ad nauseam: when traveling abroad, always use a new clean phone, i.e. another phone with a new SIM card that is not linked to your Google and other accounts... It's not just the US that seizes or snoops on phones at its borders, foreign countries do so as well. Basically, once they got hold of your phone and take it out of your sight for a couple of minutes, you never know if it hasn't been copied, and bugged. And when you're back home, always assume the phone has been physically tampered with, and make sure to throw it away (or sell it e.g. on eBay to some poor unsuspecting buyer, fair warning would be nice though). Sorry, but that's the way it is.

Slashdot Top Deals

"If John Madden steps outside on February 2, looks down, and doesn't see his feet, we'll have 6 more weeks of Pro football." -- Chuck Newcombe

Working...