Dropbox buys HelloSign (YC W11) for $230M

When these services first came out there were lots of technical hurdles to overcome re: web based PDF signing, but it's pretty straightforward to do nowadays.

I had our co-op built an open-source esignature API, that produces audit logs and has a similar user flow to electronic signature provides like Docusign, Hellosign, Adobe sign, etc.... It took him a little over 2 months to get everything working. Only real difficulty he ran into was scaling and stamping signatures on the PDF, as there wasn't a singly Python PDF library that had all the necessary features.

In the end he got it figured out though - for anyone interested / looking to implement eSignatures in their app, see https://github.com/this-is-ari/libresign - it's MIT licensed.

Surprisingly, it turns out that using security based on a URL with a random string is /not/ security by obscurity.

The security pattern of a URL with a random string is security-equivalent to a pubic username and a random string password, and also equivalent to the security pattern of a bearer token: so long as the URL is shared only with authorized users, it's the same security hardness.

The pattern can tune the security by using more randomness, such as more characters. There are implementation areas to consider, such choosing a random number generator with high quality randomness like /dev/urandom. There are some access control areas to consider, such as all the people having the same bearer token, which means there's no way to do finer-grained permissions per-user or per-role or per-attribute. There are some user interface areas to consider, such as if a user/agent doesn't treat the URL as secret, because it shows content rather than masking characters such as "*".

For comparison, "security by obscurity" means there's a weakness in how the security is built, such that if you saw the source code, or the physical insides of a lock, then you would understand more about how to crack the security.

In URL pattern, an example of security by obscurity would be if the URL string was not actually random but instead was simply incrementing, or was based on a reversible function of the time or username, etc. If you read the source code, you would discover that there's guessable sequence or guessable trick, and thus become much more likely to break the security.

Edit: I strongly favor higher security, and fine-grained access control, and multi-factor authentication, and UI/UX masking, etc. This post is just to look at security by obscurity.

I hate faxing and signing real documents. Hellofax fixes that and I've been using it since 2011 or something.

It should be something derived net present values or discounted cash flow. Same general idea: what is the summation of future cash flows distributable to owners after a suitable discount rate (plus liquidation value, maybe).

It's hard to extrapolate rapid growth correctly, but it can lead to very high present values (ie ~20x sales, depending growth curve of expenses & current margins).

The same formula, given a 10% discount rate zero growth implies a ~9x multiple on earnings, a pretty low valuation.

Craftsman Tools was a brand, if I recall correctly (made by Danaher?). So while asset light and potentially higher margin, there probably wasn't as much liquidation value there. If growth rate wasn't high or decreasing the predicted valuation on earnings might have been low.

Then you just run into human factors like fomo/bidding wars (maybe, like Nicira, Heptio?), things that impact valuation like perceived higher or low risk free rates that might impact the discount rates that are used, et cetera.

In the formula you provided how is the number for the multiple arrived at? Is that the multiplier that will be realized at some future date based on the current rate of growth? If so what would that future date be - the next round of funding, an IPO, something else?