I actually like a lot of them, and they've improved a ton since the start in general.

I'm fine with measuring performance, and sometimes tailoring content, but prefer to opt-out of ad targeting and offline matching.

Most all of them are missing proper opt-outs that really should be there, however it's a good start.

Thinking about it, the one I have the most disdain for is The Guardian's; it has a quick UI but the accept-all button is labelled "Yes I'm Happy".

There really aren't many buttons, we've just stopped seeing.

People have also not noticed the thread folding link after it's been there for a while, or the fact that the site has a footer with links. It's difficult to notice things in a grey-on-grey color scheme.

Kafka has a lovely telling of how the Great Wall of China was built:

http://www.kafka-online.info/the-great-wall-of-china.html

This kind of (mis)feature should only be available in the format string, which shouldn't have untrusted user input.

It also "should" only be active if enabled, "should" only be available against explicitly declared target, ... but it isn't.

This vulnerability is equivalent using printf(userData) when you should have done printf("%s", userData). From the perspective of the library developer, the feature is only available in the format string.

Are you sure? Several people here said yesterday that they confirmed it also works when supplied in a parameter.

https://news.ycombinator.com/item?id=29513036

https://news.ycombinator.com/item?id=29507511

Sorry, yes, it's a bug inside log4j, and it's handled even in a parameter.

But the underlying bug is because log4j uses the equivalent of printf(userData).

The log4j maintainers seem to have realized that this (the "%m" in a PatternLayout doing lookups) is a bad idea around version 2.10 (released in 2017) or even version 2.7[2] (released in 2016). These versions both included changes that allowed you to disable this behavior. Unfortunately, the Java compatibility mindset meant that they didn't take the further logical step of making the behavior that disables lookups the default.

I think this vulnerability should be used as a lesson against the vagaries of the classic Java API design issues that we're now finally starting to turn away from. Having an extensible formatting mechanism is not necessary a bad idea, but the problem with this and so many other "magic" features provided by Java libraries is that they are:

* Opt out, instead of opt-in * Hard to discover - if you don't read the ENTIRE log4j documentation (which is pretty large!), it's hard know that this stuff is happening. * Too inclusive - adding JNDI was a bad idea, but even allowing things like environment variables or JMX Beans to be looked-up wholesale from a non-sanitized message is a bad idea.

The problem is much deeper than log4j really. In hindsight, features like JNDI, RMI, and most of all Java Serialization should have never been part of Java in the first place.

[1] LOG4J2-2109: https://issues.apache.org/jira/browse/LOG4J2-2109

[2] LOG4J2-905: https://issues.apache.org/jira/browse/LOG4J2-905

It's absurd but they are parsed from parameters as well.

Both Minecraft servers and clients are vulnerable to chat messages with them.

Rapid chess is almost a different game, shown by how handily Carlsen beat Caruana in the tie breakers.

It's alright, it was 2am afterall.

This probably would have been more appropriate as an Ask HN.

Editorializing the headline like that is a no-go.

Good idea. Please reply here: https://news.ycombinator.com/item?id=29510819 .

Understood. Fixed headline.

Lots of people are getting hung up on the measurement.

The key word is "imagine" y'know.

I can't even imagine the Imagination Quotient required for some social scores.

Yeah I had to reread it a few times, it's just a mistake.

Of course maybe the kid being more accessible to doctors might increase the doctors' utility, but that's not what he meant.