I agree with everyone that this should be open-source, but at least this has one benefit over the other proprietary solutions out there: This is not just a secure messenger, but also a beautiful one. If you want to convince - and I do - those who use Facebook Messenger and iMessage and don't necessarily consider their privacy, it needs to have a great user experience on top of the technical foundation. On the other hand, if it gets that and ends up being open-sourced, it would be a great fit for Aral Balkan's Codename Prometheus: http://aralbalkan.com/notes/codename-prometheus/
I think it could work. The set of users who would pay is a completely different demographic than those who are following Justin Bieber. You're only devaluing the market for the adverts that would appeal to everyone.
It's a good point that we probably shouldn't seed the values just to avoid someone from accidentally using "deadbeefdeadbeef" in their production environment. I'll also investigate if we can reuse the transformation instances (and make the change if we can).
We didn't use the machine key as we'd have to pick one of two paths: 1) Using the [`System.Web.Security.MachineKey`](http://msdn.microsoft.com/en-us/library/system.web.security....) class to perform the encryption would probably leave us with the same issue we wanted to resolve (the class only exposes methods for encryption, not the key itself). 2) Parsing the configuration file manually is error-prone and makes us rely on the current format (and while it's unlikely to change given Microsoft's dedication to backward compatibility, it's an unnecessary dependency for an independent solution).
Our code serves as an example and while some will probably copy the code right into their solution, I expect most people will adapt it to suit their needs*. [Poul-Henning Kamp](http://phk.freebsd.dk/sagas/md5crypt_eol.html) recently wrote "Please notice that there is _no_ advantage in everybody in the world using the exact same algorithm, quite the contrary in fact." (relating to the application of well-known encryption algorithms, not designing such algorithms). We believe it's beneficial to share a solution that people can build and improve on. If nothing else, using different solutions prevent a single attack from affecting us all.
Thanks for the explanation! I'm usually pretty sceptical when people step outside the stuff provided by whatever framework they're building on (something which devs at my workplace are always a little keen to do, which occasionally winds up in terms of things that need to be refactored/rewritten a few months down the track in a more standard way to integrate with some other component or whatnot) - so it's a bit of a compulsive habit to try to pick apart why the framework wasn't suitable. For MVC auth tokens though it seems to be a necessary thing to actually get a straightforward and neat solution.
It is a really nice solution, and I'm glad that you guys have pointed out that there's a problem and actually done something about it ("hey, just set the aspnet:UseLegacyEncryption / some other undocumented appsetting" isn't a legit solution), and further than that, opened it up (though it all seems to have disappeared now).
We wound up just more tightly controlling updates (and were fortunate to be in a position that this was a solution/the problem wasn't that major), but the backup was to serve auth cookies unencrypted and add/remove the encryption via a httpmodule - after all, it isn't forms authentication that was really 'broken' IMO, it was that Microsoft kept changing the implementation of encryption all the time. I get the impression that this could be a cleaner solution for asp.net, but definitely isn't for MVC - the next time we have to share auth tokens across multiple MVC apps / multiple instances that we don't control updates on, I'll be sure to pick up your code and run with it, so thanks.
You get more than just the instance. We take care of keeping the servers alive, patching them and such. We also load-balance your traffic, which is usually something you have to add if you're picking another provider. Finally, there's what people like most about AppHarbor, the ability to push code to Bitbucket or GitHub and have it build and deploy, but only if everything checks out. Rackspace is closer to the infrastructure layer. Some prefer that, but I bet most will prefer the convenience of a platform.
2 workers will always be on two different machines. We're probably going to reuse machines when you scale to more than that and increase process limits instead (this could yield better performance as you need to populate fewer local cache etc.)
How wouldn't paying back authors be a recurring cost? It's quite simple actually; how do you divide your $20 between publishers? You can't (before you either die or stop reading that is). A monthly subscription on the other hand can be divided between the articles you've read that month.
I'm thinking about proposing to buy it for an amount covering his cost except a dollar. He will still lose money (which should serve as a valuable lesson), but not as much as if I never buy it - and I really don't need it anyway...
Some cyber squatter has my fistnamelastname.com, and several thousand others (including celebs and typo-based domains). I contacted him about and he made it clear that he was looking for something in the 10k-250k range. I offered $500 and got no response. A non-commercial domain shouldn't command that kind of price, but the cost of sitting on it just isn't high enough to discourage squatters from doing it and waiting for the occasional big payout.
Edit: the squatters name is David Webb in case anyone else has had to deal with him.
Boy I can't believe you were going to pay 500 bucks for a .com domain with your name. The guy who's owning mine is asking for not less than $6K so I just went for the '.me' which is at least as nice looking as '.com' and adds a cool factor to your emails/business cards. Everyone seems not to believe that your email can be me@yourname.me but I'd say that it looks catchy aint it?
On AppHarbor, you also get piggyback SSL by default, as well as you can add custom certificates for free. To be fair - we don't charge anyone yet, but saying nobody else does it is a stretch.
