3 ms·

This is a good idea. I see some avenues for improvement though. 1. It would be better if the application could work without an internet connection. What's stop

by isuru 14y ago

This is a good idea. I see some avenues for improvement though. 1. It would be better if the application could work without an internet connection. What's stopping you from caching the stamp data and then syncing when the user has an internet connection? This would make the product more attractive to both merchants and users. Merchants wont have to provide free wifi to ensure the stamping process is fast and smooth, and users will not have to bother with connecting to a wifi network. The technologies you are competing with (QR codes and NFC) can both work without internet connections. 2. Security. I did not see this mentioned on the FAQ and this is probably something that merchants will want to know. For example, is your system immune to "replay" attacks? If a user managed to record the capacitive stamp, what's stopping them from re-sending it to the servers to get more stamps? 3. Customers may not always want to share their email address directly with a merchant. Why not provide merchants a way to send deals to customers through an API i.e allow them to send deals to customers without exposing the customer's email address?

ccmoberg 14y ago
Thanks for the feedback! Responses: 1) We're working on a local stamp authentication code package for our native SDKs. We're at a pretty early stage right now, which means we're constantly refining our algorithms and tweaking our stamp observation interface. Thus, for the time being, it is easiest (and more secure) for us to keep the authentication services on our server. We should have a local version ready in the spring, though. 2) I'm working on a major blog post about security that I'll post next week. In summary, we have several measures implemented to prevent replay attacks, including o.auth and time-gated ticketing. 3) Agreed. This is a client-specified feature. Most SMBs want it (even if their customers don't). Ces't la Vie. We have a couponing API for our native apps in private beta right now. We also have a Twilio-based SMS couponing feature that will launch soon. Thanks for your feedback!
stcredzero 14y ago
> It would be better if the application could work without an internet connection...is your system immune to "replay" attacks? How would you reply to the observation that an app that prints out one-time use QR codes would: 1) have much the same functionality, 2) require no extra hardware for most shop owners, 3) be quite workable for customers with no smartphone, and 4) be immune to replay attacks?

by isuru 14y ago

ccmoberg 14y ago

Thanks for the feedback! Responses: 1) We're working on a local stamp authentication code package for our native SDKs. We're at a pretty early stage right now, which means we're constantly refining our algorithms and tweaking our stamp observation interface. Thus, for the time being, it is easiest (and more secure) for us to keep the authentication services on our server. We should have a local version ready in the spring, though. 2) I'm working on a major blog post about security that I'll post next week. In summary, we have several measures implemented to prevent replay attacks, including o.auth and time-gated ticketing. 3) Agreed. This is a client-specified feature. Most SMBs want it (even if their customers don't). Ces't la Vie. We have a couponing API for our native apps in private beta right now. We also have a Twilio-based SMS couponing feature that will launch soon. Thanks for your feedback!

stcredzero 14y ago

> It would be better if the application could work without an internet connection...is your system immune to "replay" attacks? How would you reply to the observation that an app that prints out one-time use QR codes would: 1) have much the same functionality, 2) require no extra hardware for most shop owners, 3) be quite workable for customers with no smartphone, and 4) be immune to replay attacks?