Because it's often a lie (at least in my experience). When I worked in defense contracting people loved trotting out stuff like "the work is stable", "you can't get fired from a government job", etc. all while dealing with furloughs, government shutdowns, geographic consolidation of work to different states, contracts changing hands, companies being acquired, etc. Employment in the US is at-will and nobody is going to guarantee you a job, especially these days, and employers at the lower echelons of the industry are very fond of selling the dream of "stability" by sowing fear of the unknown to prevent attrition while building a culture of malaise and low compensation.
I'm not saying that one should work exclusively for seed-stage crypto startups that sell blockchain-verified probiotic dog food or anything, but at some point you should critically examine whether it makes sense to be someplace that's 10 years and tens of thousands of dollars behind the curve just because it's "stable" when it so obviously isn't.
...where did I say that it was? They're both in the same space (figuratively and sometimes literally) and both of them have the same problem insofar as they aren't as bulletproof as they're made out to be. You can, in fact, be fired from a government job and things like the government shutdown circus and BRAC are real.
My apologies if I misinterpreted. I assumed it was tied together with this:
> When I worked in defense contracting people loved trotting out stuff like "the work is stable", "you can't get fired from a government job"
It's truly a shame that the employees who keep the government glued together -- be it via direct government employment or contracting -- are subject to unnecessarily turmulous conditions because of one political party's antics.
You’re likely better off getting a job that pays better, but being laid off more frequently.
If the layoffs never happen, you’re in a massively better position. If they do, the extra income still puts you ahead of staying at a stable, but poorly paying job.
Yup. Maybe this was true in the days of the 50s or so when the boomers entered the workforce and where "retired at 60 after 40 years working for the same employer" was something of a norm, but it definitely isn't the case nowadays. You can have a great job with a great team doing work you enjoy for what seems like the most stable situation known to man (large company in a boring industry or a government department) only to find yourself out on your ear when the economy hits a downturn and your whole department gets laid off.
That's what happened to me in the last set of layoffs, along with many other people.
May as well try and get as rich as possible as quickly as possible instead.
Rocket is a delight. Been using it for a year now and the docs and dev experience and stability are all exceptional.
Request Guard Transparency[1] is something I’ve only seen in Rocket:
> When a request guard type can only be created through its FromRequest implementation, and the type is not Copy, the existence of a request guard value provides a type-level proof that the current request has been validated against an arbitrary policy. This provides powerful means of protecting your application against access-control violations by requiring data accessing methods to witness a proof of authorization via a request guard. We call the notion of using a request guard as a witness guard transparency.
Basically your endpoints can require access to a protected service via a parameter and you’re guaranteed that your code will only execute for valid&authorized requests. For example, imagine a UserService and a TeamAdminService, each with their own methods appropriate for their user type. Request guards are used to validate the request headers and database entries are correct before constructing these services. And since you can only construct them from a request, simply having a service listed as a parameter in your endpoint guarantees that the proper access control has be enforced before your code runs.
We’ve structured our app so that every sensitive operation goes through these services, thereby sidestepping entire classes of security concerns and missteps. I sleep better as a result and our security reviews are much more enjoyable.
I’d love to see this discussed more and adopted by more frameworks.
I agree providing the Secret Key to other devices can be a pain. In fact it's our #1 onboarding challenge. On Apple devices specifically it's much easier as we can store it in iCloud Keychain, but we'd like to make it simpler everywhere.
Curious if you've had a chance to try the Setup Code? It's not as slick as iCloud since we don't own the OS, but it enables you to scan the code and get all the account details on your new device. That way all you need to do is type your password.
On that note we recently had a hackathon around this to make things even simpler and we had some success there. I'm hoping we can make this real and share it in an update later this year.
I'm sorry it comes off that way. We don't mean any disrespect in the slightest. Your support over all these years means the world to us and we know darn well we wouldn't be here today without awesome customers like you. <3
I left a comment just above yours that I invite you to read. I don't want to repeat it in its entirety here but suffice it to say we're excited about our hosted solution and yes we can find ourselves shouting from the rooftops about it. Kinda like newlyweds I suppose. :)
Ok, so go back through your forums and threads like these and read all the "how do I get standalone" questions throughout the last 5-6 years and tell me honestly that the awkward non-answers are just you guys being excited about your hosted solution. It's evasive. I'd feel a lot more mutual respect if you'd drop the charade and just say "yeah, you guys aren't really our primary use case anymore and we're not really planning to support you. Sorry." Making us read between the lines while you play coy games like saying "well, it's not advertised, but it kinda works on some platforms" is insulting.
Thank you for supporting us all these years! We wouldn't be here without awesome customers like you. <3
As a long time user I bet you remember when we needed to write posts like Two Factor or not Two Factor[1].
> One and a Half Factors?
Good times. :) Thankfully with our own service we are now able to provide real 2FA as our server is able to enforce it. Same with family sharing, team environments, automated backups, item history, account recovery that only your family organizers/team admins can perform, along with simple invites and easier device setup.
And it's not just new features but we can make existing ones better. You probably have seen your fair share of Conflict Resolution windows and weird sync issues over the last 10 years. Sync is a hard thing to get right and being able to rely on a server to give specific responses in specific situations has enabled us to provide a much better experience than we ever could with a generic file service.
The reality is 1Password is better than it ever has been as a direct result of allowing our developers to work their magic on both sides of the network connections. Server and client.
It's a bit dated now but I wrote From a Happy 1Password Maker[2] back in 2017 that highlights a lot of things we love about memberships. In it I explain why I'll continue to non-apologetically nudge everyone towards 1Password Memberships.
For what it's worth, not a single one of those entries in the "no more" list appeals to me in any way. I've never complained that I lost my master password, or that the license didn't work on multiple platforms, or that I accidentally deleted my files. I don't feel the need for 2FA because -- and this is a big deal to me -- my password database isn't online. I know how to do backups. It's simple and self-contained. I can use it at work where policy prohibits online password management. I don't have to worry that I'm getting continuous "new features" updates that are going to change my working environment outside of my control (I can still roll back to v6.0 if I want). I don't like external dependencies. This is a much, much greater concern to me than the "niceties" you mention that literally bring me no value. So please, stop acting like you know better than your users. You may have the 90% case nailed but you're just pissing the rest of us off with your attitude.
The problem here is how many services have been moving to forced 2FA lately (presumably because their users keep getting their re-used passwords leaked).
I'd move to 1Password (from KeePass) just to deal with these obnoxious 2FA requirements - except many of them, adding insult to injury, are SMS-only. (Feature idea for 1Password? Assign me a phone number that will automatically consume SMS 2FA codes and type them into browsers for me?)
Oh, I regularly use 2FA on individual sites. I just don't see the point of using 2FA to access passwords for sites which, if important, have 2FA enabled themselves. 4FA?
Yup! Since the very beginning in 2006 Roustem and I wanted to make sure everyone used 1Password because they enjoyed doing so and not because of being locked in.
I'm happy to hear our export worked well for you. We spent extra effort there to make sure our export format contained enough structured information that it could be imported properly elsewhere. I hate data lock-in and we wanted to make sure you wouldn't be locked into 1Password.
