ashearer

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.

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?

"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.

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?

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.

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.

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

Yes, I completely agree in the above case. The JSON input has a well-defined format and input validation should reject it outright.

The issue is that when developers hear they should "reject bad input" in order to avoid vulnerabilities, they often interpret it as a call to reject any user input that isn't already known to be good. Since user inputs are often free text, like the name field, they wind up forbidding any input they hadn't specifically imagined, which doesn't align with any particular recipient's actual data requirement. It creates false-negative edge cases while only providing illusory help against vulnerabilities.

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.

The difference is where it's done. "Sanitizing the input" implies that it happens when the value is read, so that all uses of the value are stuck with a single result. "Escaping the output", in your example, would happen in the database or its driver, for parameterized queries. HTML output of the same value in the same request would be escaped differently within a function that builds HTML output.

This sounds good in theory, but I'll give a counterexample.

Requirement: Name input box.

Implementation: We'll sanitize the input by rejecting any characters likely to be dangerous if mishandled, like single quotes, or anything else we don't immediately imagine to be useful. If a character turns out to be needed later, that's no problem. We'll just change the list.

Security audit: Passes

Later customer complaint: I can't sign up! — J. O'Brien

Dev team: Sorry, too bad. We'd have to re-audit everything and possibly modify code to allow your last name, because there might be code somewhere that relies on the original sanitization for security. That was the point of sanitizing on input, after all. If you want to sign up, it would be easiest for us if you would just change your name.

Yes. It's the word "sanitize" itself that misleads people. It creates the mindset that input from users is dirty and must be made clean, and "clean" is "safe" to use in any context.

(I've seen the line of thought taken one step further: taking the realization that it's impractical to make strings universally safe for any context—even if you HTML entity-encode it twice, what if a recipient decodes it three times?—and concluding that security is hard and we can only approach it asymptotically, so shrugs XSS-like bugs are normal and unavoidable given finite time & budget.)

If the mindset is more like converting units, it becomes clearer. You can't concatenate HTML with a general Unicode string without converting the string to HTML first, any more than you can add inches and centimeters directly. "Cleaning" the centimeters would make no sense.

It looks like a general optimization for tail-recursive functions that assumes they terminate (because not terminating would be undefined behavior). The parameters to the recursive calls don't matter: Substitute other expressions or constants for `n / 2` and `3 * n + 1`, and the compiled result remains the same. So it's not Collatz-specific.

clang appears to correctly detect that `collatz` only directly defines a result for `1`, and any other input expands to yet another recursive call to `collatz` (the parameter is irrelevant). To avoid infinite recursion, `collatz` must eventually be called with the value 1, so that's what clang concludes.

Measuring "per participation decision" often makes more sense than "per participation hour" when deciding whether to do an activity. (It could be shortened to "per event", defining an "event" to be the result of one decision.)

In explaining the choice of per-hour, the author gave the example of choosing either an afternoon riding a mountain bike or an afternoon flying a sailplane. The example works because they involve about the same number of hours. But it's also the same number of decisions, so per-event works just as well there.

Per-event fixes distortions for quick activities, where durations are meaningless because they're dominated by setup time that isn't counted (or alternatively, the risk varies by multiple orders of magnitude depending on whether you count the overhead).

The chart shows summiting Everest as being 100x safer than base jumping. But if you're deciding which activity to do, it's more relevant to compare risk per-summit to risk per-jump-trip (say, 5 jumps?) or even risk per-jump, since you can calibrate the number of jumps on your trip based on your risk tolerance, but you can't do a fractional summit.

Using the author's numbers, jumping has a risk of 0.13% per jump, or 0.67% for a trip with 5 jumps. Everest has a risk of 6.5%. So in terms more relevant to decision-making, a decision to summit Everest comes with a 10x higher risk of death than a decision to go base jumping, instead of 100x lower as the chart might lead you to think.

Immediately below that, the final Excel output is unreadable: it shows the left axis scale ending at 450 and right axis scale ending at 400, with both values corresponding to the same grid line.

Below that, it says you can draw these charts in JavaScript with a <chart> element, as if browsers natively supported it.

One approach that works very well is to keep stored functions in separate .sql files in a directory (I use "fixtures"), and execute them all on each deployment. This should happen after triggering migrations, so that table and column dependencies are guaranteed to be present. The .sql files use CREATE OR REPLACE FUNCTION so that their execution is idempotent.

This keeps the stored functions version-controlled along with the source code, and avoids any need to hunt through migration files to find the latest definition. Adding a stored function or modifying its function body just works.

The less common operations of deleting a function or modifying its argument list do require an explicit line in a migration file, but those situations are rare (and potentially backward-incompatible, requiring extra caution regardless).

One subtlety is that a migration that adds a new table with a trigger should define an empty stub function as the trigger. This avoids duplicating code. The real function body will be loaded from the fixture immediately afterwards.

Then it would become impossible to store future timestamps in a database and have a stable answer to the question, "on what day will this timestamp occur?" Timestamps around midnight could flip from one day to another unpredictably depending on what version of the leap second database the formatter has. And that wouldn't just affect the leap second day, it would affect every day of every year. That would cause problems for many fields where calendar dates matter (legal and accounting, to name a couple). I expect we'd wind up avoiding the problem by saving dates internally as formatted UTC strings, and be back where we started.

YouTube link: https://www.youtube.com/watch?v=9A92PMGcquo

It's the electric company charging different rates depending on the brands of your appliances (even if they use the same amount of electricity). They can also charge the brands themselves for good placement on this list. And they have their own private brand, which gets the lowest tier of rates. They initially present this as a special discount, and raise the price of everything else later to compensate.

Please illuminate me. I may be wrong, but I certainly wasn't being dishonest. The fact that you leaped straight to that conclusion doesn't help convince me that you have a particularly well-grounded belief in the NYT's dishonesty, either.

That's the question then--is it the case that any rational interpretation of the polls gave an actual forecast of least 70%, and the NYT lied? The parent seemed to be saying that election's outcome alone proved that the 20% number was not only wrong, but dishonest on top of it. You need some more ingredients to prove either of those things, though.

This is why I don't get usually get involved in political discussions online. Someone who's committed to a position can always bring up new questions instead of responding to the original ones. (In this case I wasn't even taking a position, just pointing out where I found the logical reasoning unconvincing.) While both the new points you raise are open to debate, they shift the topic away from the two I was talking about. If I respond further we could be here forever.

The page itself is set in the proportional version of Go. I found it distracting to read because of the uneven character widths. The majority of the characters (like 'b', 'd', 'f', 'k', 'l', 'o', and 't') are narrow, but some common letters (mainly the 'e' and 'c') are round and wide, with generous space around them. I can't get past the impression that I'm reading paper that wrinkled when it went through the printer. Even the name "Go" has a wide G, awkwardly large space, and narrow "o". Perhaps it's an artifact of the browser rendering, because it's less noticeable on the alphabet sample image.

The monospaced example reminds me of TeX-produced CS papers at first glance. I'll have to give it some time.

If they predict a 20% chance of rain, and it does rain, that doesn't show dishonesty.

The second point needs a citation.

I appreciate the effort to define a fast subset of HTML, but the AMP loader on google.com makes the whole page-loading experience different and worse in many ways. Several times today while trying to visit different sites, the AMP JS loader has broken down, displaying only the Google address bar, a fake AMP address bar below it with the intended URL, and a multicolored Android-style circle spinning endlessly (on an iPhone). All the native browser controls for page lifecycle (including timeouts and Reload button) were completely ineffective. It's important for the loader to get its replacement for these things right if it's going to try to supplant the browser's built-in functionality, and it currently doesn't succeed at that.

None of GP's points would necessarily absolve a suggestible accomplice of a crime that actually occurred. The FBI's cases, on the other hand, were entirely fictitious except for the suggestible person.

It would certainly be a strong case if a suspect had actively sought the final ingredients of a self-planned act of terror, which would have killed people had the FBI not responded to the call first with fake equipment. But the objection in these cases is that when you subtract the FBI-provided motivation, plans, and equipment, all that's left are the person's own suggestibility and weak moral compass. Those don't constitute a criminal act in themselves. Experts could argue that they aren't likely to have ever resulted in one.

The religious targeting aspect is even more unfair. As far as I know, the FBI isn't spending similar time and resources to identify disaffected and suggestible non-Muslims, and then convincing them of the glory and honor awaiting them if only they would help push a button to bomb a local mosque.

Edit: In the above example, the "predictably persuadable" person isn't criminally responsible for murder if the ride was given to an FBI agent, and there was no actual robbery or murder.

It's almost certainly correct that they use the Keychain for Touch ID. But I'd hedge that if they were bent on being insecure, they could use a different Touch ID mode that just returns a boolean. Does anyone know whether app review examines which mode they choose?