Tech/code question

[elisheva_m]

I'm trying to write a scene where two co-workers are trouble-shooting a new custom security or encryption routine. Someone else (who isn't present) wrote the code and he will have been careful to ensure it works before sending it to them. So maybe something in the implementation of it?

The scene is dual purpose, showing their interaction growing closer while also hiding something else in plain sight. The tech part of it can be whatever is plausible and easy to convey without bogging it down in details. I am so out of touch with that sort of thing I don't know what's plausible any more.

What could go wrong with uploading the new code into their office network or onto their phones which would need a bit of trouble-shooting? The kind of thing one person might overlook and another catch. Preferably with them being literally close while they do this. And again - easy to convey without bogging it down in details. Jargon is fine.

Edit: Turns out jargon is not fine. Well it would be in the sense I meant, but that's not how it was taken. Am overwhelmed by how much I can't understand well enough to follow here, let alone distill into a few phrases. I know the readers for my lakorn-novel are non-existent but I can't swamp them with details.

Edit 2: Sorry to have bothered everyone. I'm just going to trash this. It was a stupid idea in the first place. Thank you for your time.

Comments

[conuly]

Unforseen user error. The coder assumed something and didn't write it down, or wrote something in some way that was confusing, and failed to properly account for the human element.

[goddess47]

As an option...

I'd write the scene without worrying about the jargon first. What do you want to happen between the two characters? If you're looking for a fixable error, it could be something as simple as left-handed vs right-handed. On a phone screen, would something be 'awkward' if the one user is left-handed?

Do you want things to go wrong? That's kind of a different thing to write?

Whether the implementation goes right or wrong, I'm suspecting that if you write the scene as you want it to happen and put in XXX - a placeholder -- for jargon that you may or may not need will keep you moving forward.

Good luck!

[silveradept]

Much of the time, issues in security or encryption pop up from the endless creativity of humans. Has the developer considered what to do if an entire password string is all emoji? Can they handle the entire CJK (Chinese, Japanese, Korean) set of inputs? (if they're international, anyway.) What about diacritics? If symbols throw the program for a loop, that will need debugging.

Were some test credentials hardcoded into the program that give admin access? That's a big security risk.

[jadelennox]

Oh, and as a corollary to that, the entire set of falsehoods programmers believe. Sometimes it's even sillier than "I forgot not all languages are left-to-right / not all names have two words". Sometimes it's "I assumed the computer being installed on was

• on the same timezone as the programmer's
• had a correctly set date & time
• was connected to the internet
• and had access to the same cloud services as the programmer
• and that the users of the software had desktop admin rights

etc. etc.

FTP vs SFTP

[(Anonymous)]

Here's a real-life example:
SFTP is the newer, more secure version of FTP. They both are a way to send a file from one system to another. SFTP just ensures the contents of the file are encrypted while transported from one system to the other so no hacker can steal the data.

In a current system, the data is encrypted before sending it over FTP, and then we decrypt it when we receive it.

If we switch the process to SFTP, will the original data still be encrypted before sending? Meaning we'd still need to decrypt it when we receive it. Or, will they now send it unencrypted, knowing that SFTP will encrypt it in transit? Meaning we would no longer need to decrypt it when we received it.

If we try to decrypt a file that wasn't encrypted in the first place, the data won't be readable. But if we don't decrypt the file and it is still encrypted, the data won't be readable, either.

- Jill

[jadelennox]

I had to roll back a deploy this morning because I updated the version of python used in a library, but the Dockerfile used by the kubernetes cluster in our environment only installed an older version of python. I had to:

• update my code
• find out from my coworkers what other part of our pipelines were dependent on our code so I could verify my change was good
• test the dependent part of the pipeline by running a deploy
• see the deploy failed
• see in the console logs that it was because of python version
• get help from a colleague who figured out that the old version of python was coming from an ancient Dockerfile
• create a revert pull request and get it approved
• run a fresh deploy to verify

(There are tons of such things; I'm only thinking of that one because it happened today. Version incompatability is really common. There's also "certificate expired" or "processes depended on library version with breaking changes in an essential security patch" or "us-east-1 was unreachable, etc., etc. And the cardinal rule: "it's always DNS".)

[mneme]

Yes, this is the best.

If you have someone who builds code and is diligent and competent and has time to test thing thoroughly and then the other person finds that things are broken and has to track stuff down and fix them (possibly with help), the MOST likely vector is dependency issues.

Just because someone built code that worked -perfectly- in their environment doesn't mean it will work at all on someone else's machine. Even if they are using tools expressly designed to synchronize/isolate these kinds of dependecies (like, say, Docker, package management tools, release kits, etc), that's no guarantee that there won't be some setup outside those tools that causes everything to go to heck until it's tracked down; everything from having the "wrong" version of a package, library, scripting language, or even the entire operating system to a difference in a harmless-seeming configuration, security setting, or permission setup.

[autodach]

My condolences for your deploy.
This is a really good suggestion, very flexible. Can be boiled down to "version mismatch" or "it worked on my machine" if less jargon is desired.

[voidampersand]

Where are the damn unit tests? If it's security code, it should have 100% code coverage, and there should be a white-paper explaining the domain, and there should be 100% domain coverage. Making sure the code works is not enough. You need to be sure there isn't any code that isn't tested. Any code that is not executed by tests is a potential bug. Maybe a potential exploit or even a back-door. It should be deleted with extreme prejudice.

Even if the code works perfectly, it is possible to have glaring security flaws. Like leaving clear-text passwords in memory. Failing to salt. Using a fast hash algorithm instead of a slow, secure one.

If it's custom encryption code, the risk factor goes up by a lot. Most new encryption algorithms are heavily scrutinized by experts before they are used in production. Which is a good thing, because most new encryption algorithms turn out to be crackable.

[winterbird]

Looking at the comments in contrast with your edit, it's true that a lot of the comments are (unfortunately) not very penetrable/understandable to people who don't understand these things (most people don't know what DNS is for example - let alone dependencies etc.)

You might want to look at how the Murderbot series by Martha Wells handles talking about code and conflicts with code in a way that is plain language to newcomers, it will be more accessible and even show how to inject tension and fraught emotion into those scenes. It's being made into a TV series, so you can also watch the first three episodes, but honestly I think Wells is very clever for how she handles the details of a story where basically a human computer is frequently interfacing with other computers, and handles literally all kinds of security from the physical to the online.

Murderbot / Secunit frequently has to explain things going wrong to people who don't understand those things, as well as talk to computers who do, and yet that all has to remain understandable to the reader. So this is a good place to start for accessing this kind of language.

Alternatively, goddess47 's suggestion to write the scene without worrying about the jargon first is the best way to go.

There are many, many ways to write two characters growing closer, while also hiding something in plain sight, even if they both work in IT. I agree with some of the others that it would be a bit odd for people to upload custom security without that person being there troubleshooting it for them (or having a team to troubleshoot it for workers) as this is standard. When something custom is made for a workplace, typically, people will come into that workplace and run classes / literally set it up for them / walk them through how to use it / and notice any bugs that didn't make it through testing (which is something this security should *absolutely* have had) and also support and reassure workers who often don't *want* new systems and can be quite hostile to them.

Unfortunately some aspects of the scene you want to write are not very realistic to how a lot of these things are often implemented nowadays, especially when it comes to custom code commissioned by a workplace for specific needs. Especially when that code is around security.

This also might be why some of the answers aren't fitting what you need, because these situations don't really happen in the way you're imagining.

The easiest way to get around that is to keep the core of the scene - two people getting closer in a workplace, and also hiding something in plain sight (not sure what you mean by this - you mean they're altering the code? Hiding an object? They're hiding that they're helping out on the code in plain sight? etc.) - and to step away from needing the scene to unroll in this specific scenario.

Even if your characters are computer engineers themselves or work in code, they would not be troubleshooting something as serious as custom security if they didn't write it themselves. They would be sending a ticket / bug / report / calling the person or team who wrote that code.

(Experience: My mum worked for many years in a team that educated the government in how to install and run new codes and programs in the justice system in Western Australia, so the security was - as you can imagine - very important. What I learned from that is that you have many smaller teams involved in something like this on a large scale level - the testers are one part, the coders are another, the engineers are sometimes another, the people who educate those who are learning the program are another, the people who take tickets and complaints and bug reports are another, and they don't all communicate to each other very well. So the idea that two people in that setting (and we don't know your setting at all, so I can only share what I know) would 'troubleshoot' a bug independently when there are literally 60~ people working on this custom issue that you would report to first, speaks to great incompetency and misunderstanding on their behalf. This was my mum's experience in the 90s and 00s, to give you an idea of how long this has been the norm re: implementation.

Small companies often simply cannot afford custom security code (it can take many years to write, test, implement, troubleshoot, update etc.), they would be working with larger cybersecurity companies who provide more generic security code. Even small tech companies do not just find a random person to make their security code for them.

Larger companies that can afford custom security code and have a need of it (many don't), will be hiring a stable of people to usually work both in-house (in their company to familiarise themselves with the needs of the company and people) and back at their own office/s.

Unless you're writing science fiction, I genuinely can't think of many scenarios where *anyone* would simply write some security code, not test it among many MANY people first, and then pass it to a workplace, and somehow need to not be notified personally when something goes wrong (this would make me immediately not like those coworkers very much, lol, like why do they think they're so much better than the person who *knows* the code?)

It's possible that in being out of touch with this stuff, it's just now working in a completely different way to what you were familiar with. And in that sense, unless you want to go down a big rabbithole of how this stuff often works (which honestly is pretty boring, and very frustrating, because a lot of the time it's the phone team frustrated with the testing team frustrated with the engineers frustrated with the educators frustrated with the workplace people who won't just contact them when something goes wrong etc.) it may be worth changing the premise of the scene while keeping the emotional core of its function.

Alternatively, just make it so that it doesn't have to be security code or encryption, there are workplaces that have in-house folks who work on code for a program that has nothing to do with security (though cybersecurity touches more and more as time goes by), so that's something else to consider!

[elisheva_m]

Thank you for your detailed explanation of the many ways I am wrong. I'm just going to trash it.

[winterbird]

The core of the scene is fantastic! I definitely think you can keep it, and part of writing is sometimes learning that what we first imagine can be reimagined into something even better or stronger for your characters.

That, or just don't worry about people thinking it's not realistic, and write something like what you wanted to write all along, and deal with the details later. Ultimately it's your story, if the scene you're imagining is the only way something can possibly take place, then write it that way. Authors handwave reality all the time, that's literally what we do best!