Forgot your password?
typodupeerror

Comment: Re:Good idea for tickets (Score 1) 72

by JoshRosenbaum (#45596979) Attached to: Yota Phone Launches With Secondary E-Ink Display

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.

Comment: Re:Disable is disabled (Score 1) 201

by JoshRosenbaum (#45357347) Attached to: Protect Your Android Phone By Killing All Its Crapware

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.

Comment: Re:What the hell is "left open"? (Score 4, Insightful) 210

by JoshRosenbaum (#44912473) Attached to: LinkedIn Accused of Hacking Customers' E-Mails To Slurp Up Contacts

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.

Comment: Re:What the hell is "left open"? (Score 1) 210

by JoshRosenbaum (#44912433) Attached to: LinkedIn Accused of Hacking Customers' E-Mails To Slurp Up Contacts

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.

Comment: Re:Fr0sty Bin laden p1ss (Score 3, Interesting) 362

by JoshRosenbaum (#44810135) Attached to: Syrian Gov't Agrees To Russian Chem-Weapon Turnover Plan

I saw an article today that suggests that this may have actually came up at the G20:

http://worldnews.nbcnews.com/_news/2013/09/10/20416189-obama-agrees-to-un-discussion-of-russia-proposal-on-syria-chemical-weapons?lite

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.

Comment: Re:This is also the case on Firefox (Score 1) 482

by JoshRosenbaum (#44501479) Attached to: Chrome's Insane Password Security Strategy

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.)

Comment: Re:This is also the case on Firefox (Score 2) 482

by JoshRosenbaum (#44500813) Attached to: Chrome's Insane Password Security Strategy

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.

Comment: Re:This is also the case on Firefox (Score 1) 482

by JoshRosenbaum (#44499699) Attached to: Chrome's Insane Password Security Strategy

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.)

Comment: Re:OS? (Score 1) 227

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: /FFT :: assume FAT File Times (2-second granularity). /DST :: compensate for one-hour DST time differences.

That seems lame it isn't handled automatically by default with an option to switch it off.

Comment: Re:OS? (Score 1) 227

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?

Whatever is not nailed down is mine. Whatever I can pry up is not nailed down. -- Collis P. Huntingdon, railroad tycoon

Working...