fidget

I guess the idea is that points should correlate to time (questionable), and if you're estimating perfectly, that should give you a linear burndown graph. Which is stupid. What might be less stupid is that if you want to get some idea of how well your team is estimating tasks, compared to i.e. this time last year, you could look at the volatility (across several sprints) this year compared to last year, and a lower burndown rate volatility might suggest that the team has improved at estimating the duration of tasks.

However, when you just focus on the volatility as a metric, then people start optimizing for it, which is not the point at all.

As for using the correct key, dismantle the signal message envelope until you get your blob of encrypted message. Then see if the same blob appears on the target device. Multiple keys? I imagine either correlating message size and network traffic (encrypting stuff twice could well show up), or going at it with a debugger.

Which is really the answer to all of these questions instead of any network shenanigans. You root your phone and attach a debugger, then step through what signal is doing.

Not a security researcher, never reverse engineered anything for security reasons in my life.

How about his entire socialisation?

> I repeat: Your alerts and dashboards belong into your SCM, not a random SQL database!

(And I 100% agree, particularly for alerts)

Eww