Hacker News new | past | comments | ask | show | jobs | submit | ashearer's comments login

On the other hand, if they had quietly offered a one-time policy exception before reaching the point of a court verdict, they would have avoided any kind of precedent.


While I can't say how much effect grammar has on thought processes, the metaphors we rely on can be significant. For an example that came up earlier today (https://news.ycombinator.com/item?id=29923866), the term "sanitizing" is often used to mean escaping data. But this way of thinking appears to create a strong urge to "sanitize" as soon as possible, so that the rest of the system will only have to handle "clean" data. This leads to mistakes: data is escaped on input, and therefore tends to be wrong for all but one of several output formats (possibly resulting in security vulnerabilities). And then because data from trusted sources is implied to be "clean", it isn't escaped at all, even when it will wind up being parsed incorrectly. Discarding this metaphor could actually result in better software.


This is an example of why the term "sanitize" just brings confusion and leads to incorrect software. If we say "escape" (for concatenation) or "parameterize" (for discrete arguments) instead, then there's no confusion: we know that it should be done at the point of use, because the procedure for doing so depends on that use.

Calling it "sanitization" implies that the data is somehow dirty, so naturally it should be cleaned as soon as possible, and after that it's safe. But all that accomplishes in general is corrupting the data, often in an unrecoverable way, and then opening up security vulnerabilities because the specific use doesn't happen to exactly match the sanitization done in advance.

It's great to validate the data on input and make it conform to the correct domain of values, but conflating this with output formats and expecting this to take care of downstream security as well just leads to incorrect data along with security vulnerabilities.

PHP's long-ago-removed magic quotes feature was an example of this confusion in action. It not only mangled incoming strings containing single quotes in an effort to prevent SQL injection, but did so in a way that left some databases completely exposed, depending on their quoting syntax.


On Catalina at least, variable-speed constant-pitch playback is still available, just hidden. Option-click on the fast-forward or rewind buttons to access it. It jumps in increments of 0.1x.


Thanks, I didn't know that! It doesn't let you go slower than 1x speed though, which was the useful thing. I used to use it to learn tunes by playing half speed.


macOS is full of things that randomly pop up if you click something while holding a button. That UX is so hilariously bad it makes features hard to find even when you already know they are there!


Good to know that AWS is so fast to detect this.

If good uses were common—and I'm struggling to come up with them—AWS could suppress the alert for IAM users that were already sufficiently locked down. But since that would become dangerous if the permissions were loosened later, AWS would wind up creating two classes of keys, public and non-public, in order to know whether to warn about loosening restrictions. Simpler just to forbid making keys public.

To publish such a key anyway without having to go to the trouble of unwinding an AWS auto-quarantine, breaking it up in code (like "part1" + "part2") might be enough to foil the AWS bot. Can anyone confirm?


It's actually GitHub that contacts AWS even before the commit finishes being sent to GitHub so it is indeed very fast.


Really? If Github is already detecting credentials that reliably, I wonder why they don't just switch repositories to temporarily private and e-mail the account owner themselves...?


Because the key has to be revoked on AWS side, not just removed from the repo. And probably the person pushing to Github and the person paying the AWS bill/the AWS admin are usually not the same..


I don't think they do detection reliably, they have no idea whether it is an actual key or it could be a placeholder used as documentation for example. I don't know the details bit perhaps they just send it to AWS and AWS doesn't tell them whether it is an actual key or not?


Or at least display a confirmation box..


> "Similarly, Uber argued that the industry at large had become more adept since 2014 at protecting private data in the cloud, and that Uber should not be judged for “what a company did then (back when the company was much smaller and the technology at issue was evolving) according to the standards that the agency thinks are appropriate now (given the current sophistication of the company and current industry best practices).” Uber made these arguments via letter in April 2017, approximately five months after the 2016 Breach."

I've been hearing this argument for decades, and every time it's been earnest but transparent blame-shifting. "The industry didn't understand security risks back then." "No one could have predicted this." The risks were well known back then by anyone who cared about risks.


Companies don't give a shit about security until it's too late. Security is a complex beast and I have yet to meet a developer who understands it top to bottom (nor should they but I would expect even juniors to know they should not store creds in the git repo). It's an increasing specialist role that startups rarely hire for because they're focusing on survival and growth so it's to be expected this story will repeat ad nausea.


> Women can handle it in the same way they can handle a cloudy day

Going with that, then why create that cloudy day when it would take very little effort not to?

And what message does it send to actively defend creating those cloudy days?


If a particular test never finds a bug in its lifetime (and isn't used as documentation either), you might as well as not have written it, and the time would be better spent on something else instead--like a new feature or a different test.

Of course, you don't know ahead of time exactly which tests will catch bugs. But given finite time, if one category of test has a higher chance of catching bugs per time spent writing it, you should spend more time writing that kind of test.

Getting back to unit tests: if they frequently need to be rewritten as part of refactoring before they ever catch a bug, the expected value of that kind of test becomes a fraction of what it would be otherwise. It tips the scales in favor of a higher-level test that would catch the same bugs without needing rewrites.


> If a particular test never finds a bug in its lifetime (and isn't used as documentation either), you might as well as not have written it

That's like saying you shouldn't have installed fire alarms because you didn't wind up having a fire. Also, tests can both 1) help you write the code initially and 2) give a sense of security that the code is not failing in certain ways.

> It tips the scales in favor of a higher-level test that would catch the same bugs without needing rewrites.

Writing higher level tests that catch the same bugs as smaller, more focused tests is harder, likely super-linearly harder. In my experience, you get far more value for your time by combining unit, functional, system, and integration tests; rather than sticking to one type because you think it's best.


My comment went on to say that you don't know ahead of time exactly which tests will prove useful. So you can't just skip writing them altogether. They key point is that if you have evidence ahead of time that a whole class of tests will be less useful than another class (because they will need several rewrites to catch a similar set of bugs) that fact should inform where you spend your time.

To go with the fire alarm analogy and exaggerate a little, it would work like this: you could attempt to install and maintain small disposable fire alarms in the refrigerator as well as every closet, drawer, and pillowcase. I'm not sure if these actually exist, but let's say they do. You then have to keep buying new ones since the internal batteries frequently run out. Or, you could deploy that type mainly in higher-value areas where they're particularly useful (near the stove), and otherwise put more time and money in complete room coverage from a few larger fire alarms that feature longer-lasting batteries. Given that you have an alarm for the bedroom as a whole, you absolutely shouldn't waste effort maintaining fire alarms in each pillowcase, and the reason is precisely that they won't ever be useful.

There are side benefits you mentioned to writing unit tests, of course, like helping you write the API initially. There are other ways to get a similar effect, though, and if those provide less benefit during refactoring but you still have to pay the cost of rewriting the tests, that also lowers their expected value.

To avoid misunderstanding, I also advocate a mixture of different types of tests. My comment is that based on the observation that unit tests depending on change-prone internal APIs tend to need more frequent rewrites, that fact should lower their expected value, and therefore affect how the mixture is allocated.


I get what you're saying and it makes sense to me.

> unit tests depending on change-prone internal APIs

This in particular is worth highlighting. I tend to now write unit tests for things that are getting data from one place and passing it another, unless the code is complex enough that I'm worried it might not work or will be hard to maintain. And generally, I try to break out the testable part to a separate function (so it's get data + manipulate (testable) + pass data).


Sorry, that should be "tend to not write".


The same slide also mentioned supporting JIT translation (for x86 web browsers and Java), so Rosetta doesn't run only at installation time.


Even the Joel article makes what's arguably a mistake: he says that input from users is "unsafe" and must be escaped on output, while strings from elsewhere shouldn't. That may avoid security exploits, but it still results in incorrect output when a predefined value really does need to be escaped.

The issue isn't whether a value originated from the user. It's the units/data type, as you said, such as plain text vs. HTML.


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: