Windows Phone...😦

This guy I know applied for a senior position at a company I used to do freelance for. He walked in while I was spending the day there to work on our project.

We used to work in the same company and I knew that this guy doesn't know shit. He's the type that would foam in the mouth while bullshitting his way through any sort of discussion.

Anyway, they had him set up on a computer a few tables from me to complete some coding exercises--real simple stuff just to see how he would approach some common problems.

There was no time limit set but the tests shouldn't have taken him more than an hour.

He sat there for SIX HOURS.

At this point, I went out for a smoke, came back 5 minutes later, and found that he wasn't there anymore.

Apparently, he just stood up and said, "Nope, can't do it" and then left the building without a word to anybody else.

We never heard of him again.

Oh, and the tests? Not a single line of code written XD

A thing that I am annoyed that people are getting wrong is security by obscurity.

You have heard of it and being told it is bad. It is so bad that it alone is a counter argument. Let me set you straight:

>>>Security by obscurity is the best security you will ever have<<<

There is an asterisk: It is probably not right for your business. But that is for the end.

Security by obscurity means to hide something away. Most security is based on hiding. You hide your private key or your password or whatever other secret there is. If you had a 2048 long sequence of port knocking, that would be fine, too.. Or it would be fine if it wasn't observable. You could write this down in your documentation and it wouldn't be security by obscurity. It would just be security. Weird, but fine.

The real meat of obscurity is: No one knows that there is someone. The server you port knock looks like a harmless server, but suddenly has an open port to a bad application for an IP, but only if that IP went to 25 other ports first.

In the animal kingdom, there are different survival strategies. One of them is being an apex predator or at least so big and lumbering that no predator wants a piece of you. That's our security. It is upstream security. It is the state.

But what is the rest of the animal kingdom going to do? Well, run away. That works. Not being caught. And those not fast enough? Hide! Just be invisible to the predators. They cannot triple check every leaf and expect to be done with the tree before starving. That's security by obscurity. Or hide in the group. Zebras. Easy to see, hard to track in the group. Look like everyone else.

There is a reason why drug smugglers don't have vaults in the carry-on. Arrive at the customs and just refuse to open the vault. If the vault is good enough. Nope, they lack the upstream security by the state. The state is there enemy, so they need obscurity rather than cryptographic safety.

And so, for a private person, having a port knocking solution or disguising a service as another service is a great idea.

Every cryptography course happily admits that the moment they can catch you physically, cryptography is useless. They also teach you about steganography. But they omit to tell you that obscurity is the second best solution to having a stronger army when you cannot rely on your state as upstream security.

Why did I say, not a good idea for companies?
1. It is self-defeating, since you have to tell it to all employees using it. A shared secret is no secret. And therefore it cannot be documented.
2. It makes working with different servers so much harder if there is a special procedure for all of them to access them. Even if it were documented. (See 1.)
3. You're a company, you are advertising your services. How to hide that you run them?

Do you see how those are not security relevant questions? Those are implementation relevant questions.

Here is an example:
Should you have your admins log into servers as normal users before elevating to root or is that just obscurity? Well, not for security purposes. Because that foothold is so bad, if compromised, it makes little difference. It is for logging purposes, so we have a better server log who logged in. Not only always root. But if our log could differentiate by the used private key, there is no issue with that.

If it is your private stuff, be creative. Hide it. Important skill. And it is not either, or. Encrypt it your backup, then hide it. Port knock, then required an elliptic curve private key to authenticate.

It is a lot of fun, if nothing else. Don't do it with your company. Downsides are too big. Cheaper to hire lawyers if needed.

Pretty niche tool, but Sencha Architect!
It is a wanna be GUI-Builder/IDE for ExtJS, but neither works properly.
This rant is not about ExtJS, just about Sencha Architect, which my coworkers and I were forced to use.
If you want to join the ride, here an excerpt of just some of the issues:

- installation: already the setup is more of a gamble than an actual setup, either it works on your machine or it doesn't, plain and simple

- GUI Builder: just drag and dropping components is actually nice, but the editing capabilities are frustrating, you can't edit the UI code by hand at all, just through pre defined properties. If there was the need to really mix things up it wasn't possible, I couldn't even rebuild shown examples of their ExtJS documentation. Furthermore the property editor was data type locked, which means if you want to enter a string which ExtJS already supports, but architect locks the value as a boolean, you can't edit it at all, while still using Architect

- code editing: well it is a colored texteditor, which is fine, and I could live with that, but Architect let's you just edit areas where it allows you to - want to change something else? Nope not allowed

- autocompletion: there is none at all, same goes for refactoring, multi highlighting, string replacement, and others

- code storing: well now some may think edit it somewhere else, well no, also not possible... Architect not just only saves simple js, there is also a Json formatted file for everything you have created, which is needed so the tool can actually load it for further editing. They possibly never heard of DRY. But the worst of this code storing was actually using git along with it - have a merge conflict? Merge both files! Every single time, it was so damn tedious

There are a few more, but these were the worst I can remember.
Luckily I don't have to use it anymore!
Maybe they have fixed or changed a lot of it, because the developers were aware of the issues and eager to resolve them, as far as I was told on a roadmap presentation. And some of the tools they had released in the end of my time using ExtJS were actually really good, like an IDE plugin for the framework, and I liked using it.