Misunderstood Indexing
Holding the number-one spot on Corruption Perceptions Index tells nothing about how well a country is doing.
It merely highlights how bad the situation is even for the runner-up.
Holding the number-one spot on Corruption Perceptions Index tells nothing about how well a country is doing.
It merely highlights how bad the situation is even for the runner-up.
The following is an edit of a piece originally written in November 2015.
The pinnacle of non-intrusive online ads were the original Google search ads. They were out of the way, clearly marked as ads - and hence could be visually filtered out. They were pure text, so could be neatly included as elements on the rendered page. And they were always targeting an INTEREST. Not an individual.
I will take that as the minimum acceptable advertising behaviour. I'm not implying it's perfect, but at least we set a clear set of ground rules. With that in mind, my ideal, non-intrusive ads mechanism builds on the following rules:
Breaking even one of the rules automatically disqualifies you.
If you, as an advertiser, find these rules unacceptable - well, then we are in mutual disagreement. I find your ads equally unacceptable and will treat them as a form of cancer.
However, as a genuine service to the user... please allow the users to search for ads that have been displayed to them. Preferably by display context. I would be glad to return to a subject at a later date and search for something I remember seeing earlier.
The above set of rules is still not ideal, but everything that behaved according to them would at least be palatable.
Software is like a diamond ...
... the better it glistens, the more edges there are.
... the toughest substance on planet, yet can shatter from a single impact.
... creating one can destroy your tools.
... no matter how well it wears, it'll still burn.
So I wrote another one at work. After explaining to various parties how and why password cracking attempts happen, I felt it was prudent to write the whole thing down for future reference outside the corporate walls.
With that in mind, your passwords have almost certainly been compromised
TL;DR: use high-entropy passwords, a password manager, and proper 2-Factor authentication.
Faithful to habits, I found myself with a presentation at dc4420. Lessons of usability and search for sanity gave rise to a talk on how deal with conflicting auditing demands.
The talk was geared towards industry long-timers who have, for reasons only marginally in their control, found themselves appeasing externalities and ticking boxes. I wanted to highlight that hope is not lost.
You can find the slides here: Intended Consequences
When things break in mysterious ways, developers tend to go through a familiar series of increasingly demanding steps. As experience, skills and even personal networks grow, we can find ourselves diving ever further in the following chain:
How far have you found yourself?
A few days ago I posted a long-in-the-making article about the common engineering problems and constant challenges at the $dayjob blog. There are a number of repeating themes and questions that come up when doing interviews, so I figured I might as well answer them all in one place, and with sufficient detail.
After all, why not?
I gave a surprisingly long presentation in April at the dc4420 monthly event. What was supposed to be at most 40'ish minutes followed by short Q&A ended up taking more than an hour thanks to lively discussion during the different segments.
This was an overview of infrastructural design constraints for a betting exchange, especially focused on finding practical ways to address the regulatory demands. At the cross-section between gambling and FinTech the environment comes with some fairly unique externally imposed requirements.
The slides are a revised version of the presentation material, designed as better suited for distribution.
You can find the slides here: Infrastructure Design for the Professionally Paranoid
I gave a short presentation in October at the dc4420 monthly event. The talk was about the simple theory and practice behind hash extension attacks.
You can find the slides here: size_t Does Matter
Well that was unexpected. BBC just quoted me.