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 snowshoe@snowshoestamp.com 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!

The stamps have a threaded bolt hole machined into them for this very purpose! We actually built a system very similar to what you describe (secure space access authentication) at the TechCrunch Disrupt Hackathon in SF back in September. Our project (amazingly) won the whole damn hackathon: http://snow.sh/ack

Thanks again - feedback at this stage is golden!

1) This is useful feedback. If a client doesn't want to grant additional credits for social posts, we can certainly disable that feature. Unfortunately, most clients we have talked to see this as one of the main selling points. I agree - autopost spam on my news feeds sucks. This is one reason why our current MO is to have this be an opt-in feature after every stamp interaction.

3) Our HTML5/JS SDK will work on any phone running a webkit based browser. We're working on a code package for the new IE, though until we see more demand, it will be a relatively low priority. I'm not sure Blackberry is worth any expenditure of our resources right now, though if we had a developer who really wanted, we could probably make it happen.

Great questions. Our basic stamps have dot patterns that are not obscured and are static on each stamp. They are precision milled out of the aluminum stamp body, and, thus, they are still VERY hard to spoof because the location of the observed dots needs to be precise down to the pixel resolution of the phone. You can't spoof them with you fingers. The nice thing about these stamps is that they are nothing more than a solid block of aluminum - no circuitry whatsoever. You can run them through a dishwasher or an autoclave - great for food service and medical applications.

We also have more secure "dynamic" stamps wherein the capacitive touch points are modulated in sequence amongst an array of potential contact points. These are still in the prototype stage, but we get a lot of requests for them, so may be looking to launch this new product line in the spring.

Finally, as for use cases - we can do many of the things people are currently trying to use NFC, QR Codes and/or GPS gating to authenticate. We already have apps that do retail loyalty, coupons, and micro-payments launched on the platform. We also have developers working on apps to authenticate EMRs (electronic medical records) and industrial systems maintenance. Finally, we won the TechCrunch DisruptSF Hackathon back in September by using the stamp as the authentication step for a webservice actuated door lock (article: http://snow.sh/ack)

Should be back up now. Sorry for the inconvenience.

Yikes - working on getting it back up now. I guess load balancing for our www site needs to move up in priority.

In the meantime, you can see much of the same info on our AngelList page: https://angel.co/snowshoe-stamp

Thanks for the feedback! Two quick questions for you:

Re: holdup #2) Are you saying you would prefer that it automatically post to social networks all the time, or that you would prefer to not have preferential treatment of users that are willing to make a post? Or that the default should be to post with an opt-out option?

Re: holdup #3) Our native apps currently only run on Android 4.0+ because those are the only devices where we can guarantee five-point multitouch capability. There are a large number of 2.3.3 and 3.0 devices that are capable, but there is no way for us to limit downloads to only those devices while simultaneously disallowing downloads to devices with those operating systems that can only do 2 or 4 point multitouch (and we definitely don't want to allow customers that don't have 5 multitouch capability to download our apps).

Our HTML5/JS SDK doesn't have such problems, though, and works on 80%+ of the current installed smartphone user base.

Also, re: holdup #1) We can make the stamps slimmer, but don't really have a reason to. We like having an analog to the inked stamps everyone has used at some point in their life, and this form factor does just that. IF someone wants to build an app that requires a more portable version of the stamp, we'd be happy to build stamps for them with a slimmed-down form factor.

Thanks again for the feedback!

The idea is to not actually have people carrying the stamp - you are already carrying your smartphone. The stamp should be placed at a static, centralized location (e.g. the point of sale at a retailer) and used to authenticate transactions (loyalty punches, coupon redemptions, even payments in some niche applications) with customers' smartphones. Does that make sense?

Very exciting - and needed.