First off, find the login and trans_key in the database for your Magento installation:

SELECT VALUE FROM core_config_data WHERE path IN ("payment/authorizenet/login", "payment/authorizenet/trans_key");

Next, use this code to decrypt the values (the values I’ve provided below are fake):

/* Substitute appropriate Mage path: */
require_once("/path/to/Mage.php");
Mage::app()->setCurrentStore(1);
 
$hlp = Mage::helper('core');
 
echo ($hlp->decrypt("0:2:31cd17ea0becc0:d67642b7da2fab==") . "\n");
echo ($hlp->decrypt("0:2:c4b2ee0255d1a5:abc06b1bcb3394==") . "\n");

So Pinterest has a TOS doc.  People are starting to pay attention because Pinterest is getting really, really, really big.  The theme of many of the HN comments is that this is typical cover-your-ass boilerplate language and that it’s totally normal, so therefore just shut up and accept it.  This is nothing more than teenage peer pressure logic applied to what is possibly the hottest Internet startup in the country right now.

In other words, time to start focusing on it a bit more.

I actually care a lot about terms of service and how users interact with them.  And while I have lot of respect for what Pinterest has built (and have learned a few things from studying them), TOS and copyright are areas that we spent a lot of time working on at StyleFeeder in conjunction with our legal counsel and advisors (including one world-renowned expert in copyright law).  By contrast, here’s the relevant portion of StyleFeeder’s pre-acquisition TOS that I happen to have in an old file on my laptop.

This, people, is how to write a TOS that allows the business to function with flexibility and protection yet doesn’t overreach (bold text is mine).  

3. User-Posted Content.

StyleFeeder depends on the content that you post. In fact, that’s the whole point of the Site. While we encourage you to add links to great products and to post your profiles and reviews, some content just isn’t appropriate for the Site, including, but not limited to, links to illegal or counterfeit items or sexually-explicit, racist, or vulgar content. While we have no obligation to monitor use of the Site, we do reserve the right to review, modify and/or remove content, for example, content found offensive by other users or content found to be illegal.
…
StyleFeeder is not responsible for the manner or circumstances by which third parties may access such public content and is under no obligation to disable or otherwise restrict this access, although we reserve the right to do so when we deem appropriate. By posting such items, information, messages and comments in a public area, you are granting permission to us to use, display, modify, distribute and otherwise exploit such items, information, messages and comments in connection with the Site and otherwise in connection with our business.

9. Copyrights.

StyleFeeder-posted content included on the Site, such as text, graphics, logos, data compilations, APIs, software and the compilation of all content on the Site, is the property of StyleFeeder and its licensors, and is protected by United States and international copyright laws. StyleFeeder makes no claim to third-party content that is rightfully posted on the Site.

Notice that this language is markedly tighter than what Pinterest currently chooses to use.  I wish Pinterest put the same level of thought and innovation into their TOS as they did with their product.

PS Also note that imgur’s TOS doesn’t overreach.  IANAL so perhaps it’s not as good, but my reading of it is that it is philosophically very different from that of Pinterest.

All of your CDN hostnames will follow this scheme:

type-serial.environment.something.tld

The components are:

1. type: typical values include jscss, product-image, avatar.  Basically, you put a whole class of content on one hostname.  Sometimes these divisions are artificial, based on performance or based on architecture.  For example, you may keep your product images (if you run an e-commerce site) inside a big S3 bucket that you want to front with a CDN.  You may want your Javascript and CSS served off of one host.  Anyway, this is your chance to make functional groupings.
2. serial: You start with 0.  If you have a website that tends to present many images on one page, it can be beneficial to serve the same images off of several hostnames for performance reasons.  It’s also useful to have a serial field in case you migrate from one CDN provider to another since you can just bump up the serial number during the migration.  These are nuances, so I will come back to this shortly.  But if you run a small site, the value for ‘serial’ is 0.
3. environment: typical values correspond to dev, integration, qa, staging or prod.  You will have your own names for these; obviously, you will want to use your own terminology.
4. something.tld: generally, it is a good idea to serve your CDN accelerated assets from a domain name that is different to your main website.  For example, if your site is www.something.com, you should buy another domain like something-static.net.  There are a few reasons for this, but generally you neither need nor want your HTTP cookies being sent to your CDN hosts because this is normally not necessary for serving up static files that don’t differ from one visitor to another.  There are also security benefits (in case a host on your CDN’s network gets cracked) and performance (unnecessary HTTP overhead sending useless cookies).

And that’s it.

When you put it all together, you might end up with something like this for your production hostnames (I’ll use this domain, whirlycott.com as the example site):

jscss-0.prod.whirlycdn.net
avatars-0.prod.whirlycdn.net
blog-images-0.prod.whirlycdn.net

Your dev, qa and staging hostnames are easy to guess from this scheme, so I shall avoid repeating them.

I mentioned a nuance in relation to the serial number field.  If you find yourself in a position where you are generating web pages that have lots of, say, images, you can split up your content across multiple hostnames quite easily:

product-images-0.prod.foocdn.net
product-images-1.prod.foocdn.net
product-images-2.prod.foocdn.net

The advantage here is that your browser will typically download from multiple hostnames faster than from a single hostname (don’t go crazy with this and generate a hundred hostnames).  Of course, you do incur an extra DNS lookup, so you have to consider that.  When you are generating the serials for your assets, I recommend generating the same serial number (and therefore a consistent hostname) for a given piece of content.  If you have a website with pictures of butterflies, you might have a bunch of jpegs served like this  (note the alternating serial numbers):

http://animal-pics-0.prod.mycdn.net/blue-butterfly.jpg

http://animal-pics-1.prod.mycdn.net/green-butterfly.jpg


http://animal-pics-0.prod.mycdn.net/red-butterfly.jpg


http://animal-pics-1.prod.mycdn.net/yellow-butterfly.jpg

If you have fifty photos per page on your site, you should ideally generate the same hostname for each image to improve cacheability (there may also be some tangential benefits for Google image search).  Let’s say you want browsers to download animal-pics from two hostnames.  In this case, use a standard hash/mod approach to generate a gaussian distribution of your assets across your two hostnames.  Note that you will need to do this server-side.  In python, you’d do it like this:

>>> import hashlib
>>> hash = hashlib.sha1()
>>> hash.update("blue-butterfly.jpg")
>>> result = hash.hexdigest()
>>> result
'775da2f0b764b712b7c3615f479794e0095cc8ce'
>>> serial = int(result, 16) % 2
>>> serial
0L
>>>

SHA1 returns a 160-bit integer.  Python will handle large numbers for you automatically.  In Java, you have to use a BigInteger and DigestUtils to coax it into something you can do actual math with.  In this case, for the blue-butterfly.jpg, the correct serial is 0.  If you repeat this test on your python repl using “green-butterfly.jpg”, you will notice that the serial number is 1.

What I like about this layout is that it scales well, is easy to understand, easy to debug and simple to implement.  You do, however, end up with a proliferation of hostnames, but if you are successful, you will want something closely resembling this, so take the extra hour to set up your site the right way.  I like to avoid doing the same thing twice.

Previously, whenever I wanted to onboard a contractor, we would simply whip out our template legal docs (which I shall come back to in a moment), fill in a few blanks, get the contractor and me to execute it and then file it away in our filing cabinet.  It wasn’t until later that I realized how critical this ability was to our success.

Sometimes you need a designer.  Or an iconographer.  Or a developer.  Or whatever.  It should be easy to bring that person on for a week or a year to help make your project successful.  It should not require any effort as effort is a chilling effect.  You should also empower people to make these decisions and expand and contract your team as necessary.

I signed 18 contractor agreements with people or companies that did work for StyleFeeder.  Most were designers or developers and were located all over the place, from a few blocks away to Maryland to Brazil to far-flung corners of Canada to Romania.  Bringing someone on board took maybe five minutes, but consisted of a few key agreements:

1. NDA – a standard mutual nondisclosure agreement that says you won’t convey information about the gig to anybody
2. PIIA – a proprietary information and inventions agreement that assigns all the IP and ownership of the work the contractor does to the company

We had four agreements based on whether the entity was an individual, a company and their location (either inside our outside the US).  Our law firm, Gunderson Dettmer, made this really practical for us.  The agreements were reasonable, short and simple and were never met with any objection by any of the parties we did work with.  The fact that these docs were simple and easy to process gave me great confidence that everything we were doing was done properly as there was precious little that a competent person could screw up.

If you’re starting a company, be sure to ask your legal counsel for docs like these as there are a few nuances that you should be aware of (entities in Quebec, for example).  And if you’re managing a company, insist with iron-fisted stubbornness that every contractor sign the docs and that they are stored in your filing cabinet.  If you’re lucky, a grey corporate lawyer will come along and ask you for them some day.

• $4M invested from Schooner Capital and Highland Capital Partners along with a small army of supportive angels
• Acquisition price: undisclosed
• Team size: 5 tech, 1 bizdev, 1 marketing, half-time office manager
• Cash flow positive for around a year with money still left in the bank at the time the deal closed
• Started: January 2005
  Publicly launched: October 16th, 2005
  Funded: May 2006
  Acquired: January 15th, 2010

StyleFeeder roughly falls into a category I call “next generation e-commerce,” a rather broad umbrella that describes a reinvention of the classic e-commerce model in which companies sell stuff online directly to consumers.  From the consumer perspective, companies in this space offer Web-wide product search/discovery and organization through social and algorithmic techniques.  To the retailer, this represents a partial shift of their merchandising role to a third party – not per se desirable, but when viewed through another lens looks like a highly targeted customer acquisition channel.  A techie friend saw the first implementation of StyleFeeder and declared it “del.icio.us for clothes,” which wasn’t an altogether horrible starting point for those familiar with the social bookmarking site.

Social sharing of product links was certainly a core part of our initial product offering, but once we started to grow, the problem of finding cool clothes on the web started to appear locally as it became darn near impossible to find anything useful on StyleFeeder.  Fortunately, I anticipated this in advance and invested heavily in building our own highly fancy recommendation engine.  After a few false starts, we ended up with something that worked well for our needs and could handle our volume. Our investment in innovation and technology stands out still as one of the key differentiators of StyleFeeder.  While our competitors invested in other areas, leading edge technology was one zone where we really stood out.  You have to do what you were good at… and we were good at building product.  So we did that.

Eric Savage and me at the first StyleFeeder office in Harvard Square, July 2006

Competitors

At various points in our history, I considered us competitive with Stylehive, ThisNext, Kaboodle, TheFind, Like.com, Pronto and Shopstyle.  There were a few other companies that I kept my eye on, but I didn’t consider them serious threats.

Kaboodle sold to Hearst in August 2007, almost exactly four years ago.  I remember the moment that I found out that they had sold – I was at the office with some folks at 4am putting the finishing touches on a big product launch when the news broke on TechCrunch, including disclosure that the price was around $30M (although Crunchbase indicates it was $18M, which is closer to what I heard through the grapevine).  Since Manish Chandra’s LinkedIn profile indicates he is still at Hearst, I’m going to speculate that they got a four year lockup period (we were only locked up for one year, which I thought was very civilized).  I tried long and hard to figure out Kaboodle.  I mean no disrespect to anybody who ever worked at that company, but I never thought the product was original.  However, it was clear that they were stomping our asses at customer acquisition and traffic generation.  I think it was through email marketing, but I never did get clarity on that and would love to know.  Kaboodle was a success – hats off to them.

ThisNext popped on the radar in August 2006 and had tremendous launch coverage along with a technology team that seemed like a credible threat.  However, it soon became clear that their PR skills were a few steps ahead of their ability to execute.  Slowly, their founders left.  I monitored their employees’ Flickr photostreams closely to keep track of headcount and burn rate and estimated they had about ~26 people on their team.  Years later, one of their executives sat across from me in a restaurant in Cambridge and asked if we were interested in acquiring the company; we declined.  They later merged with Stylehive and are now reinventing themselves under new management.  Who knows, they may finally strike gold.  I wish them the best as they move forward.

Pronto is a unique bird.  They’re owned by IAC and had a decent product offering put together by a very large tech team that they acquired from Semantic Discovery.  They also had an unusual incentive structure in that their management team had a pre-negotiated exit from IAC, which seemed potentially thorny to me, though the details are not something I know about.  A few years ago, their business was basically SEM arbitrage, which is alright if you can make it work for long periods of time at scale.

TheFind has $26M in and, from what I can tell, is doing well.  They seem like a quiet bunch that maintains a heads-down profile.

Like.com had $47M at the time they sold to Google last year for $100M; from what I understand, this was principally an acquisition of IP and talent. In our user testing research, neither Like.com nor TheFind fared well with our target audience (female, 18-35), which, I suppose, is not a surprise.  Like.com has some advanced image recognition technology, but that seemed more of a feature than the basis for a website to me.  I can attest that not one single person in our user research ever noticed or tried the feature that Like.com had spent so much time and effort in building (Postscript: after being acquired by Google, Like.com launched Boutiques.com, a smorgasbord of beta-quality features.  Based on Compete data, Google is currently starving the site.)

However, the real standout in our competitors was Shopstyle, part of the Sugar Inc. empire ($46M invested).  It seemed to me that Shopstyle was an opportunistic acquisition for Sugar, but they have built a formidable SEO fortress around it, driving traffic to important keywords.  Fashionistas adore the site.  After researching and deconstructing their site, we decided that two qualities drive their product success: the black header color indicates “high end” and the visual product density per page is optimally tuned.  All other variants of praise for Shopstyle fundamentally boil down to those two characteristics (including the distinctive horizontal scrolling).  They did a wonderful job in putting together both the product and growth strategy and deserve a lot of credit for it.

If founders or CEOs from any of these companies can share more from their experiences in the comments, I would be eager exchange perspectives.

Partnerships

We bumped into Shopstyle a few times during our partnership building efforts, as they had a compelling white-label offering for media companies.  At one point, we were outsourcing our ad sales to Hachette Filipacchi Media (ELLE.com, if you’re not aware of HFM) and I managed to scuttle their plans to use Shopstyle in favor of our own shopping solution for publishers.  That immediately boosted our credibility.  Otherwise, partnership deals tended to be cumbersome and distracting.

Capital Efficiency Rules

If there is a high order bit here, it’s that StyleFeeder did more with less than anybody else in our space. How did we compete with companies that had 2-10x our resources? Hard work, focus, culture and excellent business relationships. If you know me personally, you will know that I am not a cheapskate. It’s just that we didn’t blow our cash on parties, fancy office space, speculative marketing adventures, or “passengers”.

I had a “no passengers” hiring rule which basically meant that everyone has to be both an individual contributor, able to do their job without support and capable of handling a team (or contractors, or vendors, etc.). We divided our efforts and learned to trust each other to get the job done.

Being a night owl at StyleFeeder's third office. My chair is to the left of the beam.

Making Deals

Shergul ran bizdev and corp dev for us and he was pretty astounding at getting us an audience with C-level executives at any company we wanted to talk to.  We were principally searching for partnerships to help in growing revenues and customer growth (but, hey, a venture funded startup is automatically on a certain kind of trajectory), so as we were able to demonstrate our product, technology, vision and the super StyleFeeder team, sometimes things got a bit more serious.

We received offers from four different companies (three of which are public companies); I won’t disclose who these companies are as I intend to honor my NDAs. I learned a lot from this experience: the cost of distraction, the importance of a simple deal structure, what matters to a buyer, how to build leverage and so on.  Turning down a written offer from the CEO of a public company is not a bubbly fun experience, especially when that offer could set you up pretty well in life.  However, it pays to be patient and cold-blooded in analyzing deal terms.  I had to learn that.  It didn’t come naturally at first.

By the time that Time Inc. got serious with us, I think I was personally in a better position to know when things were on the right track.  The people we did the deal with at Time Inc. are wonderfully friendly and intelligent, knew what they wanted and moved quickly, a sharp distinction from many large companies.  I think the whole deal took around six months from the first meeting to closing.

The StyleFeeder team wrapping up some diligence docs: Lana, Shergul, Dina, Alex, Kilby, Ben, Savage and me

The Future

I would be overstating reality to claim that StyleFeeder made a massive impact on the e-commerce space.  We played a part in disrupting the status quo and served as an inspiration for other companies that followed us.  Although I’m no longer working on StyleFeeder, the site is still being run by a highly capable group at Time Inc. that includes some of the original team.  I think that the power of Time Inc.’s brands, especially People and InStyle will accelerate StyleFind, a new site that we launched last winter and which is built on StyleFeeder technology.

I’m also keeping my eye on newcomers like Curisma, Pinterest, Suddenlee and Svpply.  Are there other innovative e-commerce companies I should be aware of?  Please let me know about them in the comments.

For a range of reasons, I’m omitting a lot.  But to everybody on the team, investors, contractors and vendors, I’ll say it one last time: thank you.

Whenever I told people that we sold to Time Inc., I could usually detect that they were somehow reminded of AOL and TimeWarner (worst merger ever).  Sure enough, “And how’s that working out for you?,” they would smirk.  The reality is that it was going great.  In the past year, we built and launched StyleFind using StyleFeeder technology and business relationships.  StyleFind is off to a great start and will no doubt become a major player in the women’s fashion e-commerce space.

The people we sold the company to knew we had created a high-output, super-functional organization… and they weren’t about to screw that up. Mostly, they kept the corporate stuff out of my way and strongly encouraged us to keep doing the things we were good at.  We were in NYC frequently, presenting both to the company’s top management and to the technology leadership.  I know we contributed a lot to Time Inc. and we were treated very well in return.  If you ever have a chance to work for Time Inc., I would recommend it.  And if you are ever lucky enough to sell a company to them, you’ll find that nearly everyone is both intelligent and nice to work with.

I will have a lot to say about StyleFeeder and e-commerce in the coming days, so come back soon.

I think Scrum has a lot of good aspects.  I’ll go a step further and say that for most startups and probably most software projects, Scrum should be your default.  You should be required to make a case for not using it before moving to something else.  However, there are two effects of Scrum that I don’t like.

Most importantly, I think Scrum does have a chilling effect on innovation.  Common symptoms of this are people saying things like “Stick to what is in the sprint” or “That’s a super idea – put it in the backlog and let’s consider it during our next planning meeting.”  Innovation and creativity don’t respond well to statements like this.  They appear suddenly and without warning and are opportunities that you must seize and run with.  Damn your plans.  Scrum is part of a family called “agile methods,” and, by comparison, it absolutely is.  Well, maybe sometimes it just isn’t agile enough.  But I guess it depends on what you are optimizing for.

The second thing that I don’t like about Scrum is that if you have a highly functional team that is cranking, applying Scrum to the chemistry of your team will absolutely slow things down.  As lightweight as it is, there most certainly is overhead involved.  Perhaps there are other benefits of having Scrum in place, but speed isn’t one of them.  That being said, Scrum can be fairly lightweight and is probably the most responsible choice you can make in the face of actual methodologies that you can, say, buy books about.

Now, what do I like if it’s not Scrum?

I like goals.  The objective of a sprint (using Scrum parlance) is to complete the specified work.  Hopefully that maps to your overall strategy.  Hopefully that makes your goals a few steps closer than before.  The reality is that reaching your goals are the most important thing, not necessarily how they are achieved.  If you want to boost conversions, increase registrations, reduce latency, etc., it’s way better to stick with a few key numbers that you can measure against and simply chase those until you’ve moved whatever needle you are measuring.  It is very frequently the case that you will have no idea what will end up working for you in terms of actual tactics.  But the ability to make guesses, learn, retry and iterate is going to get you there.  Sticking to a plan and realizing halfway through a sprint that things are Not Going Well is not going to lead to the desired outcome.  And constantly changing the composition of a sprint makes the whole process seem very flimsy.

But Scrum is just a hammer in your toolkit.  Choose it for the right job and it can be very valuable (yes, really!).  If you adopt it during a phase in your company’s lifecycle when you are trying to focus on innovation, consider yourself warned.

Do you have techniques to make Scrum work better in an environment that requires innovative thinking put into practice?

Some of the most impressive marketing people I’ve worked in the past had a background at big credit card companies. Everything they did was based on numbers and analytics. No guessing, in any material sense, anyway. Every dollar they spent was tracked. At the beginning of the StyleFeeder story, I blew quite a bit on misguided marketing efforts involving SEM and really silly ad buys. I did a calculation at one point after a particularly unsuccessful spend in which we threw $3K at a prominent women’s blogging network and only six (6) people signed up for StyleFeeder as a result. Yeah, $500/user. I know. Tell me about it.

So I coined the blimp test.

Let’s pretend that it costs $50K to rent a blimp out for a few hours and fly it over a major city. Let’s say you print up fifty thousand postcards advertising your product/service/website/whatever. Attach a $20 bill to each postcard. Take the blimp out for a ride and start throwing the postcards over the side. How much publicity can you generate like this? You’ll have spent around $1M, almost certainly landed yourself on the evening news and probably turned a few heads along the way. But will it affect anything you’re trying to do? Your cost per lead is probably going to be in the $100+ range. Insane, isn’t it? Totally crazy.

Yet a lot of marketing efforts aren’t much more than this. Take a few hundred thousand dollars and poof them away. Whenever someone tells you about some cocamamie scheme that isn’t specifically designed to affect identifiable key metrics by a specified amount and that will almost certainly just blow a large chunk of cash, my suggestion is that you tell them that their idea probably wouldn’t pass The Blimp Test. Tell them this story and ask if it might be more effective than what they’ve suggested.

As the dust starts to settle and I reflect back on the past few years running StyleFeeder, our team did several things exceedingly well. One of them was our collective ability to focus on a goal and execute towards that, whether our objective was related to revenue, product development, fixing a problem or otherwise. That ability to focus as a team is one of our core strengths.

You hear this all the time, right? It’s not new. It sounds obvious enough. In real life, it’s hard.

Part of the reason is that focusing implies that something else gets de-emphasized, but in small startups, subtleties don’t work. If you’re trying to do something, stop doing everything else. It’s a primitive caveman-like approach, but devoting 50% of your resources (time, money, or attention) means that whatever you’re doing will surely take much longer than 2x as long due to the inevitable distractions. Be brutal in your willingness to get your team to drop everything and just do that one important thing.

We had some principles that enabled this, notably with our product work that helped us avoid the cost of context switching. Whenever we built something, the goal was that (a) you wouldn’t go back to it for at least a year and (b) it had to scale 10x without intervention. These principles shaped our work in a way that yielded quality, stability and operational reliability and we still follow them. These principles also weren’t so aggressive that they promoted a culture of over-engineering with our team building the Infinitely Scalable System.

If you don’t adopt principles like this, even your successes can be cause for alarm. Crap, you got ten thousand new signups today and that underscored a scalability problem that you didn’t know about? Well, whatever your team was focusing on before has now been sidelined by a crashing website and emergency late-night patches. You rushed a feature out the door without properly considering the security holes that went along with it and someone cracked your site? Now you get to clean up that mess instead of doing something useful.

Starting to sound familiar?

I’ll give you a concrete example. Years ago, you used to be able to import your Amazon wishlist intto your StyleFeeder account. You’d type in some identifying information into a search box and select the Amazon Wishlist you wanted to import. We asked around and found that my friend Luis Villa had the biggest list we could find with almost 500 products! Literally five minutes after we pushed this feature live, the site crashed hard. Upon investigation, we discovered that someone tried to import a wishlist with over 5,000 books on it (we were attracting a lot of book lovers back then). Since we were holding a bunch of this data in memory, the server simply ran out and died. Wonderful. It was a stupid design decision on our part. The lesson was that this quick and dirty approach didn’t scale past the first few minutes of service. And users will always exceed whatever reasonable limits you think they’ll never exceed. Instead of moving on to work on another feature on the site, we had to immediately redesign the feature we had just finished building. That’s really costly.

What were we working on again? Oh, right.. the thing we were supposed to be focusing on.

During StyleFeeder’s trajectory, we added a lot of features to the site, some of which were pretty interesting and some of which weren’t obvious failures. One of the other skills that we didn’t get particularly good at until the later years was killing off stuff that wasn’t helping us or that we couldn’t properly support. An example might be a partnership that isn’t performing well and your company is powering features on another company’s website. Kill the partnership. It’s a distraction. Or, get some data and decide if you can make it work well enough to keep around. But your first instinct should be to view this underperforming lump of a partnership as an alarming problem that needs to be addressed one way or another.

There are many wonderfully witty quotes about how important reliable data is and how everybody except God needs supporting figures, etc., but it’s worth emphasizing that it’s all true. We now have wonderful realtime dashboards of all key metrics that we’re tracking. For many reasons, getting your entire team to focus on these metrics – and to build them as part of every feature – is The One True Path. Once you have tools like this, you’ll realize that you’ve just been a fool stumbling around in a dark room without any notion of where you’re going.

If I had to do it all again, I’d re-adopt these same principles and be even more aggressive in limiting the company’s activities to a short list of Things That Matter. It’s all a bit of a fine art and you’ll have plenty of opportunities to experiment with the right balance.

The open source nature of the code is helpful in the long run, but it provides absolutely nothing in the way of assurance to voters. Ben Adida’s Helios Voting System provides voters with a cryptographic, verifiable receipt that their vote was counted. Commercial implementations or Open Source versions of this software would both still need to provide a cryptographic receipt. That’s your proof. That’s something that can support the weight of democracy.