At that point, if I wrote my own proxy server, I'd drop the JS altogether and just request a proxy link. I know what's cross-origin in my code, so if I wanted to mitigate it with a proxy, I don't need the additional library. Still say your best bet is losing the JS and opening up the server. I mean, what's going to be better here, telling everyone "it's a trust issue", or passing on a relatively simple self-hosted proxy server made specifically for CORS-faking? Else, my big trust question is "why exactly do you WANT me to forward my traffic through your black box server?"
Tell you what. Since I'm not a big fan of the lynchmob, here's the only positive critique I'll give you: proxying isn't an altogether terrible idea. It's not my first go to, but it does have it's place. HOWEVER. Allowing a third party to manage it, is. If you genuinely want to create some buzz and interest, source the serverside of this, and write some docs up how to deploy it to AWS, Heroku, etc. Bundle the JS with that. That'll be infinitely more useful than this service.
You're asking that I trust you will not modify the response in any way shape or form. The very nature of software dev mandates that I do not trust data that is not my own; and even then, verify it. You're asking quite a lot here. This is by all points and purposes, a man-in-the-middle attack vector.
Has anybody else here forgotten you're passing on your Apple ID and password here in cleartext? There's a lot of information you can grab with that, and let's just assume that this guy also puts an app out for IOS-- and buys it with your account.
Seriously? Not to mention all the data that can be mined from your associated messages. And for argument's sake, since, again the passwords are in cleartext, let's just say that a small percentage of users also use the same email and password for their Facebook or their Gmail (or whatever else email they have) -- let's just brute force some bank accounts, send a forgot password request, then scour their facebook for the security question. Nightmare scenario, but considering you're passing some random guy in china all this information, not entirely infeasible.
Has anybody else here forgotten you're passing on your Apple ID and password here in cleartext? There's a lot of information you can grab with that, and let's just assume that this guy also puts an app out for IOS-- and buys it with your account.
Seriously? Not to mention all the data that can be mined from your associated messages. And for argument's sake, since, again the passwords are in cleartext, let's just say that a small percentage of users also use the same email and password for their Facebook or their Gmail (or whatever else email they have) -- let's just brute force some bank accounts, send a forgot password request, then scour their facebook for the security question. Nightmare scenario, but considering you're passing some random guy in china all this information, not entirely infeasible.
This looks nothing like coffeescript. Coffeescript is a perl syntax language which cross compiles to javascript, and has no common basis with JS other than fundamentals of programming. TypeScript is a superset of Javascript, uses identical syntax, and is loosely based on ECMA Harmony-- the future of Javascript standards. The only thing in common with coffeescript is that it's installed via node and cross compiles.
I see the humor you're trying to play here, but things like this are actually kind of rare-- microsoft offering a contribution to the open source community with zero gain to their own systems, and respecting established standards. To imply that they're ripping off CoffeeScript is irresponsible, and downplays the significance behind their work. I for one will be looking for ways that I can contribute to this project as it mitigates nearly every concern I had WITH coffeescript.
Honestly, I like this service. While I agree with everyone's sentiments as to it addressing a problem but not fixing it, I believe it's a great alternative. There's not a "one size fits all" solution to email overload, and this allows a user another channel to express their availability.
I would only suggest allowing a user to set their own alert levels for each category-- my emails constantly go upwards of 100, 200, 300 unread at a time, but I still consider that manageable. Allow it to be customized and you have an interesting project that has some great potential.
Hey, I work on several of the networks you're promoting this service on. The implementation of crowd2 is definitely spammy, although I'm sure you've had the best intention at heart.
For points of reference, this violates Facebook's terms of service, Twitter's, and several of Google's, though not directly mentioned for Google+ I'd still err on the side of caution.
One of the things you can do to be more compliant is to offer an "opt out" option, or an alternative method (like a unique URL) that doesn't directly involve the social networks sharing plugins but still provide an effective gate. Just be aware that this will cause issues with at least three of these services. Can't speak for LinkedIn, but I'd assume it's probably the same deal.