Earlier this week I gave a talk about security in the startup world. While working on the presentation and trying to figure out which content I want to cover I ran into a very simple problem: security is hard and the field is quite large.
I think this is not a well kept secret, but something most people working in information security know and are fully aware of. Nevertheless I had to figure something out and received some good feedback in the end. But instead of calling it a day and celebrating myself I decided to work on some articles outlining the foundations of things nearly any company should do.
Introducing: Startup Security 101 (the absolute basics).
Talking about any infosec related topic usually brings out people who like to start their sentences with “actually…”. And there will be a lot of chances to “well, actually…” me while reading through the upcoming articles. Consider this post my general disclaimer to not treat those articles as the ultimate, final truth. It’s supposed to be a starting point.
Some people believe security is an absolute. You either are doing everything known to humankind or everything you actually do is worthless. Some people believe security is the only thing a company must care about until they “get it right”. Others will argue that “theoretically” something better than whatever you do exists. Or that there are still holes and potential attack vectors that you missed. And there is a very good chance that some of those people are correct.
But here’s the thing: If you look at most security breaches and data leaks, they are not sophisticated attacks involving three zero day attacks. They are likely based on some very simple bug which in hindsight is so obvious that you question how this could have ever happened with a competent team working on the project. Truth be told the most talented engineers sometimes make mistakes – we all do. Sometimes the system crashes, sometimes the whole database leaks (but one of those two is obviously worse than the other).
What I will be focusing on in the startup security 101 series is covering as many basics as possible to reduce the chance of those kinds of bugs. Will you be 100% safe and absolutely unhackable? No. If I could offer this kind of knowledge I would be writing a book right now and plan which island I am going to buy to park my Bugatti Chiron on.
As you might have noticed by now is that I am always prefixing security with “startup”. This is actually intentional (not only because it increases the word count of this post). For startups there are three things which are nearly always true, no matter at which stage they are (except some specific domains):
- you can run out of money pretty fast
- time to ship is important
- dedicated security talent is not a priority
So all advices have to follow a few very specific criteria:
- they cannot add significantly to engineering expenses
- they have to be able to be implemented, used and maintained by software engineers without special training
- they cannot require days and days of work to do so
Focusing on the basics that cover the most common problems means that there will be gaps in your security concept. Therefore you have to treat security the same as your product and your company. It will evolve over time, it will need more attention and it will require you to think about problems you have not had at an earlier stage – but it has to be there from the beginning for this to happen. This is a very good problem to have, but it also means you will require additional, specialised engineers later on.
The articles will not follow any specific order. Most of them, except some which will focus on outlining a more general problem, will have actionable advice for a specific topic and hopefully allow you to jump into an implementation phase with minimal additional research. I will also try to provide guidance on how to obtain additional resources and information leading from the bare minimum coverage you should have to an industry best practice version – if something like this actually exists is a topic for another post.
Security is a process. Doing it right is often expensive and time consuming. But this should not discourage you from doing smaller pieces and going for easy wins. They will accumulate and will make sure you are in a better spot than without them. And in a way better spot than many of your competitors who do not think about security at all.
If you want to follow this article series you can either subscribe to the general RSS feed or to the tag specific one if you only care about startup security posts.
SwiftUI. When I heard the name I had very mixed feelings. It reminded me of the time I fought UI layouts in code. A horrible, dark time I do not want to remember. Back in the day I mad a happy dance for weeks when I discovered Borland C++ Builder and its interface tool. Transitioning to Mac OS and Xcode I missed it a bit and Interface Builder took a really long time before I considered it usable. So when Apple announced SwiftUI I was very sceptical. Playing around with it in the Xcode 11 beta I have to admit I could not have been more wrong. This might actually be a real game changer.
Let us first talk a little bit about application development in teams, specifically a client application for a server application. There are usually three large parts for an application like this:
- API integration
- business logic
We could surely break it down a little better, but let us just go with those three parts for now. Let us assume we are building an iOS application to fetch data from our server to display the latest news.
The API is pretty straight forward – fetch a JSON object, maybe pass a token in a header field to authenticate, handle some common errors,… pretty straight forward Swift you do not even need a third party library for anymore to make it simple and maintainable.
The business logic might be some transformation, maybe image resizing because the server team is lazy and does not want to do it or some random lookups and references to previously fetched data.
Now what happens when two engineers work on the same piece of code? Likely a merge conflict when bringing both changes into the master branch of the project. But it is also very likely that the conflicts can easily be resolved – in the end it is “just Swift”, right?
But what happens when you have merge conflicts in your xib / nib? For those who never were in this situation: you are in a world of pain, undo the merge and go on a vacation hoping someone else took care of it when you come back. Maybe you consider switching jobs if this is not the case.
Xib files are basically XML. A lot of XML, even for very simple UIs. And it is nearly impossible to programatically resolve merge conflicts, you are forced into Xcode and Interface Builder to figure out which changes were made and how to resolve them. There are lots of neat work arounds, but in the end – it sucks.
Fast forward to SwiftUI. Just watch this video if you have not yet. It is a pretty good introduction with some nice examples of a lot of the features you will likely love.
The code is stupidly simple. It is Swift. They even built a list with
UITableViewDataSource! This part alone makes me want to use an Xcode beta software all day long. Going a step further you can now inject test data and get a live preview. You read that right, a full preview of how your UI will look like with some data you can freely define. In Swift! And you can even do some sane positioning and layout changes without messing with constraints! And those two things were only the first 8 minutes.
Obviously not everything will be beautiful, nice and cozy. There will be a transition period, you will have to learn a new framework and I would take a bet that Xcode will break in 10 minute intervals after the release just for the sake of breaking. (Remember Swift v1 to v3 and code completion crashing?)
I took the time to create some test UI in Xcode and do some modifications in various branches. It is actually possible to see and resolve merge conflicts, but the more complex UIs and applications will get, the harder it will be. In the end writing a UI in code was never a pleasant or good idea, but it was a working solution.
Now I might make it sound like this is a totally new, unheard of concept, but it is not. Technically you can already maintain a UI in code. You could for decades. Technically. You do not really want to do this, especially when you have a team working on it. The chances that everyone is comfortable with it are pretty small. And to address one comment I know I will read: No, this does not speak to the quality of the engineers, not everyone thinks that using a steady hand and a magnetic needle is the right way to code, Mr. Elitist Snob.
SwiftUI might also make it feasible to develop a Swift application without Xcode. For all the AppCode or vim lovers this might be an actual game changer. And who knows, maybe Apple takes the chance and brings us Xcode for iOS next year. I would really appreciate that.
I am excited about Xcode 11 and SwiftUI, as excited as I was not in a very long time when it came to developing UIs and graphical applications. Let us see where this will lead us, but a unified way to write UIs across all platforms is surely welcome, appreciated and necessary if development for platforms other than iPhones and iPads should gain popularity.
When you look back at the last few WWDCs it felt less like a general developer conference and more like an iOS conference with some add ons at the end about the rest of the ecosystem. This year was different, it actually was a developer conference. But this also means certain topics do not get as much or in depth attention as you might have been used to during the last few years. But still: There were a few very exciting news, primarily for developers.
The developer page for iOS gives away the core focus of this year – ML and AR. While this sounds like something the end user does not really care about, they will care the moment applications start to leverage those technologies. One of the key factors to me is that machine learning is actually running on device.
I cannot stress enough how important “on device” actually is – ML in the cloud is a great idea and surely got some advantages… until you do not have an Internet connection. Or only have Edge as mobile data connection. The moment you have to rely on a network connection on a mobile device for a great user experience you are in for a very bad time.
AR is something Apple seems to toy around with to show its potential. Guess why people were standing in front of a $999 monitor stand with iPads up. Hint: not because they are as stupid as you would like the Internet to believe. While Apple is clearly is trying to show off the capabilities of AR, companies like Ikea and Pokémon Go leverage it in a way that got users excited. With all the focus I hope we will see a lot more innovation in this sector, even if that means going through tons of mediocre experiences where developers believe running through a city with an iPad in front of your face is a pleasant user experience. (It is a start.) But there will be some features that can be used by end users and it seems like people are really excited about them.
Dark mode is coming to iOS. I am using it since the release on macOS and for some reason my code does not magically pop out, policies I am working on to explain people why they cannot leave workstations unlocked and the weekly sprint planning does not bring me any more joy. I like the optics, but I cannot get on the hype train.
Follow up questions for Siri on the other hand are something I am really looking forward to. This should make using Siri a lot more enjoyable and useful. Features like reservation reminders are not really something I care about – living in Germany I will most likely have to wait roughly five to ten years before I can make use of them.
For watchOS we will see stand alone applications. Being a big fan of the Apple Watch – not necessarily as a watch though – having more capable apps on the road might be quite beneficial. How far developers are willing to push the watch and if the market will actually be open to buy watch only apps is something we will have to see. I could easily see Things on the watch becoming yet another version of the app you have to pay for for example.
In conclusion I like the general approach of WWDC becoming a developer and not an iOS conference again. I hope this trend will continue. And there are some exciting features users will be able to enjoy right away when iOS 13 will be released.
You often hear people complaining that Apple is ignoring the professional market. The iMac Pro is an amazing machine and I did not regret getting one for a single day. But this obviously was not enough for the loud, orange crowd. You need to be able to upgrade your system, you need x, y and z. Guess what – you can now get exactly this.
But, since we are talking about people on the Internet, everything is still bad. Too expensive. Not what they expected. The squeaky noises continue in an corner no one really cares about anymore. I hate to break it to you – the Mac Pro and Pro display are most likely not for you.
The Mac Pro in its smaller configurations is actually pretty reasonably priced considering the expandability. „But I can build the same hardware for $2000 less than what Apple is charging me“ I hear you say. Sure, if you ignore literally half of the keynote and half of the things that were announced and the options the system design provides. Then you can indeed get a CPU, memory and GPU for less. You can get the iMac Pro for less with a free 5k screen.
„But the Pro display is way too expensive“ I hear you say. Sure, if you compare it to consumer grade hardware you find on Amazon you are right. If you compare it to hardware in the same segment the display is positioned in it is more than reasonably priced.
You might want to joke about the display stand. I have to admit it feels like poor marketing, but is fully aligned with Apples usual pricing strategy. Just offer a discount if you do not buy the stand and no one would have ever talked about it. But most people actually buying a display in this category have desk or wall mounts in place, I would not be surprised if for every 10 displays only one stand is sold.
The Mac Pro and Pro display target a very specific customer group. Just because they have „Pro“ in the name and you consider yourself a professional does not make you the target audience for those two pieces of hardware. The moment you need – notice the „need“, not „believe to need“ or „want“ – a system like this and it actually makes a difference for your work you are most likely charging your clients enough that after one or two jobs the system is paid for and you still have enough left to get a pizza.
The Mac Pro and Pro display are like an Bugatti Chiron – looks amazing, I would enjoy taking one for a drive, but there is no scenario in which I would ever need one.
I already hear the squeaky noises bringing up some C code base you can build on 28 cores and are done compiling in 15 instead of 20 minutes explaining that they are surely the target audience for this…
It is no secret that I am a big fan of the iPad. While most people talk about media consumption, I see it as a productivity device. With iPadOS we are actually getting a lot closer to being able to get work done without changing known paradigms on how „things are being done“.
Considering the iPad as productivity device is one of those topics you can discuss for hours and still end up with people sticking to their existing opinion. I think there are a few very convincing points you can make for the iPad, if the kind of work you do matches the devices capabilities.
- It is secure without much effort and without a lot of user training (auto updates, biometric authentication, MDM,…)
- It is easily replaceable (restore from iCloud backup)
- No: moving parts, fans, heat making it uncomfortable to use
- The Apple Pencil, hands down the best thing that happened to my specs (photos of my whiteboard are not something you want to see, believe me)
Price is not really an argument in favor of the iPad after its last iteration. With the keyboard, the pencil, some storage you are easily in the price range of a traditional MacBook. And thanks to the usual lifespan of a MacBook (ignoring obvious technical deficits we have seen in the last two iterations) an argument for the iPad being cheaper over 5 years can also not be made.
With iPadOS We are seeing a lot features regular users requested since they are part of their regular workflow. Copying files from a USB drive? Sure. Two Word documents side by side? Okay. We can joke and mock those features as „enterprise-y“, but those are exactly the features preventing a lot of users from using the iPad for more than pure media consumption. Too many tradeoffs.
And considering the added „enterprise features“ – imagine how many people from your executive and non engineering team you could transition to an iPad. In most startups you find some web applications, some cloud storage and some apps for documents and spreadsheets that legal, finance, upper management,… are using on a daily basis and require to get their job done. We are getting close, really close to being able to make this possible.
Now I might hear some of you complaining about screen real estate, mice and keyboards. Hook up an external screen, connect the standard Magic keyboard people would be using anyway and let us hope the mouse support through the accessibility features is more than an ugly, grey dot on screen.
Safari bringing a desktop like web browser experience to the iPad seems to be something people appreciate. I do not really get it, but I also never had any problems with Safari mobile and I prefer to use native apps whenever I can instead of a web app.
I usually receive some mockery for working a lot on the iPad, but hey, works for me. Even for some light software development thanks to Neovim and Blink. I know, I know, there is a computer somewhere, but not on my lap, not somewhere in my proximity and without anyone but my wife or myself near it. Especially when traveling that is something I really appreciate.
The iPad is getting better and better as a productivity device, and I’m curious to see how far Apple will go.