ccmoberg

This is very cool, and great to see a full writeup. I actually built a very similar hack at the 2012 TechCrunch DisruptSF Hackathon: http://techcrunch.com/2012/09/09/meet-the-disrupt-sf-2012-ha...

We used an electric imp and we 3D Printed a aperture for grabbing the deadbolt handle.

Interestingly, this was about 4 weeks before lockitron announced the presale of their current product...

Great work!

I totally agree - there are major signs of progress. The fact that the Female Founders Conference was held at all could even be taken as a sign of that progress.

That said, I think Jami was lamenting the fact that signs of progress are, at times, being taken as signs of completion - that the conference needed less focus on the progress to-date, and more focus on the major inequalities that still exist.

This is really interesting. My company is currently funded with convertible debt, and we have had to modify the conversion date at least three times thus far as we progressed through various twists and turns in our business model and funding structure. The SAFE mechanism would have likely alleviated a large and (unfortunately) recurring headache.

Having just placed a startup in SoMa, I'll say that the inconvenient CalTrain <-> BART transition is an issue. If you are looking to draw employees, mentors or investors from the peninsula, that one BART station makes a big difference. I expect this will change significantly once the new SoMa transportation hub opens and you have CalTrain lines that dead-end at a BART station.

We consider the SnowShoe Stamp to be superior to NFC because, unlike NFC, our technology works on the vast majority of existing smartphones, including all iOS devices.

As regards QR Codes, the vast majority of the population finds the scanning process to be too cumbersome and counterintuitive. Several surveys have shown that only about 10% of current smartphone owners are able to correctly scan a QR code.

We think our tech is significantly more intuitive (the user experience is exactly analogous to that of using an inked stamp). In fact, we've launched punchcard loyalty apps with zero training for the POS staff at two separate coffee shops in Madison, WI, and both times, the POS staff were able to figure out how to authenticate purchases in less than thirty seconds.

It is very hard to communicate how intuitive the Stamp user experience is without actually trying it in person, so, if you'd like, shoot us an email at [email protected] and we'll send you one of our developer stamps to play around with.

Thanks!

You are not going to carry the stamp - you are already carrying your mobile device. The stamp is placed with the centralized person or system with whom you want to interact (e.g. at the coffee shop's point of sale or on the outside of the door you want to unlock). You stamp your mobile device to authenticate that you are interacting with that person or system in a specific way (e.g. the coffee shop cashier only stamps the loyalty app on your phone if you have made a purchase - thus purchase-gating that transaction). Does that make sense?

Thanks for your feedback! Responses:

"My pre-question qualifier: most of the use cases that immediately spring to mind for have the user holding an authenticating block, and not the touchscreen device." -Could you say a little more about the use cases you are thinking of? Who do you consider to be the "user"? Most of our targeted use cases involve transactions where many smartphone users need to interact with a single, centralized system, person or installation. For example, our loyalty apps are downloaded by a retailer's customers, and then credits for purchases are added to their apps via a stamp placed at the retailer's point of sale. We consider both the customers and the retailer to be "users", though.

As for the security question, the capacitive touch points are embedded in a low capacitance elastomer, so physical duplication (e.g. casting) without destroying the stamp isn't an option. We also have other optional authentication layers (GPS-gating transactions to a stamp's known lat & lon, time-gating transactions to a stores hours of service, etc.) that would make even a duplicated stamp much harder to use.

Remember, its not hard to make a functional copy of the mag stripe on your credit card. I would argue it is much easier to do that than it is to spoof one of our stamps. Further, we don't print the "secure key" (the stamp point coordinates) on the front of our stamps, but your credit card number is plastered across the front of your plastic . . .

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!