Directly behind it is the student library, with an echoey three story tall open space [1] (why would you design a library like that?!). When you're there at 2am you can hear the chains dropping and hitting the coffin on the hour, which is not at all terrifying...
> A common pattern in these systems is that there's some frontend, which could be a service or some Javascript or an app, which calls a number of backend services to do what it needs to do.
I think an important idea here is that you should be trying to measure the experience of a user (or as close as possible). If there is a slow service somewhere in your stack, but has no impact on user experience, then who cares? Conversely, if users are complaining that the app feels sluggish, then it doesn't matter if all your graphs say that everything is OK.
I find it helpful to split up graphs/monitoring into two categories: 1) if these graphs look fine then the service is probably fine, and 2) if problems are being reported then these graphs might give an insight into why things are going wibbly. In general, we alert on the former and diagnose with the latter. Of course, its nigh on impossible to get perfect metrics that track actual user experience, but we've definitely found it worthwhile to try and get as close as possible to it.
---
Another fun problem with using summary statistics is they can easily "lie" if the API can do a variable amount of work. For example, if you have a "get updates API" that is called regularly to see updates since the last call, then you end up with two "modes": 1) small amount of time between calls and so super fast and 2) a large amount of time between calls and so is slow. Now, in any given time period the vast majority of the calls are going to be super quick, but every user will hit the slow case the first time they open the app for the first time that day. This results in summary statistics that all but ignore those slow API calls when opening the app.
One thing that always has scared me a bit with using CAs for SSH is how you protect the signing certificates? After all, if an attacker gets that cert then they get full access to everything, and can masquerade as anyone. You end up with a choice between a) have lots of SSH keys out in the wild, each with varying degrees of access, or b) have a single cert that is on your infrastructure but has access to everything. (Not to mention how you deal with the operating the site, what happens if it crashes? How do you log in without the site to sign your ssh key? Using standard trusted SSH keys to access feels like its somewhat undermining the point of using CAs).
Has anyone solved this, or got a write up of some best practices for running this? All I've managed to find are articles about how to run such apps, rather than how it fits into the broader security architecture.
Ideally ideally, what I would actually like is the ability to configure OpenSSH to require multiple things to log in, i.e. both that they SSH key is trusted and that it has recently been signed by the signing service. That way gaining access to the signing certificate doesn't help without also gaining a trusted SSH key (it's still bad, but not quite Game Over levels of bad). I had a quick look to see if I could hack together a patch to do this, but alas I had forgotten how weak my C foo is :(
The main thing I found interesting about this is the idea of trying to break the taboo of working from bed, especially for those who have a disability that make it hard/impossible to get out of bed some days. After all, this is the reality for a lot of people long before the pandemic. Yes, fine, maybe it's bad for your back or sleep schedule (I personally hate even reading in bed), but it's up to the individual to figure out what works for them.
I really hope that one thing we get from this pandemic is not just that remote work is more accepted, but that there's more understanding and flexibility over people's individual situations (without them having to try and justify themselves). This would help so many people, whether they're disabled, or juggling childcare, or whatever.
To me all these slogans around security is to ensure people really, truly, actually think about things before they go against the grain. Is using obscurity as part of your defence always wrong? No, but equally it often adds a false sense of security. Popularising these easy to remember slogans helps change peoples defaults. Nowadays, if someone sees an attempt at security by obscurity it (hopefully) rings alarm bells and causes them to interrogate it to ensure that there is also other security measures in place, or that it is otherwise OK. It's the same with "never roll your own crypto"
I find it somewhat interesting that the article uses an example which falls right into another pitfall that "security vs obscurity" is trying to prevent.
> SSH runs in port 64323 and my credentials are utku:123456. What is the likelihood of being compromised?
>
> Now we changed the default port number. Does it help? Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports. ... So, if you switch your port from 22 to 64323, you will eliminate some of them. You will reduce the likelihood and risk.
This is technically correct. However, the author has identified a security concern that he wants to mitigate: brute force attacks. Now, you could try and reduce that risk by using a different port which might reduce it by 50%, or* you could fix this issue by deploying fail2ban (or using ssh keys, or VPNs and bastion boxes, etc), and thus negating that attack vector entirely. There isn't even a usability argument here: making people remember the right port for ssh is less usable than setting up fail2ban. Of course there are tonnes of other attack vectors to consider, but in general where possible its better to "properly" (fsvo.) mitigate those concerns and only rely on obscurity where that isn't possible. If a concern is mitigated than adding obscurity does almost nothing, while likely proving to be more annoying to the end user (like in the case of specifying a port in the above example).
Now of course that's not to say that you should never use obscurity, but if you do then I think its entirely reasonable that you are prepared to give a good justification why its appropriate. For example, sharing via secret URLs is a good example where it can be easy to justify in some settings, but it equally may not be OK for documents that are really really sensitive as its relatively easy for links to be shared in error with the wrong people.
RE some comments about using obscurity to signal that your deployments would be harder to get into and thus for attackers to not bother: I'd genuinely love to know if that is true or not, I wouldn't be surprised if attackers assumed obfuscation mean that the more advance security measures hadn't been deployed (otherwise why bother with obfuscation?).
* Based on the twitter poll in TFA, though if you have a targeted attack it seems sensible to assume that if port 22 doesn't work they'd try again with other methods
I did a Maths degree before becoming a software engineer, and honestly I think its really changed the way I think, just in general. There's something about being given a problem, or theorem to prove, and grappling with it until you really start to get a deeper understanding. After spending hours on a single problem, sitting there trying various ideas, getting flashes of inspiration, hitting dead ends, grabbing a drink, coming back and doing it all again. Finally actually getting to the point where it all just suddenly clicks and you realise that actually if you just think about it in these ways the solution is just, well, obvious! It's really intensely satisfying; just a three line proof of "without loss of generality we can assume X, which implies Y, and so clearly Z is true". So satisfying! (Then you realise you still have another nine problems to try to do before tomorrow, oh god...)
Anyway.
To me, it really taught how to tackle Hard Problems, where you do just sit there making seemingly no process for hours/days/weeks. When you first start tackling such problems it can feel really frustrating, but actually with experience you realise that progress is being made when you slowly manage to map out the problem space and get a better intuitive understanding what's going on. I kinda do imagine it as stumbling round in the dark in an unfamiliar place, slowing groping around, hitting dead ends, then slowly but surely getting a mental model of what's around you and how it all interconnects. Once you have that understanding and intuition the problem is often, kinda, easy? Or obviously impossible and you'll need to make some trade offs.
Changing the way you think about progress to be less goal oriented and more about expanding your understanding is really quite crucial to tackling such problems I think. Both just to keep you motivated through the process and stop you from getting discouraged, but also helps you realise when you've stopped making any progress and should take a bit of a break and come back with a fresh mind.
Most of the time this skill is entirely useless, but sometimes it really is quite powerful. I guess working on Matrix is a bit of a special case, but I would never have been able to sit down and spend weeks trying to come up with a new state resolution algorithm, to pick one example, without that sort of experience. I just wouldn't know where to start, and I'd become demotivated by the end of the first day and likely give up (knowing me).
All of this rambling is to say: I think Maths is really something you have to do. Reading books about it is interesting and great and all, but if you really want a deeper understanding you have to get stuck, get your hands dirty and try to solve problems. I don't mean problems where you take that cool theorem you just learnt and apply it or figure out how to apply, but problems where you actually have to come with ideas and theories on your own. (Now, I have no idea how feasible that is outside a formal setting and without supervisors, but that's really the dream).
I hope that in some ways helps, even if its probably entirely devoid of practical advice :)
FWIW I've been coding since my early teens and enjoyed it a lot, but when it came to university (in 2009) I had very little interest in doing a CS degree and instead opted for Maths. The two main reasons were: a) I knew that doing Maths instead of CS wasn't really going to hinder my job prospects in any way, and b) CS sounded a lot drier and had fewer options and choices than the Maths degree (in the UK you apply for the course and you generally don't do anything from other courses, so your choice matters a lot).
The first point I think has born out fairly well, even if it was probably a bit arrogant. Certainly when I'm interviewing grads I'm not actually that interested in if they did a CS degree (though that might be more because I didn't do one...). We don't really do early stage training so we're looking for evidence that the grads can actually code, whether its by pair programming, via questions or looking at personal projects, etc, its the people who have done it as a hobby that tend to shine there.
The second point is highly subjective and obviously quite personal, but equally if people know they can get into software engineering without a CS degree then I think they're more likely to do a course that really interests them. After all, if you it doesn't effect your job prospects that much then why wouldn't you? There is a fair argument to be said that the industry should be better at hiring CS and code camp graduates and doing on the job training, but that's not where we're at currently, alas.
If anything I tend to view CS as the academic arm, and software engineering as the practical/vocational arm. In the same way e.g. law works (at least in the UK), where actually most lawyers haven't done law as their first degree and do a conversion course after instead (often getting a contract before doing the conversion cause and then having the firm fund it). Really, its the classic argument about how much university degrees should be academic vs vocational.
It's worth noting that VPN / SSL proxies provide box to box (or process to box) encryption, whereas native SSL support provides process to process encryption. The difference being that if an attacker manages to get access to the box then it becomes easier to capture traffic due to it going unencrypted between the app and the VPN/SSL proxies. Fundamentally, native SSL support provides strictly better protection than just VPNs or SSL proxies.
Now, given the context this may or may not be a distinction that you care about, but there certainly are times where you really do care.
(Besides, if I'm running a tcpdump on a box to try and figure out why the network is going wibbly I'm a lot happier knowing all traffic is encrypted and I'm not going to accidentally capture some PII. I've had to tcpdump within docker containers before too, so putting everything in containers doesn't necessarily solve this.)
Yup, if you're using ssh-agent (as opposed to something like gnome-keyring) setting `AddKeysToAgent confirm` to your ssh config should cause a pop up to happen every time anything requests a key from the agent.
Isn't the other reason so that adversaries can't tell if a particular username/email has signed up? This is not so useful for something like github, sure, but certainly is useful for the more embarrassing sites where users have an expectation the site won't leak their membership.
So in some ways I've always thought of this as a privacy concern rather than a security one?
Edit: I guess I'm thinking purely of emails where you don't get availability checkers during sign up.
Honestly, these replies feel completely unhelfpul. This is exactly how MPs offices have always worked, staff open and respond to letters with little oversight. Now they do the same with email.
Yes, in 2017 we can do a lot better and use delegated access, but adoption of those features doesn't happen overnight. Delegation of access was probably not even a thing when Dorries was first elected?
So the question really is: who is responsible for ensuring that MPs are up to speed with new security measures? Why aren't they dealing with this?
I think we should be lobbying MPs to ensure that they have the support they need to keep up to speed with best security practice, not vilifying them for trying to muddle through the best they can. It sounds like a recipe for disaster to try and get them all to do it themselves.
---
On a tangential note:
> It's alarming to read that Nadine believes criticism of her approach is due to her gender because if ever there was a construct that's entirely gender-unbiased, it's access controls! Giving other people your credentials in a situation such as hers is a bad idea regardless of gender, race, sexuality and any other personal attribute someone may feel discriminated by.
Completely misses the point. Of course security is gender-unbiased, but that doesn't mean she isn't getting a harder time of it simply because she is female. Such bias happens a lot.
To be honest, I think the actual truth is that the papers enjoy reporting on whatever Nadine Dorries says. So yeah, I don't doubt that another MP would have received less flak for saying the same thing, simply because it wouldn't have been reported as widely.
(That doesn't mean we shouldn't talk about security issues, but don't discount the abuse women get just because you happen to disagree with them on a particular point.)
> And if what I’m truly trying to do is to learn to think about problems in a different way, a week-long effort at dabbling in a side project isn’t going to change my way of thinking.
I'm not sure that's why people try different languages. Certainly what I've gained from messing around with different languages over time (e.g. most recently rust) is exposure to different ideas and ways of doing things. Do I "think about every problem as if it should be a collection of tables in the third normal form"? No, but when I do need to decide how to store data I have a much better idea of how I would do it, or what I needed to look at.
Gaining experience of a range of ideas is a good thing irrespective of whether it changes the way you think. For example, if you know only one language (or one type of language), it can be quite hard to differentiate in your head whether something is a limitation of the language or a limitation of the problem. ("If all you have is a hammer, everything looks like a nail")
That being said, I do take his point that it is worth spending some time learning about things that aren't programming languages: testing, security, business, etc. After all, software development isn't anywhere near just programming. But really it shouldn't be a question of "do I learn this or that?". Read into things that you're interested in, or that would be useful at work, or just something completely different that will broaden your horizons a bit.
I don't think it matters particularly if that is a new language or not.
This really highlights the differences between trying to understand and formalise the theory behind distributed systems and trying to practically build and use distributed systems.
In a practical sense, bitcoin pretty much has the property of strong consistency. That is a useful thing for people to know and understand. However, none of the theory that applies to strongly consistent systems necessarily needs to apply to bitcoin, because bitcoin is not theoretically perfectly strongly consistent. This is also important for people to understand, as otherwise they may incorrectly assume that certain results apply to bitcoin, e.g. the CAP theorem, leading to confusion.
So, I really do believe it is important to differentiate between talking about the properties of distributed systems in a theoretical sense and talking about them in a practical sense. The current formalisations of distributed systems have mainly been built to understand the theoretical properties, which while can be useful as a starting point to understand the practical properties, its always important to note that distributed systems may have good enough approximations to useful theoretical properties for a particular use case.
I totally get this; federation is hard, and its so much easier and nicer ─ as a developer ─ to have a centralised service. Often centralisation is the right choice for a particular project, and I respect that.
That doesn't mean we should give up trying to federate things, though. The major upside (for me) to federated systems is simple: choice. Choice over the client you use. Choice over the servers you use. Choice. For something so fundamental as how we communicate over the internet that's incredibly important. I want to be able to use the app I want without having to figure out if the other person is using the same app, and i don't want to have to have 10 different apps on my phone just to keep in touch with everyone.
The reason I think that things like email and SMS are still so prevalent is how you don't need to care what service the other people are on, you don't need to worry about how other people are going to talk to you, it all just works. It's true that currently a lot of the email traffic is going through google, that sucks, but:
- If google discontinues gmail then your email still works, people can still talk to you. It's annoying you need to get the new addresses for all your contacts that used to use gmail, but that will get resolved quickly enough.
- A day may very well come where people decide another service is better, but then people are free to move there without having to try and convince all their friends and family to also switch. (Take browsers, for example, the browser that everyone uses to access the internet changes over time. And its great! People use what they want to use, the servers don't care, everything just works ─ well, more or less).
Not everything needs to be federated, often there are situations where its advantageous for there to be a central authority. (The blog post highlights a few of those situations). That's also great! People who want those things are then free to choose to use those things as well. Using 2 apps you want to use is still better than 10 you don't want to use.
Federation is hard, and it imposes constraints, but I really, really hope that we can build something that works before we give up and hand over all our comms to a particular company.
This is exactly why I work at matrix.org; I just want to be able to use the clients I want without having to care what everyone else uses. I don't even have to care if matrix.org goes down (except the fact I have to fix it), I can happily talk to other people since I connect via my own server.
I do actually agree with a lot of what's said, I just disagree with the conclusion. Federation iss hard, but it's just so worth it if we can get right.
Really? To me that sort of is the closest translation, but it doesn't really hit the nail on the head. But maybe that's just my weird linguistic background.
> Well that's just it, security is talked about but the buyer (the hotel in this case) is often not in a position to actually evaluate the vendor's claims.
But at least the buyer becomes aware that security might be an issues, and thus take it into account when making the final decision. (Even if its just "take the lowest bidder that talks about security convincingly"). OTOH, this doesn't work for buyers that don't actually care.
> You can put down "device should not be hackable" but without their own competent IT arm the hotel can't possibly verify the product delivers on the security promise.
Sure, but if the vendor puts this in the contract and the hotel does get hacked, isn't the vendor then suddenly liable?
Fundamentally, English is a flexible enough language that if any of these concepts became common enough they would become ordinary words (probably lifted directly from German).
This has actually happened, for example Blitzkrieg (commonly the "blitz"); now this does not simply mean "lightning war", it very much references a particular part of a particular war. Also, Zeitgeist is used in English, but doesn't simply translate to "spirit of the time".
Often such compound words mean more than the sum of their parts (as I guess the OP kind of meant), which is what makes them interesting to other languages. OTOH, it seems pretty rare these constructs actually describe something that English doesn't have a word/phrase for already. In fact, I would say that its not so much that German has such constructs in their language that makes them interesting, and more that as a different culture they have different words to describe different concepts.
Edit: I should probably point out that I am a native English speaker that can speak fluently Norwegian. "Ohrwurm" and "Wunderkind" are such nonsense examples in this case; they are literal translations (just without the space, and are understandable from any Scandinavian language), and they are pretty much anti examples. Using foreign words that mean exactly the same as the English equivalents is nothing but pretentious, and doesn't support his central argument at all.
Genuine question: Don't the other companies talk about security in their replies to the RFQ? Wouldn't that cause the original company to stop and ask the other repliers about the security they would implement (if they didn't mention security)?
I wonder if this is too featureful? What is the difference between +1, heart, and hooray? Having just a +1 and -1 is unambiguous and probably covers the vast amount of use cases? Perhaps not, but I'd be very interested to know the reasoning between being choosing between "unambiguous" and expressive.
[1] A terrible picture of the space, where the back of the clock would be on the left: https://i.pinimg.com/originals/e1/9b/1c/e19b1c997dc06c45e8b9...