There may be a bit of both at work here, because I remember seeing a lot of issues with hacking the Prius at Defcon[0], but I vaguely recall the SUA incidents being mostly related to as pedal misapplication.
I know Wikipedia isn't exactly a great primary source here, but:
> From 2002 to 2009 there were many defect petitions made to the NHTSA regarding unintended acceleration in Toyota and Lexus vehicles, but many of them were determined to be caused by pedal misapplication, and the NHTSA noted that there was no statistical significance showing that Toyota vehicles had more SUA incidents than other manufacturers.
In any case, I believe companies can definitely be guilty of criminal negligence (and Toyota did a lot of bad things during their SUA crisis). But I think the use of SUA in the comment I originally responded to sort of misrepresents the situation and mostly spreads a lot of FUD around self-driving cars.
I thought the unintended acceleration issues had been largely disproven as user error.
That is, many other brands of cars had been reported to have the same issues by drivers. And basically a driver was put into a stressful situation, thought they were hitting the brakes, but were actually hitting the gas. Then, panicking that they can't stop the car, hit the "brakes" harder, exacerbating the problem.
The idea of exclusively using only a few applications definitely seems limiting. I understand in this case it's probably because of licensing and morals, but I can't imagine many businesses caring much about your principles on software licenses when everyone's passing around their ".sketch" files.
From what I can tell, this is a useful first step towards credential stuffing.
Requests against endpoints like this are going to be unauthenticated, since by their very nature they happen before the user is actually authenticated against the system. So you can burn through a few thousand (or hundred thousand) possibles and find out which ones actually have accounts.
From there, you can use one of many other email/password dumps and try authenticating. Hitting an endpoint where you can use an email and password is (hopefully) going to be much more guarded and will start blocking IPs when the rate or variance is too high.
That being said, I don't really know how you can stop the first step. There are plenty of answers here that say you should just let them "sign up" and then send them an email if they already have an account. But what happens if your signup process includes something like accepting payment? Obviously you don't want the user filling out all of that information again.
With as many accounts on these services that actually exist, it still doesn't answer the question of whether or not the person actually owns the email.
A corporation has no freedom of speech rights. It's important to remember that a corporation is not considered to the same rights as a person in these cases, nor should they ever be allowed to be.
A bit unrelated, but it's weird that Medium doesn't seem to support embedded code, and instead only seems to work with gists.
It made the mobile experience pretty bad (all I get are links to the gists) and it would definitely "pollute" my gist history with a lot of little code snippets.
On the note of the topic itself, though, this was a fun read for building fractals in JavaScript!
Instead of two things, you just need one. They're saying that instead of a USB-A-to-Lightning cable and a USB-A-to-USB-C adapter, you can just use the one cable.
You don't even need to rebind the escape key. I've been using ^[ for years, and it works in basically all standard terminals and vims as the escape key.
This is less safe than the branching alternatives. Instead of "moving" the original commit, this copies the original commit to a new one and leaves the original one dangling and waiting to be garbage collected.
Also, if you have more than one commit before you noticed you were on the wrong branch, this only grabs the one commit.
I'm unhappy with the approval process being a simple search for "LGTM". I wish GitHub pull requests had actual support for a review process, e.g.:
* open issues to address
* review state, such as "changes requested" or "approved" (along with users that are in each state).
We've been using Phabricator's[1] Differential tool for code reviews and it feels superior to this process, but it would certainly be nice to have an all-encompassing solution for this.
Came here to say exactly this. Most stats should probably either treat 3XX as "success" or follow the link to figure out what the next location's status is.
What is the correct way to force a link to open in a new tab, then?
Unfortunately "let the user decide" is not the best answer if you want to link to something like "terms and conditions" in the middle of a sign up flow or something. If the user doesn't know how to open it in a new tab on their own, this can be extremely frustrating I'd imagine.
This looks pretty interesting. It does require the structure of the HTML to be very similar to the object, though. And I'm not thrilled that is uses the class name for a DOM node in the key/value pair. Why not define some "data-" attribute to read from?
EDIT: Looks like I posted without reading all of the comments in regards to the class name thing. I see some other people have mentioned it as well. It also looks like the author states that this isn't a hard requirement. I guess that would solve that problem at least.