chavesn's comments

Right, and how would you further verify “the person paying for your subscription”?

Genuine question, what would that flow look like?

> all of those cases very well justify a manual check, or some sort of extended identification before the user is let in.

Just curious, what would that check look like that's not open to the same vuln?

If oauth makes an authenticity claim, it should be true. Saying it's the same user when it's not is bad, clearly.

in other words: Google could make a more accurate authenticity claim than they currently do.

This problem would be worse without oauth, though, right? With plain email login, all they would need to do is "forgot password" and there wouldn't even be a way to tell.

in other words: Email login would never be able to make a more accurate authenticity claim.

> Failed startups don’t always shut down cleanly like that.

Agreed, and with the number of services and the "ease" of oauth it's likely impossible to even track. You could make a list of the major ones, but there could be hundreds per user, ultimately thousands of unique services used depending on the breadth of the startup's activities.

> NPM stood for "not my problem"

wait...

I think it's more like there's more surface area to forget when you have humans handling so many concerns, and it's not likely the part that's changed the most so it's a likely candidate for being "pushed out of the buffer" (of the human).

In a more typical model, backend devs focus more on security, while not needing to know the frontend, and vice versa.

It seems like that's the point of the story -- they were willing to tip well, and received bad service. If it came after, then drivers would have a reason to make sure food was delivered fast and efficiently.

obviously drivers would want to know it, but is that good for everyone involved? It would make more of an auction but should it even be an auction?

The ligatures are really interesting, but at a glance I process them so much slower than the raw characters, especially the ones that change the graphical semantics such as <= vs ≤. Does anyone have experience getting used to these and 1) does it end up faster? 2) once you are used to it is it harder than it was before to process the raw characters when reading code in fonts that don't have the same ligatures?

Those sans-serif spaces tho...

Keep the same amount of garbage, but make it minimalist garbage

Ok but I can't unsee that the first two say plus plus ("plus+") and the 3rd just says "plus"?

(Very cool project though)

"Hey, this looks like darkpatterns.org. ...oh, it is."

Yeah, but what about "zoom and enhance"? :)

Seriously, sure, 4K is enough for output but who says it's enough for input? As long as sensors keep getting better, the industry will keep finding ways to take advantage of it until it's essentially required.

Imagine a future where you can zoom in on any detail as well as you could with a high-res sensor at capture time?

It's not necessary for today's viewing experiences, but we know little enough about what is going to become popular that I wouldn't put ANY bets on "4K" being enough forever.

All of that statistical analysis was actually a bit silly, because I've never heard the "typo" argument as a reason for email grammar validation[1]. Sounds like a straw man. It didn't need to be disproven.

The conclusion is sound (although leaves out a discussion of the whether an email confirmation field is at least better than nothing).

[1]: (As a side note, I think the most common explanations for grammar validation are programmer perfectionism and proactively stopping user garbage, such as copy-paste errors or intentionally fluffed fields that will result in a bounced email anyway.)

It sounds to me like the point is that the market could be much larger if the transaction value were clear to consumers.

In the current app store, with the methods that consumers are used to spending money on their phones, for whatever reasons, it's not.

It's like when you'll easily spend $30 on drinks on a Friday night, but suffer a shitty note-taking system for years when you could have many of your problems fixed for $5 one time just because you don't know the possible transaction exists.

> To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly.

I certainly hope they aren't interviewing anybody under duress.

I agree with you that this is what the law seems to think (being overly broad), but not if you are arguing this is sensical.

In other words, yes, the WSJ does intend to only give Google access to their content, and not the general public.

But no, the WSJ has not "authorized" Google by anything more official than a bank telling their security guards to let anyone into the vault who is wearing a blue t-shirt.

So yeah, I agree with you, there is a lot of conflation of technical means and the law, but we also shouldn't be granting to the WSJ that they are doing any real "authorizing" here, beyond wishing it and hoping it stays true.

Where did this title come from? Not only is it not the title of the post in question, but it's quite inaccurate -- the article doesn't even come close to claiming that anything "almost killed" the doodle.

With that said, I clicked the click-bait title, and I enjoyed the article. (shrug.)