3 ms·

I think it could be done -- I mean, Pine's an example of a secure client application that uses a kinda-API (SMTP) to deliver data. If we don't make APIs becaus

I think it could be done -- I mean, Pine's an example of a secure client application that uses a kinda-API (SMTP) to deliver data. If we don't make APIs because someone might write an insecure client, would anyone make any APIs ever? I do agree with you though :) It's probably not going to happen in the real world any time soon. C'est la vie.

DanielStraight 17y ago
I'm sure it could be done. But consider for example if Bank of America did this and someone created an awesome client app that basically became the main way anyone used their Bank of America account. If a bug is discovered in this application that means everyone's data is no longer secure, are users going to blame the app creator or Bank of America? Can Bank of America afford to take that chance?
- scottjackson 17y ago
  You're right -- that's almost certainly the reason you don't see stuff like this happen. Though, didn't Bank of America make that iPhone app a little while ago that allowed you to photograph a cheque in order to deposit it? They're obviously OK with sending financial data around. I guess maybe it was OK in that case because they were the ones that wrote the app? In any case, you're right. Security is definitely the reason this kind of stuff hasn't been implemented. I still think that it's possible to write an open, secure interface to things. Email is the example I fall back on here. Like I mentioned above - sensitive information gets sent around in emails all the time, yet there are countless email clients and they're almost all secure (I say "almost all" to cover my ass if there's some that aren't). I think that if it can work for email, then maybe it can work in other domains.
  - grncdr 17y ago
    Unfortunately, email is a terrible example. While it's possible to have a modicum of security in regards to receiving your e-mail, spoofing emails is trivially easy (unless you use cryptographic signing, which isn't well supported by the majority of clients afaik)
- dustingetz 17y ago
  yes, but what about when I mechanize my own API to my bank anyway? it's theoretically impossible to detect more effectively than cat-n-mouse.
  - DanielStraight 17y ago
    I don't see how that's related at all. I'm not saying Bank of America needs to work hard to prevent automated access to their online banking system. Right now, automated access counts as "undocumented behavior" at best. Bank of America is not likely to face public ridicule because someone hacked up an automated interface to their site which was not intended for that purpose and shot themselves in the foot. If, however, Bank of America says explicitally, "Hey, come use this API and applications built off it to access your account," and then one of those applications starts shooting people in the foot, people are going to wonder why Bank of America thought it was a good idea to let people access their accounts like that in the first place.

DanielStraight 17y ago

I'm sure it could be done. But consider for example if Bank of America did this and someone created an awesome client app that basically became the main way anyone used their Bank of America account. If a bug is discovered in this application that means everyone's data is no longer secure, are users going to blame the app creator or Bank of America? Can Bank of America afford to take that chance?

scottjackson 17y ago
You're right -- that's almost certainly the reason you don't see stuff like this happen. Though, didn't Bank of America make that iPhone app a little while ago that allowed you to photograph a cheque in order to deposit it? They're obviously OK with sending financial data around. I guess maybe it was OK in that case because they were the ones that wrote the app? In any case, you're right. Security is definitely the reason this kind of stuff hasn't been implemented. I still think that it's possible to write an open, secure interface to things. Email is the example I fall back on here. Like I mentioned above - sensitive information gets sent around in emails all the time, yet there are countless email clients and they're almost all secure (I say "almost all" to cover my ass if there's some that aren't). I think that if it can work for email, then maybe it can work in other domains.
- grncdr 17y ago
  Unfortunately, email is a terrible example. While it's possible to have a modicum of security in regards to receiving your e-mail, spoofing emails is trivially easy (unless you use cryptographic signing, which isn't well supported by the majority of clients afaik)
dustingetz 17y ago
yes, but what about when I mechanize my own API to my bank anyway? it's theoretically impossible to detect more effectively than cat-n-mouse.
- DanielStraight 17y ago
  I don't see how that's related at all. I'm not saying Bank of America needs to work hard to prevent automated access to their online banking system. Right now, automated access counts as "undocumented behavior" at best. Bank of America is not likely to face public ridicule because someone hacked up an automated interface to their site which was not intended for that purpose and shot themselves in the foot. If, however, Bank of America says explicitally, "Hey, come use this API and applications built off it to access your account," and then one of those applications starts shooting people in the foot, people are going to wonder why Bank of America thought it was a good idea to let people access their accounts like that in the first place.