seems to me a plausible reason why it might be silly
An alternative theory is that maybe 1Password defines unavailability in some nuanced way given their local-cache client model as well as this allegedly only affecting sign-in, with presumably anyone with a live session at 11:35 being able to use the rest of their API
Also, https://status.1password.com/incidents/3cqc0kx5qdzz is the actual thing, since clicking "history" takes some horrific amount of time to load, as a nod to the aforementioned "Atlassian Excellence in Execution"
I was under the impression that the 1Password database is synced and stored locally. If that is the case why would the servers having issues prevent logins to local databases, and not just the syncing of them?
Edit: It would appear the browser extensions can directly access the web interface without needing the stand alone 1Password application installed. As I run the standalone 1Password + browser extension, it can fall back on the locally stored database if the servers go offline.
It's not that they were preventing the local database unlock, they were preventing acquiring a credential to the server in order to sync any changes to/from the central store. As mentioned in a sibling comment, it's was also specifically the login endpoints that were labeled as bogus, so my suspicion is that any credential acquired before the incident may have continued to work
My 1Password for Linux was emitting `Some(Status=500)` on the console, so I'd presume they botched a rollout and then just rolled it back. Unknown why it took an hour, but maybe it's the old adage about 59 minutes to find the bolt, one minute to replace it
I don't know if 1Password/AgileBits publishes postmortems nor if they'd be of sufficient detail even if they did
5 comments
[ 2.5 ms ] story [ 30.7 ms ] threadseems to me a plausible reason why it might be silly
An alternative theory is that maybe 1Password defines unavailability in some nuanced way given their local-cache client model as well as this allegedly only affecting sign-in, with presumably anyone with a live session at 11:35 being able to use the rest of their API
Also, https://status.1password.com/incidents/3cqc0kx5qdzz is the actual thing, since clicking "history" takes some horrific amount of time to load, as a nod to the aforementioned "Atlassian Excellence in Execution"
Edit: It would appear the browser extensions can directly access the web interface without needing the stand alone 1Password application installed. As I run the standalone 1Password + browser extension, it can fall back on the locally stored database if the servers go offline.
My 1Password for Linux was emitting `Some(Status=500)` on the console, so I'd presume they botched a rollout and then just rolled it back. Unknown why it took an hour, but maybe it's the old adage about 59 minutes to find the bolt, one minute to replace it
I don't know if 1Password/AgileBits publishes postmortems nor if they'd be of sufficient detail even if they did