I know these guys have good intentions, but they seem confused about the guarantees that SRP provides. It does allow the server to verify the user's password without receiving it, but it doesn't help in any was against offline attacks. If the "password" (in this case verifier) database is compromised, the attackers will still be able to brute force the passwords. If they implemented it correctly, they will be salted, but this only makes the attack slower. Furthermore, nothing can protect you if your password is password.
Also, I hope that they don't think this removes the need for SSL. It does not. In a web application the server sends the client the javascript to run. A man in the middle can modify it and defeat the whole point of SRP.
What I meant by that is that a brute force offline attack will always succeed if your password is easily guessable regardless of what hashing or password verification protocols are used.
I have an exercise: is it possible to create a javascript file (served over https) that, when included in a non-https HTML page, is able to determine whether any other scripts were included on the page or will be included on the page by a man-in-the-middle?
If this were possible (I suspect it is not), then it might be possible to have secure javascript code running over a non-HTTPS url. (the motivation for this is to have some form of security and still be able to load websockets and make CORS xmlhttprequests to other (non-secure) hosts - with the assumption that these hosts may also be man-in-the-middled). For now, the only alternative is to use something like a packaged app, if you want to make sure your code is actually your code, and still be able to load insecure resources.
It's not possible. What's possible is using a browser extension to verify some of the essential javascript and use that javascript to do further verification.
"Meteor 0.5.0, available today, allows you to write secure realtime client-server applications in pure JavaScript. It's the only system of its kind in the world."
While I agree with you wrt to there being other examples, and the original claim was wrong/false, it could be considered presumptuous to label this as 'an outright lie'.
Most people I know, and the internets, seem to agree that lying requires: intent to deceive.
Having chatted with Matt DeBergalis online and in person on occasion, he comes across rather honest in my admittedly subjective opinion (although welcome to hear contrary info). So if we accept that, then it seems unlikely he would intentionally allow the team to spread falsehood knowingly (especially if it's so easily refuted).
FWIW, I think Meteor is cool for certain camps and projects, but I also really like the 'pick and choose' NPM-friendly style of node development (in fact my personal preference at the moment is for an open modular ecosystem vs a monolithic framework with plenty of magic), so it's not like I have any particular emotional investment in saying this, other than to correct the record.
So in conclusion, this does not seem like a totally fair assessment of the author.
(And yes I realized you mentioned no-one by name, but a project website cannot 'lie'. At the end of the day, a person was still responsible for writing those words).
Notwithstanding Hanlon's razor, ignoring the existence of your competitors (Opa, Derby, SocketStream) would be a display of incompetence I don't expect from the Meteor team.
SocketStream http://socketstream.com lacks the media blitz, but it provides authentication and integrates with pretty much anything in NPM (one of the stated goals of the author), and still provides all the benefits of a real-time framework like Meteor (for more than a year now)
This is exactly why I love SocketStream. The extensibility of it is great. I can use one of the several thousand existing node modules/libraries and install them easily via NPM. In addition, development has been active and Owen (the lead dev) is extremely responsive to any issues on the GitHub repo.
It doesn't do much yet, but shows the direction I'm going in: More API based, pipeable Node Streams wherever possible, full npm / Node compatibility. Follow @socketstream for updates.
Also I want to congratulate the Meteor team on their release. Making scalable, reliable realtime web apps is hard and all work in this area benefits the entire community.
Opa generates pure JS code, even though it's indeed a variant of JavaScript with some added features (the ones you mention) and some removed. But then, there's also Derby and probably others.
Just curious, as I don't know enough about the two, what makes Opa similar enough to Meteor that the claim "[Meteor is] the only system of its kind in the world" is an outright lie?
i think when they say "only system of it's kind" they mean they are solving all of these problems in different ways than all other systems... everything from rails to django to opa to derby to whatever.
Basing this on the screencast I think this looks amazing and they seem to be very productive. This said, I am unsure if this would produce codebases that are easier to maintain, since there is not a clear separation of concerns and everything seems to be connected. I think doing client-side JavaScript is hard and messy (even with Backbone or Ember) I could not imagine this would be any easier if I had to handle the backend on the client-side as well (especially a backend that's updated in realtime).
This said, maybe the current struggle of the client side is because the data is on the backend and needs to be fetched, updated and handled using a client-server model. With Meteror the data seems to live on the client-side which maybe makes things easier.
Agree on all fronts. However, for getting something up and running, MVP, and for 99.9% of sites that don't need to scale past couple-hundred thousand users (just making up a small figure here), this type of solution might be more than sufficient...
I don't know, though, but I do know that I'll keep following the project. They make great screen casts, and have interesting ideas.
It's an early preview for a reason. That's why auth wasn't in til now. Not because it wasn't planned, but because the product isn't done yet. Wait for 1.0 before you start greenfielding.
I agree auth is a huge success, but no alternate DB support is a not starter for most I imagine. Any other non relational DB support would be a huge win, most people that I have talked to are blocked by Mongo's license.
How in particular are they blocked by Mongo license? It's AGPL but it only applies to changes made to the database source code itself. It doesn't impose any requirements on your application if you are just talking to Mongo over the wire.
It is not unheard of for businesses in both the public and private sector to not allow AGPL code or use of applications released under this license.
For example, I worked at a public library for years, and the policy was no AGPL, even if we had no intention of touching the source. Same for a local university.
While I'm not confident that being this tightly coupled to MongoDB is a great (or even a good) idea, I'm really glad to see Meteor get closer to 1.0 especially seeing as it's not another Rails clone.
The other concern I have is how testable is a meteor/derby codebase? I don't think I could commit to using something in a team environment without being able to _easily_ test things.
Are Meteor or Derby frameworks to be used on the premise that you have only browser clients? If my Meteor/Derby web app has server component, how easy it is to build native iOS and Android clients to access the same data on the server?
Not as straightforward as in other more established server-side frameworks, I assume. It's part of the reason I'm reluctant to ditch my server-side framework of choice (Rails) in favor of an all-encompassing solution like Meteor. There are more than just javascript clients that need to access my APIs.
This is a huge milestone for a very, very interesting and ambitious project. I wish instead of nit-picking about the marketing language in a release announcement, people would take a minute to appreciate just how amazing this platform is becoming. Yes, ok, derby.js and socketstream and nowjs and opa and realtime-project-foo and etc, sure, maybe they are awesome too, but so what? Meteor is incredible, and contributing to this rising tide floating all the realtime framework boats. And that is something to celebrate imho.
To the meteor team: high five, keep it coming, and thank you!
The other top HN page article today doesn't add to my confidence in MongoDB so more persistence options will be interesting. But still, production ready or not, this can be an excellent MVP creator.
I saw the following tweet from PG within the last hour and wondered if it was a reference to some tech company launch. Then I came here and saw this story. Still not sure...
@paulg: "Did anyone else see a fireball heading east over Silicon Valley at 7:44? (Meteor?)"
This looks very interesting, but can anyone tell me how scalable is this? All the examples I've seen are small scale; but can it support, say, 1000 clients? 10_000 ? Higher?
Meteor.com runs on meteor, and it survived their own launch, which was bigger than anyone seemed to expect. In practice, that's probably the biggest thing to run on meteor at the moment.
The framework is built around long lived requests, which push data to the client. There doesn't seem to be anything unscalable about that, since Facebook and many other huge sites are doing it.
That essentially leaves node.js and mongo, both of which should lend themselves to scaling pretty well.
I've used the Auth Branch for a few month now. You can see it in action at http://www.classfy.com (P.S: make sure you have the "www", or else you wont be able to access the page)
It's super confusing to have your 'naked' domain and www. subdomain point to different things. Clearly, it also requires you to explain it every time you post somewhere. What's the reasoning behind this?
I have allowed most connections on NoScript and RequestPolicy in Firefox, but this website shows only the background image. How do they use many APIs or stupid JavaScript snipets to show something about SECURITY?
Also, I hope that they don't think this removes the need for SSL. It does not. In a web application the server sends the client the javascript to run. A man in the middle can modify it and defeat the whole point of SRP.