I installed it and will compare it to Lastpass (which is pretty good IMO). HOWEVER, it saddens me to read on the front page: "using 256-bit encryption". I'd really expect the competent people at Mozilla to know that this statement means next to nothing. At the very minimum I want to know:
1) HOW is the key derived (say, "derived used PBKDF2 on the Firefox username + password")
2) WHERE is it encrypted (I assume "encrypted on the device/end-to-end/zero-knowledge"). It needs to be clear what the attack vectors are.
3) HOW is the secret managed (say, "Secret is wiped on all application switches")
and probably more that I forgot.
Using the app, the first thing I noticed is that I have a LOT of duplicate entries but no obvious way to clean that up.
EDIT: I see most of these details are on https://blog.mozilla.org/services/2014/04/30/firefox-syncs-n... but it doesn't change my disappointment in the totally useless "256-bit encryption" statement. Just say "strong encryption practices" and provide a link to the details. 8,192 bit encryption doesn't help you if you don't manage the key well.
Firefox Lockbox architect here. Thank you for the feedback. Your comment is fair; we can, and will, do better on the details. The language we have today is the balance marketing, security reviewers, and engineering could reach for the masses to feel informed without being overwhelmed and confused.
As you found, Firefox Accounts derives the encryption key from your username and password on the client-side; the server is never aware of your password. That encryption key protects your data on your device using AES-256-GCM, and is stored in its security enclave behind Touch ID or Face ID wherever possible.
>The language we have today is the balance marketing, security reviewers, and engineering could reach for the masses to feel informed without being overwhelmed and confused.
It would be fantastic to have a 'more details' page, where the nitty-gritty is detailed for those who care.
Maybe also compare this service with other cloud password managers. It's not easy to understands the pros and cons of each of them. Is this a better service than existing managers and if so, in what way?
I, too, want to know the implementaion details. That said I’ve watched hundred of eyes gloss over as I emphatically implored lay-persons about password policies and tools like password managers and Frankly their definition of ‘secure’ can be encapsulated in ‘256-bit encryption’.
An oversight on Mozilla’s part for security-types and engineers, but maybe they have the masses in mind with this tool & it’s marketing site.
Maybe the ship has sailed, but I would prefer laypersons not associate the phrase "256-bit encryption" with anything, and would much rather one like "strong encryption practices" if it's a link to the technical specifications. They have no basis on which to evaluate what 256 bits of anything actually mean, so using it as a technical term to throw at their face intending for them to latch onto it as a valuable metric is actively harmful. What if it said "Strong 256-bit RSA encryption". To you and I that phrase should send off alarm bells, but a layperson might actually rank that as more secure because of the added technical jargon. You've just taught them to trust random technical-sounding security jargon so adding more jargon makes it sound more better.
It's probably way to late to make any difference here, but I still wish mozilla could push the boundaries here.
yeah, but if I'm rotating a 256-bit key using XOR, is that really secure? It's 256-bit encryption, but about the weakest thing I could possibly do short of plain text.
Not at all! But that’s what all the other security whitewash on financial and ecommerce sites say, so to most folks it, like, totally means it’s really really secure— pinky swear!
I'd guess for that page the technical details get fed to marketing who boil it down to whatever they think will impress people with limited (if any) technical knowledge.
For Mozilla to be successful they have to appeal to the largest demographic possible. I'd only ask that Mozilla make additional technical information easy to find and well laid out.
Instead of making password management modular, so any password manager capable of certain queries and operations (KeePass, LastPass, Bitwarden, KWallet/Gnome Keyring/libsecret, Microsoft Credentials Management API, Apple Keychain, etc) could become a storage backend with some programming effort... they're doing the exact opposite - they've created yet another password manager UI and yet another proprietary data format (Lockbox Data Storage) for that purpose.
Seriously, I doubt many (if anyone) but Mozilla management needs or wants a Mozilla-branded extra ecosystem, in addition to Google, Apple and Microsoft-branded ones - yet another piece of software that doesn't interoperate with anything but its own unique data formats and protocols.
I don't know what others want, but I want a good browser that I can hook up with things I already use.
Different definitions, I guess. I call it proprietary because it's:
- Unique to Mozilla products. Invented there (disregarding any existing solutions of the same problem) and no one else uses this.
- Based on Accounts and Sync I believe this is not a standard at all, just something that happens to be documented. With FxA&Sync there are a lot of undocumented subtleties and things sometimes change at whim without any warnings. If you make an independent implementation, you're bound to be always catching up, just like it is with any other proprietary protocols.
It's "open" because it's documented and the implementation is FLOSS, but it's also "proprietary" because effectively, Mozilla is in full and ultimate control of this stuff.
They are on day one, sure, but if the file format is documented and clear then there's no reason why other managers couldn't interoperate. It's not as good as using an existing standard, but I'm not sure there is _an_ existing standard right now.
> I'm not sure there is _an_ existing standard right now
I think there is none, except for the OS-provided APIs (but those have complications of their own, e.g. Chrome had dropped Apple Keychain support for a reason).
> there's no reason why other managers couldn't interoperate
Why would they? I don't think anyone was invited to this party. And I find it highly unlikely someone will bother to interoperate beyond implementing an importer tool, because it's likely that no one wants to spend resources on alternative implementations just to be in dependent always-catching-up position.
Seriously, I absolutely don't see how this could become a standard. I've called it proprietary not to badmouth it, but because it is Mozilla's own, unique stuff and is very much likely to remain so.
I believe if someone wants to devise a standard for something, they call for everyone having their in-house implementations, asking if they want to interoperate. Many won't bother, but some may like the idea. Then, a specification is written, and conforming implementations follow.
That isn't what proprietary means, though. Every criticism you level at this file format _can also be levelled at the others_. There's no way around that at this stage. The only way mozilla could not have caused that problem is to not have built anything like this.
Password manager storage/exchange formats? Sure, there are no standards at this point. Arbitrary formats or protocols? Certainly not. Similar cannot be said about e.g. HTML/CSS or WebDAV or OpenPGP - even though there are enough incompatibilities, deviations and proprietary extensions.
> The only way mozilla could not have caused that problem is to not have built anything like this.
Of course. I don't think anyone needs yet another password manager, for there are a lot of options already (although many lacking one thing or another, but it's not like Lockbox is going to be the perfect one).
Mozilla are in touch with standard bodies, like W3C. They are participating in development various authentication protocols like FIDO2. Surely they can raise a call for other password management software vendors to devise a common API. Some would not want one (besides importing into their product), some would enjoy a capability to concentrate on some parts of the product but leave others to compatible third-party implementations (e.g. backend/frontend separation).
It's not a bad thing, of course, to build another password manager. I just don't see anything good about this, either.
While a lot of Mozilla's work is great, this seems to be the tendency of every "Test Pilot" project I've seen; NiH and always a reimplementation of ideas there are plenty of alternatives for already, without much consideration for learning from/interop with those alternatives. It's a bit odd: it all seems quite separate and "distant" from the core work I expect from Mozilla.
I think someone in their management has/had a vision of Mozilla as an ecosystem brand, just like Google or Apple. They must've felt big enough to pull it, providing users with all things Firefox (think of Firefox Account).
They hadn't succeeded and had cancelled Firefox OS, but at least the inertia is still there, if not the continued effort to push in that direction.
Seriously, if you put Mozilla in the same box as Google, Microsoft and Apple, then you are ignoring company culture completely.
Yes, I want a big privacy oriented, non profit organization with strong engineering practices to handle my passwords. This is not Google, Microsoft or Apple.
I only wish Mozilla wasn't American due to the insane laws about "national security".
I'd love to be wrong about this, but I don't see them as privacy oriented - only marketed as such.
Mozilla made it harder for me to handle my passwords. In their effort to not lose market share and to market themselves as ecosystem rather than a browser vendor, they did horrible things to their password storage. Sync1.1 was tolerable. Accounts+Sync1.5 is an abomination. It's bloated beyond reason, full of weird protocols and formats mixed in odd ways. I'm not even remotely a strong engineer but I can't call what Mozilla made there "good engineering".
And I spent some time writing my own implementation of Accounts and Sync, so I believe I can assure myself my opinion is not completely baseless but relies on some first-hand experience (my crappy code is not good engineering - but neither I claim it such)
OpenKeychain and Password-store (paired with a yubikey) is the entire reason I use Android over iOS. I really wish there was hardware GPG key solution for the iphone.
I've been using pass with a yubikey for the past year and a half and have been very happy with it. The ability to call out to the pass binary in personal scripts is a really handy feature that I didn't realize would be so useful until I started using it.
I've been working on this distributed offline-first datastore that uses the Git protocol as the network layer. I'm calling it GitDB (but the Git trademark is getting more strictly enforced these days so that'll need to change).
The idea is that we should be able to build tools where the user can understand and manage where data is stored while at the same time keeping many of the conveniences of modern apps, like cross-device sync.
As a user, you can decide if you trust Github, Gitlab, Bitbucket, etc. and pay them to host your data.
The first tool I wanted to build with GitDB was a password manager but seeing this post made me wonder if there would be enough people who wanted this level of control over data, does this sound like something you'd be into?
This work is all super early, but would love to gauge the interest from others.
If this is any good I'll be considering it as a replacemnt for Keepass.
A bit off topic, but while looking at this I noticed another expirement - Firefox Side View. It looks like it lets you have two open tabs side-by-side in one browser window. This is exactly why I used the Tile Tabs[0] extension and had to switch to Tile Tabs WE[1] with the Quantum update. I'm happy to see this coming back without the WE workarounds.
The reason I haven't switched to Keepass is its very decentralized nature - not in terms of how it stores data, but in terms of it being a format not a unified set of tools.
Maybe I'm misunderstanding it, but it feels to me like I can get Keepass (v2.x or v1.x) for Windows from a somewhat-official source. I can also run that v2.x on Linux or OSX via Mono (via the packages on the download page?), or I can use any of 4 unofficial OSX ports or 2 unofficial Linux ports, plus any of several unofficial browser ports, plus an unofficial webserver based port, plus 3 unofficial Android ports or a bunch of unofficial iOS ports. It's not clear to me how many (if any) of these are actual "ports" of the software not "reimplementations of the file format," nor is it clear to me whether any or all of them are audited (or who's doing that if they are).
Basically, massive fragmentation and independently developed clients in the software that I'd use to store all my passwords behind a strong master key creeps me the f out. I don't have the time, math or detailed language knowledge to personally audit a bunch of cryptography implementations in a bunch of different languages and I know it, and I'm not sure I'd pick up any obfuscated transmission or concealment of security/decryption information, but I also don't feel like I have a trustworthy source that I know is doing that auditing.
I use Android, Linux (at home), and Mac (at work). I switched from KeePass because the UI was really bad, it seemed dead, and I really didn't want to move to KeePass 2 (with Mono on Linux). I switched to enpass, and it's been great. It has native Linux/Mac/Windows apps, a solid Android app (with fingerprint support), and there's no subscription. It's perfect for my needs.
The browser extension leaves a lot to be desired though. I feel that there are a lot of good standalone password managers, but the ones with good browser extensions are far fewer. I'm using bitwarden right now, which so far seems to be the best of the open source ones in terms of usability.
Hm, enpass seems to be closed source which makes it unusable for me to store all my passwords basically because of the same as someone wrote in their forum:
"The fact that Enpass isn't submitting all my passwords to enpass.io right now doesn't mean anything. I'm currently using iptables to restrict Enpass from doing so, but I don't know yet how to archive the same thing on my unrooted Android."
That's the problem I have with all of the commercial password managers: I simply don't trust them.
I find it incredibly telling that every big password manager has a mandatory, binding arbitration clause in their user agreements. This tells me that I am supposed to take their word on everything yet I have zero recourse to a neutral third party if the password manager company leaks (or intentionally hands over) all of my passwords.
Unfortunately, I have a similar issue with things like Keepass - perhaps the core project has enough eyes on it, but how about all those "Contributed/Unofficial KeePass Ports"?
Totally reasonable. I figure the people who write the unofficial ports I use have a personal reputation to protect. It bothers me a lot that the "professional" password management people disclaim all of their liability and just expect me to hope that it works the way they want.
I kind of figure almost the opposite - those commercial entities have both the resources (hopefully) for subject matter experts and auditing (also hopefully) and a strong financial interest in not having a disclosed breach (and almost all significant breaches are likely to be disclosed/discovered at some point). On the other side a small development team of individuals seem (to me) less likely to have the resources and more ability to simply walk away in case of a breach.
Because they don't offer to save your passwords the breach can always just be if someone attacks your personal computer, which is so much less likely than that someone tries to attack a company which hosts thousands or even millions password databases.
In the open source world you have at least the possibility that someone who you trust looks at the code, with the closed source you don't.
Ot: Shouldn't your window manager handle this ? Consider using i3wm if it does not.
Does this work seamless with other web extensions ? As a webextension developer i do not know how those tabs will be handled. I do not see any benefits using this.
I am a fan of the quality of dev the Firefox team has, and am sure they have thought this through very deeply. For trust and security, it would be helpful if that were reflected in the specs as well as the final product.
I was the architect for a solution solving a similar problem some years ago, and then, as apparently now, the key derivation scheme appears to be a bit of a shell game. Was just reading this and trying to get a picture of how someone could reason about trusting it. This doc specifies four symmetric keys, where two are used for encryption, and two are used as salts.
The salts are derivations, which are hashes from data elements
So simply, we have:
FxA credentials: a string or blob to be determined.
f: some function tbd
k_pre: a bootstrapping scheme initialization key.
k_enc: keystore key.
k_salt: a user-bound diversification component
k_item: a key to encrypt an item within the encrypted container, or "lockbox"
Some definitions:
k_pre :=(f(FxA))
k_enc := (f(k_pre))
k_salt := KDF(k_pre, userid, infostring, length)
item := KDF(k_salt, k_enc)
Question is, what is FxA? Best thing could be is an HSM key with a user-bound diversification component, with some kind of secure provisioning protocol to get it into the device, but from what I can tell from the docs, there are still some exercises for the reader.
What wasn't clear on first reading from the architecture was the protocol they use between where the lockbox is stored, and where its components are used. When I did this, we used a variation of OCRA to prove possession of correct keys and their versions and release verifications for "items," (attributes).
The next useful documentation step would describe a sequence like:
A -> B: init msg
B -> A: challenge
A -> B: (userid, key version, HMAC(k_pre, challenge))
B -> B: derives k_pre(userid)+ HMAC, validates
B -> A: challenge'
A -> B: etc...
Not to be a pedant about this stuff, but to be able to reason about the things we can trust it for, there are some things we can't be handwavy about.
If I'm already using Firefox on Mac, Windows & iPhone, what advantage does this bring over just opening the Firefox app on my iPhone and looking in Settings > Saved logins? Seems to me to be exactly the same, am I missing anything?
It's faster. It syncs. It's safer than firefox passwords manager. It unlocks integrates better with the OS (unlock with fingerprints or face). You can use it for something else than websites.
However, it's still nowhere as convenient as lastpass.
I paid a one time license fee of 1Password, then I use it offline on laptop and iPhone. I sync them through wifi regularly.
This offline use option is not very disclosed on the website but it’s possible and in my opinion it’s more safe.
I’ve tried open source password apps but the problem it’s they are all from independent developers. These developers can’t afford security reviews and I can’t tell if the version on the App Store is the same of the version on GitHub. If there’s a vulnerability and passwords leak, a company can be legally responsible, it’s not the same with independent developers.
And it’s not practical to install an app and its updates from source on iPhone. So I went with the closed source 1Password because it’s a big company and everybody is looking at them.
A little pricey, but I've got important data in it and I use it every day, so at the moment I consider it to be worth the ~36 EUR per year. Previously a standalone license user, I've finally switched to their subscription model. Some people are afraid of storing that encrypted data on their servers, however I don't see the threat model as being any different than synchronizing with Dropbox, which I was doing anyway, plus it makes it easier for me to have a digital last will for my family.
Keepass' copy&paste/autotype always felt like a hassle to me and also a bit insecure. When I was looking for alternatives for Keepass 2 I discovered the Kee [1] plugin for Firefox which communicates with Keepass via the RPC plugin. It's great and made me stay with Keepass. Login fields are automatically filled reliably without any issues. Registering accounts is easier too: just choose a username, let Kee generate a password, submit the form and then click the button to save the entry - all without having to use the Keepass UI at all.
I have in the past, but not written it down. My criterion was:
- FOSS (totally indispensable)
- Offline (totally indispensable, data you put on others' servers is not yours anymore)
- Can be used from the CLI as well as some interface
- Can be synced to Android
With this, you have 2 options: pass, or keepass. The latter is a bit confusing, w/ many apps around one format and it's hard to know which one to use. Also the file format is proprietary, which means it's harder to use from scripts.
pass on the other hand uses the filesystem, gpg and git, which are tools I always have around and know how to use. It's totally FOSS and totally local (Keepass is like this too), it's version controlled by default, can use it on android w/ Password Manager and OpenPGP apps (available from both the play store as well as FDroid), and it's easy to script (I've written my own Emacs fronted in no time), and while there are many third party frontend apps, there is one program that's blessed by the community as the default one, which is the pass(1) cli.
One criticism on pass is that it leaks metadata because the file names usually contain the website domains. I think that's a non issue because usernames and websites are already known by many other parties (the website itself, and millions of people if it's sth like a social network), and we should not rely on hiding public information for security. Use long passwords and 2FA where available. But encrypting your hard drive would be more secure in the first place anyways.
I specifically use keepassx and v2 format keepass file db, separately, because it is not integrated with any browser via extension or plugin. Keeping things compartmentalized reduces risk in my opinion.
And unless I copy the locally stored .kdbx file somewhere manually, it has zero interaction with any network, cloud based service, or third party beyond my control.
I was tired of browser plugins that just didn't always work quite right.
Keepass, on whatever platform using whatever client, just uses the clipboard. 100% chance of working, although not safe against certain types of spyware.
It's not all clipboard based - Keepass has an RPC plugin that can be used with browser extensions for Firefox and Chrome. I also use Keepass2android for (duh) Android, and while you can use copy/paste it also has a custom keyboard you can use instead.
> Keepass, on whatever platform using whatever client, just uses the clipboard. 100% chance of working, although not safe against certain types of spyware
On Android the preferred way of using Keepass is with custom keyboard, which protects against clipboard sniffing.
> Has anyone done a thoughtful comparison of PW managers?
I think a valuable comparison would not be of features but of the security, and therefore a person comparing them would need real security expertise. I'd worry about bad information from non-experts. In the past, at least some security experts on HN have recommended 1Password.
All these people storing all their secrets in one place creates an exceptionally valuable target that I expect, IMHO, will attract well-resourced attacks. Find a way to crack Lastpass, and imagine what you have - it's the ultimate breach (and if you are smart, nobody will know).
To be a net gain in security, a password manager needs very effective security for itself. If the user wants something to ease the burden of managing all those exposed passwords, then perhaps features are the issue.
There is a surprising lack of unit tests in Bitwarden, which is mostly maintained by one person. If Mozilla can apply its rigorous engineering practices to maintaining an open source password manager with all the features I use, I will switch from my current system.
Love it. I don't love using LastPass, but I don't want to deal with the rough edges of KeePass either. Looking forward to the Android app. +1 for autofill API.
The need to use a third party plugin to get any form of cloud sync working for one. Minor weirdness with it scrolling through your secret share structure on the left instead of up and down your passwords if you have accidentally clicked over (a feature that acts more like a bug). The lack of ability (or at least any documentation) on how to use something like Google Authenticator as MFA for the database.
The external sync is a feature for me, not a bug. I can use whatever tool I want to sync between my devices (I use Syncthing) and do not need to trust some company with storing my stuff on their servers and not fiddling with them.
But it has certain connotations in many cultures, which is not positive. I too like them and know they aren't a part of our value system, but naming a security product that is meant to protect your valuable stuff "fox" is like calling a bank Robbers&co.
From the link, it claims that this "gives access to all the logins you've saved in Firefox", but I thought it was common knowledge that in-browser password storage is insecure? [0,1]
If so, then this doesn't really promote much confidence in a product that appears to be a password manager. If they've addressed this issue, then that should probably be explicitly stated, although I understand the difficulties of that from a marketing perspective.
Maybe the reference to 256-bit encryption is a nod to this, with the expectation that those unfamiliar with the problems wouldn't be familiar with the differences between plain-text and encrypted storage?
Regardless, I think it's pretty promising that a browser is addressing this problem head-on, rather than leaving it to third-party companies to solve in a cross-platform way.
> (If you don't use a master password, which isn't required, I believe?)
When using a cloud-synced password vault that lands on the servers of a third party (this includes Firefox, Google, 1Password, Lastpass, etc.) you must always assume that the file itself is compromised; the only thing between an attacker and your passwords is the encryption by your master key.
I seriously doubt that Firefox Lockbox will allow you to cloud-sync your password file without setting a master password. *
Note: One of the first things malware authors typically go for is the password vault stored in browsers, but this is only because it is commonly used without any master key set.
* It might depend on some key derived from your account password, if you haven't observed the requirement of a master key. Not sure.
> I seriously doubt that Firefox Lockbox will allow you to cloud-sync your password file without setting a master password.
The current Firefox Accounts protocol simply encrypts a master key with a key derived from the account password. That's not terrible, although it does mean that account passwords must be cryptographically strong. However, Firefox Accounts can be logged into from a webpage which executes JavaScript served dynamically, which means that Mozilla, a Mozilla employee or any government or organisation which can compel Mozilla or Mozilla employees can serve targeted JavaScript to you to steal your master password, and then silently read your passwords. As such, Firefox accounts cannot be trusted with high-security passwords.
(Yes, you have to trust Mozilla to run Firefox at all, but it's significantly easier to hide a single download of a compromised JavaScript file than it is to hide a compromised Firefox binary served to the world)
If you are a likely target for a government entity with subpoena power you have much bigger problems than your Firefox Accounts password. The problematical scenario is that Mozilla is remote compromised by some bug or poor opsec and criminal entities will serve compromised JS. Since this has literally happened to basically every kind of organization out there, it is virtually certain to happen to Mozilla.
The problem is that Mozilla is aware about the issue for years, yet is not doing anything about it, even though the auth protocol is stable and documented. Okay, I get it that they may not want to rewrite already working parts of the browser - but even in this new Lockbox project they're using a WebView to log in to FxA.
<fud>Maybe they're already breached by highest-profile actors like NSA?</fud>
On problem with password managers (that are using web authentication to create/manage an account for backing up the password manager in the cloud) is that the authentication password can be leaked during the authentication process. For example, the storage provider for password manager backup can simply read the password from the authentication web page since this web page is hosted at the provider. This is problematic if the authentication password is also used to encrypt the password manager, i.e. the provider could decrypt the password manager with the authentication password. You would actually need two passwords; one for authentication and one for encryption. Unfortunately, you usually don't even have the option to choose two passwords.
To solve this problem I'm working on FejoaAuth (https://fejoa.org/fejoapage/auth.html). FejoaAuth uses an authentication protocol that does not leak the user password to the provider who is going to store the password manager. This protocol is run in a trusted browser plugin in order to ensure the correct execution of the protocol. Thus you can use a single password for authentication and password manager encryption.
So can someone expand on this a little? What are the differences between this and something like LastPass (other than this isn't an add-on). Does it provide app autofill? Does it prevent the same plain text decoding that browser password managers typically have? Is this useful? I'm legit asking because I don't know and would appreciate a security person chiming in.
Nice, will check it out! FF is already my default browser. One question though, is there a good way to import from other exported sources such as LastPass or KeepassXC?
I appreciate the vote of confidence but I was hoping someone from the team could chime in or someone who took the time to try it out. Based on other comments in this thread it looks like it may just rely heavily on copy/paste.
Are Firefox passwords encrypted on the client? I currently use (any pay for) Bitwarden and I like that the code is open and my data is encrypted on the client and only synced with the server. I'd like a similar service from Mozilla, but don't know how the encryption is handled.
as others have said, it's encrypted if you enable the "master password" option; however, the ux of the master password is miserable:
* the prompt for entering your master password is a simple dialog, with "ok" and "cancel" buttons. a website could probably trigger an identical prompt with javascript to phish your master password.
* the prompt pops up once when you first start the browser (about 15-30 seconds after everything is loaded) and then (if you dismiss it with "cancel") again each time you visit a site for which you have a saved password. there's no way to trigger the unlock prompt on-demand.
* the master password doesn't have a timeout. once you've unlocked the keychain, it remains unlocked until you restart the browser.
don't bother. stick with whatever third-party extension you're using.
If you have master password set in the browser then the password db is encrypted locally. I remember there being some noise about it not being very secure encryption, so better check the details if that is critical for you. As for the Firefox Accounts/Sync stuff, afaik MozCo servers see only encrypted content.
One of the ideas I had once was to build a client for Firefox Sync, either as a plugin for Keepass or as a native standalone application (that could possibly sync with Keepass database). While this does not exactly match such use, it kinda still is a step towards that direction.
A history of shutting down site-identity related products, no less. [1] The fact that it's not on Android as of day one looks pretty bad too; the sort of developers who think iOS obviously comes first are (in my experience) likely to be chasing hype and their apps are dead in a year (or at least still not on Android). I don't know if that's the case here, but I have no interest in using this until it's been adopted by Mozilla as more than an experiment and has several years of strong support.
I haven't looked in to it, as I'm not an ios user, but Mozilla would be very stupid if this isn't end to end encrypted. And as far as I know Mozilla typically isn't stupid.
Is this a Firefox password manager or a general password manager with integration with Firefox? Should I expect to be able to replace 1Password with it for instance. If I can't then I have no motivation to have two password managers.
Unrelated, does this page implement it's own custom scrolling? I get some weird rendering bugs when scrolling too, very stuttery.
Honestly, the region shouldn't matter. If you want you could add a little notice that it's English-only for now, but there's absolutely no reason to limit this to a particular country. It's a totally free service and it doesn't involve complicated region-specific licensing agreements, so where someone lives quite simply does not matter.
I hope you are aware of the fact that language and geography most of the time don't match because one person is capable to speak/read multiple languages and that English is understood by people outside of the USA?
1) HOW is the key derived (say, "derived used PBKDF2 on the Firefox username + password")
2) WHERE is it encrypted (I assume "encrypted on the device/end-to-end/zero-knowledge"). It needs to be clear what the attack vectors are.
3) HOW is the secret managed (say, "Secret is wiped on all application switches")
and probably more that I forgot.
Using the app, the first thing I noticed is that I have a LOT of duplicate entries but no obvious way to clean that up.
EDIT: I see most of these details are on https://blog.mozilla.org/services/2014/04/30/firefox-syncs-n... but it doesn't change my disappointment in the totally useless "256-bit encryption" statement. Just say "strong encryption practices" and provide a link to the details. 8,192 bit encryption doesn't help you if you don't manage the key well.