Listen to this. I work at ZipRecruiter and it is great. I can't say enough good things about it. I'd recommend it to all developers, but experienced Perl/Python developers definitely have a leg up. Make sure to brush up on your interview skills a little as it's never fun to go into those blind.
You sure the dvds were 18 years old? I'm not sure there were even consumer dvd writers available around 1996. Perhaps you meant cds?
I actually had really good luck with my burned cds from around 1998 or so. I was able to read all the data off of them recently. A couple had to slow down a bit to be read, though, so there must have been some sort of degradation. Wonder if it could be more related to the burner you used or maybe the reader you used to try to read them? (Also, I can suggest ddrescue for recovering from cds/dvds if needed. It came in handy when I was recovering a scratched cd with info on it that I really wanted. I used it over and over with a couple of different readers to get a complete image of the data.)
Your hard drive suggestion sounds exactly like what I use. All the data I've read from old cds/dvds I now store on hard drives. I use SnapRaid to create a couple of parity disks. (So I can recover from up to two disks failing. Plus, since it isn't online raid, I can fix deletions and other problems as well.) I occasionally backup onto external hard drives utilizing SnapRaid again and then store them in a firesafe at another location.
Not sure if these are the same thing. If it is, then it's sad this knowledge isn't more common place to help people out.
Well if we're gonna get technical, you just calculated pixels per dollar whereas he was calculating dollars per pixel. Switch your numbers around:
3000 dollars / 8294400 pixels = 0.00036 dollars per pixel
So technically he is still right. It is less than a dollar per pixel.
Snapraid (free!) might be an option: http://snapraid.sourceforge.net/
It snapshots your data to some parity files on a separate drive. All you would have to do is occasionally copy those files offsite. Snapraid includes commands that allows you to check and fix bitrot as well.
I've used barcodes on my phone at the theater multiple times just fine and I haven't messed with my brightness settings on my phone. The one time I saw that it didn't work, the guy said he tried to scan it in the wrong part of ordering, so nothing was happening. He started the transaction over and it scanned fine. I wouldn't be surprised if some people have phones with weird screens or screen protectors that mess with the reading of the barcode, though.
On my Verizon Galaxy S3 I rooted and installed BoneStock ROM. I chose this over Cyanogenmod, because it is mostly the stock ROM with lots of tweaks. Since it is basically the stock ROM, you don't lose any features and have less chance of bugs. (For example: No losing your camera.) However, it allows you to pick pretty much everything you want to install on the device and re-enables base features disabled by Verizon. (Wifi tethering for example.) I unselected most of the Verizon bloat along with many Samsung features I did not need. Makes me feel warm and fuzzy inside not having all that bloatware. The features list is huge too. Check out the link below to find all you can do with the ROM.
The BoneStock ROM can be found here: http://forum.xda-developers.com/showthread.php?t=2275376
The xda-developers forum has all sorts of ROMs and root methods, so be sure to navigate to your correct subforum and see all the different ROMs and root methods you can use.
I'd say it's more likely that one of your friends is allowing Facebook to scrape their email account and you are getting associated in that way. There's no need for them to hack your account when they can get all that data from someone else. No matter how much we try to keep our privacy, it's easily destroyed when one of our connections gives up all their data.
They tried using people's linkedin passwords for their email accounts,
Which would require clear text storage of LinkedIn passwords. In 2012 when there was a compromise, LinkedIn claimed that they stored an unsalted hash.
Not necessarily. When the user creates an account or anytime the user logged in LinkedIn could use the password they received to do the email login. It doesn't matter that the password is stored as a hash.
I saw an article today that suggests that this may have actually came up at the G20:
In a further development, a spokesman for Putin said the Russian president had discussed the weapons handover plan with Obama at last week’s G-20 summit.
Firefox certainly gets props for going beyond that, except for 3 things:
A) a re-implementation of a keychain outside of the OS opens additional potential security issues. Generally the OS's keychain security will have more eyes / devs looking at it than Firefox's.
B) 99% of users dont use the master password mechanism
C) once the keychain is unlocked, whether it is the OS keychain or firefox's, any program can access it.
A) Can't argue with this. However, there is guaranteed always on access to Chrome password store while there is not with master password encrypted Firefox store. (While logged in of course. Which is almost always the case for attacks.)
B) I agree, but that doesn't mean there isn't extra security for the 1%. The code change to add it would be pretty insignificant and wouldn't need to inconvenience users who don't want it. One could argue this is exactly what extensions are for and I could agree with that. I believe there are some for Chrome/Firefox that utilize Keepass for example. At the same time I believe the Firefox master password is opt-in, which can explain the low uptake.
C) Yes, but it's not always guaranteed that the attack will happen when the master password keychain is unlocked or that it will be an ongoing attack. That means this is a security risk mitigation. I'm fine with that.
Only if the attacker is already running arbitrary code with access to the userdata, in which case youre screwed anyways. Such an attacker could simply log keypresses, or wait in the background for firefox's keystore to unlock, he has full access. Trying to defend against arbitrary code running in the user context is really not in the scope of what a browser should be doing.
Yeah, I said as much in my original post. However, there is no guarantee the attacker will wait around (or be around) long enough to keylog. (Might be a hit/run or the user/antivirus might detect something and stop activity.)
This seems to be a classic philosophical debate of ideal security vs realistic security. I understand the ideal security side of this, but I prefer to mitigate risk as much as possible. Luckily we have choices that fit our various needs out there. (Firefox with/without master password. Chrome/Firefox with extensions to add Keepass or other password support. Or just utilizing the OS keychain.)
If you care so little about security that you don't secure your user account, I doubt you care enough about security to worry about your other credentials.
Stupid is as stupid does, as they say.
The problem with this is that it is very short-sighted. There is no 100% effective way to secure an account other than to not use it or to keep it disconnected from networks and away from other users. That may be an acceptable risk for you, but I prefer having another layer of protection.
You need the user's Windows account credentials to decrypt the passwords.
Have you ever seen a user using a Windows machine that isn't logged in? That means there is basically constant access to Chrome passwords. I'd prefer to have the option of a separate master password for my browser like Firefox does. It's not like it would even be that hard for Chrome to implement, so I'm not sure why there is such a struggle to add it. (Could be a hidden advanced feature even.) Are there scenarios where an attacker could get the master password? Yes, of course, but with the current system they are guaranteed access. Are there scenarios where they could not get the master password? Absolutely.
I'd prefer to minimize my security risk. I'm not proposing that you are forced into the same master password system, merely that I have the option to choose it. (Which I currently do by using Firefox.)
Hmm, that's good to know that I should watch out for this if using FAT. I pretty much only use NTFS these days, so this is not something I've ever noted.
I checked out the options in robocopy and I wonder if one of these two would fix this issue:
That seems lame it isn't handled automatically by default with an option to switch it off.