srctree

Gregory Mullen parent 324ccbff ade91771
rename do-less article

inlinesplit
filename was Deleted added: 81, removed: 70, total 11
@@ -0,0 +1,79 @@
+++
layout = "post"
title = "Do less"
date = 2019-06-22
lastmod = 2023-02-08
tags = ["security", "code", "old-man"]
+++
 
I have a strange take on YAGNI. You should do less, write less code, consume and
produce less data, instead of being a **10×** dev, be a **10÷**
developer. Now, that may be a bit misleading, because I don't want to suggest
you should want to be, *just a software developer*. Really what I'm getting at
is that I think you should try to channel the ideals of what it is to be an
engineer. It may seem to be simply a linguistic difference, but I think it's a
pretty important semantic difference as well as being an important one.
Developers write a lot of software, implementing new features left and right.
New +100 line commits daily. Some of the best ideas I've seen come from people
who are happy to be a developer, and they're ones that I easily respect. The
critical difference, (at least for the remainder of this rant,) is that
developers are the ones to omit possibly the defining engineering maxim.
 
> *Perfection is achieved, not when there is nothing more to add, but when
> there is nothing left to take away.* -- [Antoine de Saint-Exupéry](https://en.wikipedia.org/wiki/Antoine_de_Saint-Exup%C3%A9ry)
 
 
You should apply that ideal to every single line of code, every import/include,
every decision, every packet, every expectation, every **thing**! This is the CS
equivalent of spending 5 of your 6 hours, sharpening the ax.
 
It's trivially annoying when I come across needless cruft, but it's beyond
frustrating when stuff breaks, especially when it comes from people I depend on
to know better. I'm not just saying this with my "Get off my lawn" voice either,
I can say it standing on my security soapbox too.
 
The catalyst this time, is a gaming community, that will remain unnamed, allows
it's members to join groups anonymously. The system is complicated, but nice.
Each group gets it's own web-based chat room, and private forums; each with its
own dedicated permission system. I actually like the system, the problem is
every status/presence response includes a stack of metadata. At first glance
looks like there's nothing of value getting leaked, each roll is just a number
with an array of other numbers. The problem comes when one member isn't publicly
listed, and another is. Once you can resolve the group roll id to a group name
you can identify every member of that group, hidden or not.
 
Security and privacy data goes both ways, i.e., when your code requires the
client to provide information that it doesn't need, and then breaks when that
information is omitted. If you have any desire to protect as much of your online
privacy as you can, you should have already disabled your browser from sending
referrers on each page request. That is, unless you want to login and do some
online banking. Disable referrers and visit [Chase.com](https://chase.com). I
know *why* they've decided this was a good decision, but expecting a header you
don't receive, and then allowing everything to break when it's missing isn't how
you write good software. Less is more.
 
It's not just requiring less, or providing less. You should also try and *do*
less. You obviously don't want any online account to be compromised, but just as
bad is allowing a denial of service. We can argue about the correct number of
failed login attempts before you do something. But there's no doubt that if Eve
is trying to guess the username and password pair, what you shouldn't do is
preemptively reset the users password. Passwords are already hard enough for
users to manage, don't do anything extra to make it *harder* on them. And, under
**no** circumstance should you allow an attacker, without the password, to force
a password change[^1]. I'm looking at you Wells Fargo!
 
[^1]: [1] [XKCD Password Reuse](https://www.xkcd.com/792/)
 
If you're not interested in building strong, correct systems, and you only want
it to work, I'm not sure why you're reading my blog, but I'm still glad to have
you, and you do you! Import
[left-pad](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) and get
on with life! But for those still reading, and not yet recoiling at my,
admittedly, opisitional take, read through the code you're working on right now,
and ask yourself. "Is there anything here I can take away?" Not only will future
you be grateful, and not only will I thank you when I inherit your code, but
most importantly, none of your users will curse your existence, and isn't that
really what it's all about? Making the fewest possible arch-enemies in life[^2]?
 
[^2]: [2] yes yes, this is something I'm famously bad at... Baby steps :)
 
 
ev/null added: 81, removed: 70, total 11
@@ -1,68 +0,0 @@
+++
layout = "post"
title = "You don't want to be a developer"
date = 2019-06-22
tags = ["security", "code", "old-man"]
+++
 
You don't want to be a software developer. Or at least *I* don't want you to
be, I want you to be a software engineer. It may seem to be simply a semantic
difference, but it's an important one. Developers write a lot of software,
implement features left and right. Some of the best ideas I've seen come from
developers I respect. The critical difference is that developers omit the well
known engineering maxim.
 
> *Perfection is achieved, not when there is nothing more to add, but when
> there is nothing left to take away.* -- [Antoine de Saint-Exupéry](https://en.wikipedia.org/wiki/Antoine_de_Saint-Exup%C3%A9ry)
 
 
You should apply that maxim to every single line of code, every import/include,
every decision, every packet, every expectation, every **thing**!
 
It's trivially annoying when I come across needless cruft, but it's beyond
frustrating when stuff breaks, especially when it comes from people I expect to
know better. I'm not just saying this with my "Get off my lawn" voice either, I
can say it standing on my security soapbox too.
 
A gaming community, that will remain unnamed, allows it's members to join groups
anonymously. The system is complicated, but nice. Each group gets it's own
web-based chat room, and private forums; each with its own dedicated permission
system. I actually like the system, the problem is every status/presence
response includes a stack of metadata. At first glance looks like there's
nothing of value getting leaked, each roll is just a number with an array of
other numbers. The problem comes when one member isn't publicly listed, and
another is. Once you can resolve the group roll id to a group name you can
identify every member of that group, hidden or not.
 
Security and privacy data goes both ways, i.e., when your code requires the
client to provide information that it doesn't need, and then breaks when that
information is omitted. If you have any desire to protect as much of your online
privacy as you can, you should have already disabled your browser from sending
referrers on each page request. That is, unless you want to login and do some
online banking. Disable referrers and visit [Chase.com](https://chase.com). I
know *why* they've decided this was a good decision, but expecting a header you
don't receive, and then allowing everything to break when it's missing isn't how
you write good software. Less is more.
 
It's not just requiring less, or providing less. You should also try and *do*
less. You obviously don't want any online account to be compromised, but just as
bad is allowing a denial of service. We can argue about the correct number of
failed login attempts before you do something. But there's no doubt that if Eve
is trying to guess the username and password pair, what you shouldn't do is
preemptively reset the users password. Passwords are already hard enough for
users to manage, don't do anything extra to make it *harder* on them. And, under
**no** circumstance should you allow an attacker, without the password, to force
a password change[^1]. I'm looking at you Wells Fargo!
 
[^1]: [1] [XKCD Password Reuse](https://www.xkcd.com/792/)
 
If you're not interested in building strong, correct systems, and you only want
it to work, I'm not sure why you're reading my blog, but you do you! Import
[left-pad](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) and get
on with life! But for those still reading, take a look at the code you're
working on right now, and ask yourself. "Is there anything here I can take
away?" Not only will future you be grateful, and not only will I thank you when
I inherit your code, but most importantly, none of your users will curse your
existence, and isn't that really what it's all about? Making the fewest possible
arch-enemies in life?