Since it doesn't appear to possible to reply to your answers: thank you all!
To single someone out, @jpgoldberg has some lovely in-depth answers.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Thank you very much, @nils_enevoldsen!
Some of the questions were submit early, so I was able draft answers at a more leisurely place. (I type very slowly.) I also got to cherry pick questions that I thought I could say something interesting about. So I had a great deal of fun with it.
For those who missed it, see our AMAFeed session
Unfortunately that site looks terrible in a mobile browser on an iPad.
Is there some way to get a mobile friendly version?
I had a similar experience (I primarily work from an iPad Pro). I’m unfortunately not aware of any alternate interface available on iOS.
Had you been listening the internal call among all of us answering the various questions, you would have heard us struggling to deal with the UI and design of that site. That involved a fair amount of profanity. I didn't swear that much, though; instead, I would just whimper.
Yes, I was frustrated by how hard it was to find my own question. Oh well.
I don't think you were the only one. But I found it fun to read everyone's nevertheless. :)
I was able to read this on my iPad Pro 10.5” using iCab Mobile and one of its modules (to fake the screen size).
Interesting stuff! In particular the info we usually don’t see here at the forum, like questions/answers about the company (and way of working) instead of the product.
In fact I now feel like I missed an opportunity to ask those kind of questions myself...
Most “burning” question:
What kind of security measures are taken for working remote? (Do all developers use a VPN? Does that require 2FA? Are they using a laptop/desktop that is only used for work?)
Our internal Security Manual is an evolving document and I expect that our VPN requirements will grow laxer as the need for them is reduced. We require a VPN for accessing some of our systems, but not all. We "strongly encourage" a VPN when working from untrusted local networks (hotels, coffee shops, etc). But while those networks may remain untrustworthy, we mostly just insist that people use HTTPS strictly for everything and be very sensitive to browser warnings.
TLS1.2 with HSTS dramatically reduces the threats that a VPN also reduces. And I'm looking forward to deployment of TLS1.3, which will make it even harder for malicious actors on a network to do things.
We do use 2FA for a number of our services, but we recognize that if you are using a password manager well, the claimed value of 2FA is small. However, various 2FA schemes have other value, particularly for those managing access.
Because we have built a system based on encryption over authentication, we don't have as strong security requirements as others. If my communication to our systems is compromised, the damage that the attacker could do is limited because we've built the system to constrain my power. This is not to say that we ignore such threats, but it means that "access" isn't really as big a deal as it would be with other architectures.
We still allow BYOD but have have requirements on those systems (full disk encryption, system updates and software, etc). Probably the most annoying thing that we impose on these is that when using a web browser to deal with our own "back office" system, that the browser does not have any (unapproved) third party extensions installed. We are gradually moving toward "managed devices", but it is a slow process.
One thing that is important about policies like this is that they be regularly updated. And updating involves removing requirements as well as adding them. We developed our policy with the recognization that if it becomes too burdensome people will find ways around it. I would rather have people come to me and tell me why some requirement is a problem for them so that we can work out a solution that meets the needs of the case.
It is because people can and do ask about such things that we can be confident that these are being followed without us having to employ burdensome enforcement mechanisms. At the same time, where we have policies that we cannot reliably enforce, we have to design our overall systems with the expectation that compliance will not by 100%.
We've looked at the policies and guidelines of other organizations and recommended by compliance auditors. Our over all impression is that there is no way that a person could actually comply with those and function. Those policies appear to have been written to satisfy some requirement without a real expectation of compliance. That is what is called "CYA Security" (Cover Your ...). Those documents aren't designed to secure processes, but to place blame after something goes wrong. We, on the other hand, want to design our policies to genuinely help people behave more securely.
I should add that we have very tight access control. For example, I do not have any access to the backend database. Only the very tiny handful of people who really need that do. Likewise, I have read access to lots of source repositories, but limited write access. Just because I'm responsible for much of our security doesn't mean that I have access to everything.
So while, of course, I must protect my devices, compromising me or my devices would not immediately give an attacker the ability to do much damages (beyond the embarrassment). This is another example of what I meant when saying that we've designed the system so that we ourselves have limited capacity to do damage. This in no way means that we can ignore operational security, but it does mean that we don't need to enforce extreme opsec. The requirements on the people who can actually tamper with the back-end database are much higher than they are for your typical remote worker.
Thank you for taking the time to present such an informative answer!
On behalf of Goldberg, you're most welcome. And...well, I enjoyed it too. :)