3 ms·

I wonder if they considered breaking the app up into smaller parts that can be sold to different markets: * API that accepts the scanned images, parses and r

by dkubb 11y ago

I wonder if they considered breaking the app up into smaller parts that can be sold to different markets: * API that accepts the scanned images, parses and returns the receipt data. * API (that does the above and) stores the data to allow later exporting of receipt data in Quickbooks, Excel, and other formats. * IOS and Android Libraries that integrate with the API. * Birdly app build on top of the library and API. Birdly could be used as an end-user application, but also as a showcase for the API usage. Other application developers could license the libraries and API from your service; sure it creates competition, but you'd be getting a slice from a larger pie. Also if there was a solo API plan, I would probably consider something like this for some personal expense tracking software I've been thinking about writing for myself.

seccess 11y ago
I've always been curious how, in this business model, you protect API tokens if the users of the API deploy mobile apps. Embedding them in an app isn't secure: anybody could reverse engineer the app and use the key for themselves free of charge. And there is no way in Android or iOS to know which app makes a request from the server.
- striking 11y ago
  You can create a sneaky change to the protocol, or something that looks unnecessary, but still works without it temporarily. (or check the order in which the headers are formed, or something.) Then you can detect which clients don't conform exactly to the internal specs. And then you can send those accounts an email telling them they'll be banned if they continue to use external clients. This strategy only works if you have a single blessed version of a client, and it's really only because of security by obscurity. For the mentioned business model, it would not work unless you created a single authoritative server that acted as a proxy to the other API or consumed data from that API without giving the app a key. Snapchat may or may not have used this strategy. (The external client emails were real; as for the detection strategy, who knows.)

by dkubb 11y ago

seccess 11y ago

I've always been curious how, in this business model, you protect API tokens if the users of the API deploy mobile apps. Embedding them in an app isn't secure: anybody could reverse engineer the app and use the key for themselves free of charge. And there is no way in Android or iOS to know which app makes a request from the server.

striking 11y ago
You can create a sneaky change to the protocol, or something that looks unnecessary, but still works without it temporarily. (or check the order in which the headers are formed, or something.) Then you can detect which clients don't conform exactly to the internal specs. And then you can send those accounts an email telling them they'll be banned if they continue to use external clients. This strategy only works if you have a single blessed version of a client, and it's really only because of security by obscurity. For the mentioned business model, it would not work unless you created a single authoritative server that acted as a proxy to the other API or consumed data from that API without giving the app a key. Snapchat may or may not have used this strategy. (The external client emails were real; as for the detection strategy, who knows.)