5 ms·

We either have different definitions of proprietary, or I'm misunderstanding something. The format appears to be open and documented. https://github.com/mozilla

We either have different definitions of proprietary, or I'm misunderstanding something. The format appears to be open and documented. https://github.com/mozilla-lockbox/lockbox-datastore https://github.com/mozilla-lockbox/lockbox-datastore

drdaeman 8y ago
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.
- annabellish 8y ago
  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.
  - drdaeman 8y ago
    > 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.
    - annabellish 8y ago
      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.
      - drdaeman 8y ago
        > can also be levelled at the others 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.

drdaeman 8y ago

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.

annabellish 8y ago
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.
- drdaeman 8y ago
  > 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.
  - annabellish 8y ago
    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.
    - drdaeman 8y ago
      > can also be levelled at the others 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.