4 ms·

Ask HN: Please take part in experiment on HN's collective expertise.

16 points by iuguy 16y ago

There's a lot of really smart people from different backgrounds on HN. I thought I'd ask the HN community to post the one piece of advice that you could give a fellow HN'er from your own domain of expertise. Please upvote the ones you like the most, but only post one piece of advice.

iuguy 16y ago
Having done information security for way too long, the one piece of advice I could give is: Never trust input. Unless you can control access to the source and destination and secure the confidentiality and integrity of the transport, assume that any information is tainted by default. It doesn't have to be user-generated (that cookie in that request, don't assume it's not been tampered with) input, just input in general. However your app interacts with data, sanitise it by default and assume that the content may be malicious and you'll solve a fair chunk of your potential information security problems.
- madhouse 16y ago
  Expanding on this advice: never assume that the libraries or programs you use are bug-free. Before digging deep into your own code, make sure the bug actually is in it, and not somewhere else. I have seen problems where a particular program didn't work, due to the other side - which I had nearly no information about - had a bad optimisation, which made it crash. Or another, recent case, where a particular third party library was abusing a cache, and stored freed objects in it, which resulted in interesting crashes all over the place.
RiderOfGiraffes 16y ago
Randomness clumps, and randomness solves many, many problems. Be sure you understand first both your problems and the randomness you intend to introduce, otherwise many, many things will break in bizarre ways. Single example: ballistic shotgun stochastic hill-(climbing|descending) will often get you a good enough solution far faster than most techniques that are more complex and more impenetrable.
imcqueen 16y ago
Test everything about your design. Your customers will tell you what works and what doesn't. Remember that copy is part of the design too, headline tests are boring but they can make a huge difference.
Jacquass12321 16y ago
When you're debugging and you make that assumption that the error certainly isn't in one section of code so you should look elsewhere, check that one section of code first.
stakent 16y ago
Periodically test the infrastructure backing up your primary production assets. Make tests so close to reality as possible. Use tests results to learn and improve your processes.
proexploit 16y ago
The motivated and hard-working will succeed.
deleted 16y ago
[deleted]
hfinney 16y ago
The conventional wisdom is usually right. That's how it got to be the conventional wisdom.
marklabedz 16y ago
When presenting: Never, ever read from a slide. Always speak more words than you type. If possible, get rid of slides completely.
aiurtourist 16y ago
When writing code, think of the people who will inherit it from you.
meaydinli 16y ago
K.I.S.S rule "keep it simple s...." it is usually better to subtract code to fix bugs (and to optimize) then to add code.

16 points by iuguy 16y ago

iuguy 16y ago

Having done information security for way too long, the one piece of advice I could give is: Never trust input. Unless you can control access to the source and destination and secure the confidentiality and integrity of the transport, assume that any information is tainted by default. It doesn't have to be user-generated (that cookie in that request, don't assume it's not been tampered with) input, just input in general. However your app interacts with data, sanitise it by default and assume that the content may be malicious and you'll solve a fair chunk of your potential information security problems.

madhouse 16y ago
Expanding on this advice: never assume that the libraries or programs you use are bug-free. Before digging deep into your own code, make sure the bug actually is in it, and not somewhere else. I have seen problems where a particular program didn't work, due to the other side - which I had nearly no information about - had a bad optimisation, which made it crash. Or another, recent case, where a particular third party library was abusing a cache, and stored freed objects in it, which resulted in interesting crashes all over the place.

RiderOfGiraffes 16y ago

Randomness clumps, and randomness solves many, many problems. Be sure you understand first both your problems and the randomness you intend to introduce, otherwise many, many things will break in bizarre ways. Single example: ballistic shotgun stochastic hill-(climbing|descending) will often get you a good enough solution far faster than most techniques that are more complex and more impenetrable.

imcqueen 16y ago

Test everything about your design. Your customers will tell you what works and what doesn't. Remember that copy is part of the design too, headline tests are boring but they can make a huge difference.

Jacquass12321 16y ago

When you're debugging and you make that assumption that the error certainly isn't in one section of code so you should look elsewhere, check that one section of code first.

stakent 16y ago

Periodically test the infrastructure backing up your primary production assets. Make tests so close to reality as possible. Use tests results to learn and improve your processes.

proexploit 16y ago

The motivated and hard-working will succeed.

deleted 16y ago

[deleted]

hfinney 16y ago

The conventional wisdom is usually right. That's how it got to be the conventional wisdom.

marklabedz 16y ago

When presenting: Never, ever read from a slide. Always speak more words than you type. If possible, get rid of slides completely.

aiurtourist 16y ago

When writing code, think of the people who will inherit it from you.

meaydinli 16y ago

K.I.S.S rule "keep it simple s...." it is usually better to subtract code to fix bugs (and to optimize) then to add code.