It isn't about believing your government is moral or good. Its about understanding that your government is responsible for the safety of citizens, and that your enemies will want to kill you (or at least kill your soldiers).
2,085 karma · joined October 31, 2014
It isn't about believing your government is moral or good. Its about understanding that your government is responsible for the safety of citizens, and that your enemies will want to kill you (or at least kill your soldiers).
Export controls are there to prevent killing machines getting in the hands of a countries enemies (or potential enemies in the future)
The government shouldn't be forced to buy any type of military technology someone creates. But even if the government won't buy your tech, it still can be dangerous in the hands of other countries.
One could argue that if the government is preventing you from selling your tech abroad - there should be some sort of compensation for this. Others could argue that's just the cost of being in the business of weapons manufacturing.
While its always great for your career to be in a company that's constantly growing - sometimes being that person that can help the company do a lot more with less resources is even better for your career. When everyone's jumping ship - the people who choose to stay on-board can often be very rewarded as far as their career growth goes.
If a service has an outage and a company posts a postmortem, we all think: "wow! that was an interesting bug, lets learn from this". We shouldn't be treating security issues differently.
People who make security mistakes aren't idiots. They aren't negligent. They're engineers just like us, who have tight deadlines, blindspots and mistakes. Shaming people and companies for security bugs will only cause less transparency and less sharing of information - making us all less secure.
This is a really cool bug. Kudos to the researcher for finding it, responsibly reporting it, and to paypal for fixing it in a timely fashion. Hopefully - this type of bug changes some internal processes and the way the company thinks about 2FA.
As for security questions - these are obviously insecure, and should really never be relied on. If you can opt out of security questions - do so. If you can't - just generate a random password as the answer. "I_ty/:QWuCllV?'6ILs`O12kl;d0-`1" is an excellent name for your first dog / high school. Just don't forget to use a password manager to store these.
if ((isset($_POST["SecurityQuestion0"]) && $_POST["SecurityQuestion0"] != $answer0) ||
(isset($_POST["SecurityQuestion1"]) && $_POST["SecurityQuestion1"] != $answer1)For SF to justify extensive subway infrastructure, it needs to start building higher density neighborhoods.
Imagine:
Alice generates a link.
Sends the link to Bob over an unencrypted/unauthenticated link.
Mallory intercepts the link. Generates his own link and send that link to bob.
Bob enters the confidential information on Mallory's link.
Mallory sees the confidential information, and then sends it to Alice's original link.
The only way to prevent this type of attack is sending the link over a secure channel. But if you already have a secure channel - what's the use case?That's actually very lazy. It's shifting the burden of "drawing the line" on the other side.
It's the "well, why don't we just kill toddlers as well? Where do you draw the line?" in an abortion argument. It's the "why don't we just give 12 year old's automatic assault weapons" or "why don't we disarm the police and military as well" in a gun control debate. It's the "So why don't we just tax corporations 100% of their income" in a corporate tax debate.
Lets say you have a lot of single byte opcodes:
40 INC EAX
43 INC EBX
41 INC ECX
C3 RET
And you want to set a breakpoint on INC EAX.
If you replace "40" with "CD03" - you'll overwrite INC EBX as well.
That can cause your program to crash if there are control flows that end up jumping to INC EBX without going through INC EAX first.That's the main reason why 0xCD, 0x03 isn't used.
While a lot of tech is rapidly moving and constantly changing - this is the type of fundamental knowledge that will probably prove valuable for the rest of your career.
This makes setting a breakpoint really easy, as all you have to do is replace a single byte (and restore a single byte) where you want to place your breakpoint. INT 3 being only one byte is also important when you're setting a breakpoint instead of a another single byte instruction - your newly set breakpoint won't override the consecutive instruction, which might be jumped to somewhere else in the code.
Most times the toll roads also have to compete with "free roads", limiting the amount of money you can charge per ride. http://reasonrail.blogspot.co.il/2011/06/do-toll-roads-make-...
A programmer working at a large internet company may be impacting millions upon millions of people. Building a feature that lets you collect (or save) a penny from a user every month is worth $240K a year when spread out over 2 million users. $120M when spread out over 1 billion users.
That's really my answer to the common question at the end of the post: "I don’t understand this at all and would love to hear a compelling theory for why programming “should” pay more than other similar fields, or why it should pay as much as fields that have much higher barriers to entry."
AWS is built by developers for developers as well.
Most of the complaints here about AWS aren't actually about AWS not being "for developers", but about AWS requiring a certain learning curve.
It's a perfect trade-off between power and flexibility vs agility.
Reverse engineering isn't inherently good or bad, it's just a tool. That tool can be used for both good and bad.
I always recommend certificate pinning in order to prevent MITM attacks. I also recommend it if you're backend API gives out a lot of information about your product's "secret ingredient".
That said - certificate pinning can often be bypassed: http://blog.dewhurstsecurity.com/2015/11/10/mobile-security-...