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.
Robocopy doesn't keep the ACM dates across volumes. So it is certainly not a 1:1 copy.
Maybe I'm misunderstanding you, but robocopy does keep dates across volumes. You can also control whether or not you want to copy them. File times are copied by default and for directory you add the DCOPY:T parameter. Are you speaking of some other underlying file system date?
That number is over 3 years according to the summary, so you need to divide by 3.