7 ms·

I feel sorry for companies these days who have to continually respond kindly (for years in this case) to unreasonable customer demands via forums/facebook even

I feel sorry for companies these days who have to continually respond kindly (for years in this case) to unreasonable customer demands via forums/facebook even when they've clearly stated why things are configured the way they are and changing that will break functionality for tens of thousands of people. Some companies after a while just need to start following the Wendy's Twitter account model where they start just telling folks like it is after they've shown they aren't going to be reasonable.

stupidcar 10y ago
I feel bad for users who have to deal with supposedly-security minded companies who cite weak, historical reasons for not doing the right thing now. Companies who ignore the actual solutions proposed to them, and instead attack a straw-man. Claiming they're being asked to make backwards incompatible changes for all existing users, instead of providing an an opt-in alternative for users who actually care about their security. Companies whose culture is so inept that they blindly commit the most basic of engineering fallacies: Rejecting solutions on the basis of minor flaws, while defending a incumbent solution with massive flaws, simply because it is incumbent.
- eddieroger 10y ago
  The users don't have to deal with it. No one forces you to use 1Password. They've been asked and stated their position and don't owe anyone anything else. If the folks in the thread (or here for that matter) don't like the answers, don't use the product. Pretty simple.
  - bostand 10y ago
    Are we allowed to say why we don't like what they are doing? Are we allowed to tell other people why? Then what is the problem??
    - eddieroger 10y ago
      Sure, complain away! This is the Internet after all. My problem is the fake pity for users who make the conscious choice to use the problem despite - or regardless of - it's faults. If you don't like how AgileBits handles Dropbox permissions, either don't give it Dropbox permission or don't use 1Password. Complain, sure, but don't pity users for the sake of hyperbole. I read the original post in this thread as genuine pity for AgileBits, which I share - they get to make the application they choose, and users may or may not use it. But hyperbolic pity for the users? That's my problem.
      - mkrishnan 10y ago
        Without users your product is nothing regardless of how great your product is. You are nothing without your users. You are what you are because of your users. Many companies forget that Agilebit is one of them. Throwing your users under the bus just because you can is not acceptable. As someone done Dropbox integration for many of my clients, I know how easy it is to implement app folders. I know it and you know it. We all know what kind of game agilebit is playing here.
        eddieroger 10y ago
        I've never implemented Dropbox in an app, so I don't know. But what you don't know is that the people who message AgileBits on their website are even customers in the first place. And even if they are, which I'll concede because I don't care, there were a handful of them. Presumably this is a handful out of thousands? Millions? If it mattered to more people, more people would complain. That was my point. They addressed the ease of implementation, and have a valid point - it breaks backwards compatibility. That is something I do know about, and it's a terrible thing to do. Yes, they could write a migration path. Yes, they could write all the documentation in the world to go with the migration path. But, yes, it will cause their existing customers - who aren't complaining, save a handful - pain, since the app will stop working as expected, even if only briefly. And that still doesn't address the fact that AgileBits gets to make the app they want to make, and we have the choice to use it or not. The ease of implementation was never their rationale not to, and even was acknowledged in the thread. And my primary point was that they're only accountable to users as far as they can keep them, and have the freedom to make the application they want.
- Terretta 10y ago
  Are users' Dropbox creds (password, optional 2FA) in 1Password? Do you see AgileBits' point about that? If your own creds are able to use more than the app folder, and if your threat is Agile Bits binary, the 1P app folder permissions will do nothing, the evil binary will just use your full creds. Sounds like clamoring for them to reduce a bunch of use cases in service of security theater.
  - hartator 10y ago
    AgileBits is doing the wrong thing here. Dropbox full access is stored on their servers and it's in clear text. Dropbox regular login/password is also stored on their servers, but encrypted via a remote master key. If AgileBits is compromised, they can access all your DropBox files. Attackers still can't access regular login/password because of the lack of master keys.
    - mcgrath_sh 10y ago
      How is Dropbox access stored on AgileBit servers? I buy an app license. I then set up a vault in a Dropbox folder just like a local folder. I use 1Password to access that vault. Same goes for the iOS app. If the worry is iOS, one should assume that every iOS app company that uses Dropbox has a copy of your Dropbox creds on their server, correct? It is my understanding that at no point, does AgileBits store my Dropbox creds. It also does not store my 1Password vault.
    - alphabettsy 10y ago
      Almost everything you just said is incorrect. You don't even enter your dropbox password into the app unless you're storing it as a credential, they present an authentication dialogue for the dropbox API just like all other third-party apps accessing Dropbox and store the OAuth key on the client. Not the server. That's why you have to re-authenticate with dropbox on every device you want to set up 1Password sync.
      - hartator 10y ago
        I stand corrected. There is no security - or security added - issue.
- kevinr 10y ago
  One person's "thing that is broken for weak, historical reasons" is another's "pebble on the inevitable mountain of technical debt." Complexity scales super-linearly on number of features. Solutions aren't the hard part. Implementations are.
rlpb 10y ago
> and changing that will break functionality for tens of thousands of people. This particular request explains why this wouldn't be the case. It doesn't sound particularly easy, because the app would then have to support two modes - the new secure mode, and a legacy mode for backwards compatibility to avoid breaking users. There certainly would be an additional maintenance burden. But it is disingenuous to claim that it is impossible to do so.
- floatingatoll 10y ago
  Your characterizations are incorrect, or as some might say, 'disingenuous'. AgileBits does not claim it's impossible to do so. To quote: "This is not to say it's impossible, but it requires much more careful planning and consideration than changing the permission request in the application." They also note that 'the new secure mode' would break functionality for "many customers", due to a design choice (or flaw) in the Dropbox API: "But even if we were able to work around many of those complications and used the Dropbox API to limit permissions and use a specific app folder, there's still at least one major issue, which (as Khad explained to you a few years ago) is that Dropbox API doesn't allow sharing folders between different Dropbox accounts. That would prevent sharing a 1Password vault with others via Dropbox, which is a feature that many customers love and rely on." Claiming that this 'wouldn't be the case' is a misleading characterization. In actuality, they would have to support two modes - a reduced-functionality 'secure' mode, and a full-functionality 'legacy' mode. While it may be distasteful that users shares password vaults using Dropbox, they have clearly chosen to continue supporting that use case. 1Password offers a paid product that competes with the usually-free Dropbox-based sharing solution. Their paid product is far more secure than the shared-Dropbox method, with both per-vault and per-device encryption keys. It offers no compromises in functionality and offers what some would consider an increase in security for shared-vault users over the 'legacy' Dropbox model discussed herein. It uses a cloud storage service other than Dropbox, but that's no more a dealbreaker than Dropbox itself would be. So with 1Password having already implemented both "the new secure mode" (paid) and "a legacy mode for backwards compatibility" (dropbox), they clearly have already accepted the additional maintenance burden of the increased security requirements of their 'new' method. Please identify the evidence you see supporting your claim that it is impossible, in light of their words and actions to the contrary.
Perceptes 10y ago
If I didn't know HN better, I'd think this was a satirical comment. 1Password is a security product, and they are intentionally not addressing a legitimate security concern because they don't think it's worth spending the effort creating a migration path for the way it works now to a better way. Yes, there are cases where customers angrily demand things that are unreasonable, but this is definitely not such a case, and blindly defending a company's bad actions because you feel sorry for the company is tiring. A company is not a person. It is not a moral virtue. Users pay money for this product, and they do not owe anything further to the company. The company should deliver the best product it can.
- kevinr 10y ago
  Every security product needs to make trade-offs between confidentiality and availability. Addressing all "legitimate security (meaning confidentiality) concerns" results in the proverbial turned-off computer under a mountain with a Marine standing guard. Agilebits have chosen a trade-off which maximizes their users' availability while minimizing Agilebits' best assessment of their users' potential for unacceptable loss of confidentiality, in service of delivering the best product that they can. Now, you may disagree with Agilebits' methods of assessing those qualities or the particular trade-off they're choosing to make here, but you can't claim "security" in the abstract to justify a change without articulating its costs and benefits in more-concrete terms.
  - Perceptes 10y ago
    What is the availability trade off you're referring to? I don't see a downside to migrating to more limited permissions for the user. Agilebits just has to do the work to make it happen.
    - kevinr 10y ago
      AIUI, under the proposed system, Agilebits would have to do permissions prompting every time the user created a vault in Dropbox, which adds friction to the process (makes it less available). They would also need to provide a reasonable migration path for existing users, which, for those who encountered problems, would result in them not having access to existing vaults or the vaults not updating correctly (loss of availability).
DavideNL 10y ago
> to unreasonable customer demands i think i agree with this.. i mean, who stores unencrypted data in Dropbox anyway? I think the real problem here would be people uploading unencrypted 'sensitive' data to Dropbox in the first place.
mkrishnan 10y ago
Asking AgileBit to NOT ask for entire dropbox storage is not a UNREASONABLE request. Looks like AgileBit is really really nosy about what users has stored in their dropbox. and just hate to lose the luxury to access every data stored by user. Read the Pilor's (from AgileBit) response. she gives a link to article which talks about "How to sync 1Password with Dropbox" but she lies that the article details "Why 1Password needs full access".

stupidcar 10y ago

I feel bad for users who have to deal with supposedly-security minded companies who cite weak, historical reasons for not doing the right thing now. Companies who ignore the actual solutions proposed to them, and instead attack a straw-man. Claiming they're being asked to make backwards incompatible changes for all existing users, instead of providing an an opt-in alternative for users who actually care about their security. Companies whose culture is so inept that they blindly commit the most basic of engineering fallacies: Rejecting solutions on the basis of minor flaws, while defending a incumbent solution with massive flaws, simply because it is incumbent.

eddieroger 10y ago
The users don't have to deal with it. No one forces you to use 1Password. They've been asked and stated their position and don't owe anyone anything else. If the folks in the thread (or here for that matter) don't like the answers, don't use the product. Pretty simple.
- bostand 10y ago
  Are we allowed to say why we don't like what they are doing? Are we allowed to tell other people why? Then what is the problem??
  - eddieroger 10y ago
    Sure, complain away! This is the Internet after all. My problem is the fake pity for users who make the conscious choice to use the problem despite - or regardless of - it's faults. If you don't like how AgileBits handles Dropbox permissions, either don't give it Dropbox permission or don't use 1Password. Complain, sure, but don't pity users for the sake of hyperbole. I read the original post in this thread as genuine pity for AgileBits, which I share - they get to make the application they choose, and users may or may not use it. But hyperbolic pity for the users? That's my problem.
    - mkrishnan 10y ago
      Without users your product is nothing regardless of how great your product is. You are nothing without your users. You are what you are because of your users. Many companies forget that Agilebit is one of them. Throwing your users under the bus just because you can is not acceptable. As someone done Dropbox integration for many of my clients, I know how easy it is to implement app folders. I know it and you know it. We all know what kind of game agilebit is playing here.
      - eddieroger 10y ago
        I've never implemented Dropbox in an app, so I don't know. But what you don't know is that the people who message AgileBits on their website are even customers in the first place. And even if they are, which I'll concede because I don't care, there were a handful of them. Presumably this is a handful out of thousands? Millions? If it mattered to more people, more people would complain. That was my point. They addressed the ease of implementation, and have a valid point - it breaks backwards compatibility. That is something I do know about, and it's a terrible thing to do. Yes, they could write a migration path. Yes, they could write all the documentation in the world to go with the migration path. But, yes, it will cause their existing customers - who aren't complaining, save a handful - pain, since the app will stop working as expected, even if only briefly. And that still doesn't address the fact that AgileBits gets to make the app they want to make, and we have the choice to use it or not. The ease of implementation was never their rationale not to, and even was acknowledged in the thread. And my primary point was that they're only accountable to users as far as they can keep them, and have the freedom to make the application they want.
Terretta 10y ago
Are users' Dropbox creds (password, optional 2FA) in 1Password? Do you see AgileBits' point about that? If your own creds are able to use more than the app folder, and if your threat is Agile Bits binary, the 1P app folder permissions will do nothing, the evil binary will just use your full creds. Sounds like clamoring for them to reduce a bunch of use cases in service of security theater.
- hartator 10y ago
  AgileBits is doing the wrong thing here. Dropbox full access is stored on their servers and it's in clear text. Dropbox regular login/password is also stored on their servers, but encrypted via a remote master key. If AgileBits is compromised, they can access all your DropBox files. Attackers still can't access regular login/password because of the lack of master keys.
  - mcgrath_sh 10y ago
    How is Dropbox access stored on AgileBit servers? I buy an app license. I then set up a vault in a Dropbox folder just like a local folder. I use 1Password to access that vault. Same goes for the iOS app. If the worry is iOS, one should assume that every iOS app company that uses Dropbox has a copy of your Dropbox creds on their server, correct? It is my understanding that at no point, does AgileBits store my Dropbox creds. It also does not store my 1Password vault.
  - alphabettsy 10y ago
    Almost everything you just said is incorrect. You don't even enter your dropbox password into the app unless you're storing it as a credential, they present an authentication dialogue for the dropbox API just like all other third-party apps accessing Dropbox and store the OAuth key on the client. Not the server. That's why you have to re-authenticate with dropbox on every device you want to set up 1Password sync.
    - hartator 10y ago
      I stand corrected. There is no security - or security added - issue.
kevinr 10y ago
One person's "thing that is broken for weak, historical reasons" is another's "pebble on the inevitable mountain of technical debt." Complexity scales super-linearly on number of features. Solutions aren't the hard part. Implementations are.

rlpb 10y ago

> and changing that will break functionality for tens of thousands of people. This particular request explains why this wouldn't be the case. It doesn't sound particularly easy, because the app would then have to support two modes - the new secure mode, and a legacy mode for backwards compatibility to avoid breaking users. There certainly would be an additional maintenance burden. But it is disingenuous to claim that it is impossible to do so.

floatingatoll 10y ago
Your characterizations are incorrect, or as some might say, 'disingenuous'. AgileBits does not claim it's impossible to do so. To quote: "This is not to say it's impossible, but it requires much more careful planning and consideration than changing the permission request in the application." They also note that 'the new secure mode' would break functionality for "many customers", due to a design choice (or flaw) in the Dropbox API: "But even if we were able to work around many of those complications and used the Dropbox API to limit permissions and use a specific app folder, there's still at least one major issue, which (as Khad explained to you a few years ago) is that Dropbox API doesn't allow sharing folders between different Dropbox accounts. That would prevent sharing a 1Password vault with others via Dropbox, which is a feature that many customers love and rely on." Claiming that this 'wouldn't be the case' is a misleading characterization. In actuality, they would have to support two modes - a reduced-functionality 'secure' mode, and a full-functionality 'legacy' mode. While it may be distasteful that users shares password vaults using Dropbox, they have clearly chosen to continue supporting that use case. 1Password offers a paid product that competes with the usually-free Dropbox-based sharing solution. Their paid product is far more secure than the shared-Dropbox method, with both per-vault and per-device encryption keys. It offers no compromises in functionality and offers what some would consider an increase in security for shared-vault users over the 'legacy' Dropbox model discussed herein. It uses a cloud storage service other than Dropbox, but that's no more a dealbreaker than Dropbox itself would be. So with 1Password having already implemented both "the new secure mode" (paid) and "a legacy mode for backwards compatibility" (dropbox), they clearly have already accepted the additional maintenance burden of the increased security requirements of their 'new' method. Please identify the evidence you see supporting your claim that it is impossible, in light of their words and actions to the contrary.

Perceptes 10y ago

If I didn't know HN better, I'd think this was a satirical comment. 1Password is a security product, and they are intentionally not addressing a legitimate security concern because they don't think it's worth spending the effort creating a migration path for the way it works now to a better way. Yes, there are cases where customers angrily demand things that are unreasonable, but this is definitely not such a case, and blindly defending a company's bad actions because you feel sorry for the company is tiring. A company is not a person. It is not a moral virtue. Users pay money for this product, and they do not owe anything further to the company. The company should deliver the best product it can.

kevinr 10y ago
Every security product needs to make trade-offs between confidentiality and availability. Addressing all "legitimate security (meaning confidentiality) concerns" results in the proverbial turned-off computer under a mountain with a Marine standing guard. Agilebits have chosen a trade-off which maximizes their users' availability while minimizing Agilebits' best assessment of their users' potential for unacceptable loss of confidentiality, in service of delivering the best product that they can. Now, you may disagree with Agilebits' methods of assessing those qualities or the particular trade-off they're choosing to make here, but you can't claim "security" in the abstract to justify a change without articulating its costs and benefits in more-concrete terms.
- Perceptes 10y ago
  What is the availability trade off you're referring to? I don't see a downside to migrating to more limited permissions for the user. Agilebits just has to do the work to make it happen.
  - kevinr 10y ago
    AIUI, under the proposed system, Agilebits would have to do permissions prompting every time the user created a vault in Dropbox, which adds friction to the process (makes it less available). They would also need to provide a reasonable migration path for existing users, which, for those who encountered problems, would result in them not having access to existing vaults or the vaults not updating correctly (loss of availability).

DavideNL 10y ago

> to unreasonable customer demands i think i agree with this.. i mean, who stores unencrypted data in Dropbox anyway? I think the real problem here would be people uploading unencrypted 'sensitive' data to Dropbox in the first place.

mkrishnan 10y ago

Asking AgileBit to NOT ask for entire dropbox storage is not a UNREASONABLE request. Looks like AgileBit is really really nosy about what users has stored in their dropbox. and just hate to lose the luxury to access every data stored by user. Read the Pilor's (from AgileBit) response. she gives a link to article which talks about "How to sync 1Password with Dropbox" but she lies that the article details "Why 1Password needs full access".