You're wrong about LinkedIn, it's not the users, it's you
1–10 of 23 posts
Re: You're wrong about LinkedIn, it's not the users, it's you
#2Makes a fairly interesting point that seems obvious once you've read it, but which we actually don't have embedded as an assumption - that the level of user trust placed in us as developers is not matched by the level of care and responsibility which we actually feel when that trust is placed in us. Definitely some food for thought, and I think we need to take the entire issue much more seriously rather than just slapping anything together and forgetting about it.
Re: You're wrong about LinkedIn, it's not the users, it's you
#3Makes a fairly interesting point that seems obvious once you've read it, but which we actually don't have embedded as an assumption - that the level of user trust placed in us as developers is not matched by the level of care and responsibility which we actually feel when that trust is placed in us. Definitely some food for thought, and I think we need to take the entire issue much more seriously rather than just sla…
What is the interesting point? That users should place a foolhardy, ridiculous level of trust in developers and processes that they don't know and have no insight into?
Re: You're wrong about LinkedIn, it's not the users, it's you
#4I agree with the article's premise, but the user does need to be educated about the risks at the same time. We can enforce some degree of password strength, but we can't keep the user from reusing the same password. If we could guarantee that their password would never be exposed, that would be fine but I'm never going to make that guarantee.
I can be diligent and yet one mistake can still expose the user's (hopefully salted and hashed) password. If there is a financial impetus for someone to find my mistake, they will spend the time looking.
As a side note, I'd love to hear how the hackers came to be in possession of 6.5MM LinkedIn passwords ... what mistake was made that allowed them to collect unsalted hashes in the first place?
Re: You're wrong about LinkedIn, it's not the users, it's you
#5I agree with the article's premise, but the user does need to be educated about the risks at the same time. We can enforce some degree of password strength, but we can't keep the user from reusing the same password. If we could guarantee that their password would never be exposed, that would be fine but I'm never going to make that guarantee. I can be diligent and yet one mistake can still expose the user's (hopefull…
I keep hearing about these mysterious hackers. My gut feeling is that with these really big ones that we hear about, its more likely to be some kind of insider threat that they will do everything they can to hide. Blaming "them" with no details at all, seems really sketchy to me.
Re: You're wrong about LinkedIn, it's not the users, it's you
#6The point about insiders is often overlooked but just as plausible as an outright hack. A rogue sys-admin or coder who is trusted and has access to file-systems and DBs can leak or sell data and might even get away with it without ever being caught.
Re: You're wrong about LinkedIn, it's not the users, it's you
#7Makes a fairly interesting point that seems obvious once you've read it, but which we actually don't have embedded as an assumption - that the level of user trust placed in us as developers is not matched by the level of care and responsibility which we actually feel when that trust is placed in us. Definitely some food for thought, and I think we need to take the entire issue much more seriously rather than just sla…
What is the interesting point? That users should place a foolhardy, ridiculous level of trust in developers and processes that they don't know and have no insight into?
I don't know what it takes to build a lot of things, but I trust that the engineers will do a good job. I see no difference with software.
I've always found it odd that SWEs can harbor this type of opinion. That is, "it's the user's fault for trusting me/us." when every other engineering discipline would consider such a stance insane. All other disciplines would place responsibility directly on the engineering team. Whether a plane falls out of sky, a car explodes when rear ended, a bridge collapses, a chemical causes cancer, or an oven electrocutes the user, in all cases we'd point the finger at the engineers (or company that performed said engineering) and demand an explanation. I see no difference here.
Full disclosure: This is coming from someone who was originally studying to be a ChemE before switching to comp-sci.
Re: You're wrong about LinkedIn, it's not the users, it's you
#8The point about insiders is often overlooked but just as plausible as an outright hack. A rogue sys-admin or coder who is trusted and has access to file-systems and DBs can leak or sell data and might even get away with it without ever being caught.
I imagine there's all sorts of motivation for this too. A dishonest security admin or consultant for LinkedIn might have had no traction in convincing managers that they should pay him to upgrade the security system. I can see rogue programmers contriving leaks like this just to give themselves more work.
Re: You're wrong about LinkedIn, it's not the users, it's you
#9The point about insiders is often overlooked but just as plausible as an outright hack. A rogue sys-admin or coder who is trusted and has access to file-systems and DBs can leak or sell data and might even get away with it without ever being caught.
[deleted]
Re: You're wrong about LinkedIn, it's not the users, it's you
#10Earlier quoted context omitted.
What is the interesting point? That users should place a foolhardy, ridiculous level of trust in developers and processes that they don't know and have no insight into?
I don't know what it takes to build a lot of things, but I trust that the engineers will do a good job. I see no difference with software. I've always found it odd that SWEs can harbor this type of opinion. That is, "it's the user's fault for trusting me/us." when every other engineering discipline would consider such a stance insane. All other disciplines would place responsibility directly on the engineering team.…
It might be interesting to point out that in all the examples you give there exist strong regulatory requirements. Are you (we, collectively) saying that regulations and government oversight should be on the table for web sites that provide services requiring a certain level of security?