Not sure why you got downvoted; it's a good question. It's not as trivially easy to check as your downvoter might think, as deployed Meteor bundles are minified.
Anyway, the answer is that the entire script is sent to the file and the server. In practice, this isn't a performance issue so much as a security issue - there may be parts of your server code that you don't want clients knowing about.
You can prevent server-side code from getting shipped to the client by placing it in the server subdir.
JS files in the 'server' directory (or any path with a 'server' component') are not sent to the client.
Everything else is.
Putting code inside an `if (Meteor.isServer)` block doesn't keep it from the client. Now someday we might statically analyze the code for clauses like this and keep them out of the client bundle -- the first step is greenspan's jsparse package -- but not likely in the short term.
I really wish people would stop giving instructions like this. Despite all the focus on web security and sandboxing, we continue to instruct people to run arbitrary code on their user account.
People should at least give any shell script they download from the internet a cursory look to see if it's doing what it should be doing instead of blindly executing the response from an HTTP request.
You're right but this is just kind of a nit-pick. It should be up to the user to decide if they trust the source. The way I see it, it all comes down to the question of do you trust the source. If the source is trustworthy from there you've got to worry about an attacker compromising your trusted source. That happens and it sucks but its life and I for one am not going to stop `gem install`ing and `curl`ing because Rubygems.org was compromised once or some other source was tampered with.
I know my sources, I trust them. If they're compromised and they take me down with them, I'm going to cry a little but it's not like I'm working on a nuclear reactor - I'm making some shit CRUD app. Now as the importance of a codebase increases the kind of attitude like I have should decrease of course.
> "I'm going to cry a little but it's not like I'm working on a nuclear reactor"
Great for you, but you're a developer who presumably works on 'shit CRUD apps' for other people who pay you for the effort.
What happens when a script from a compromised source that you run on your devbox grabs the entire contents of ~/.ssh/ and sends it to the bad guys inbox? Congratulations, all your clients have been thoroughly owned.
I don't understand this argument, unless you include things like gem, pip, npm, etc.
`pip install foobar-py` runs a Python setup script, which can do anything bash can. Do you inspect all of those, and comment about their insecurities on HN?
This method makes you vulnerable to attacks that change the script being run. DNS spoofing, HTTP proxy hacking or hacking of the source server itself.
Good package management systems use digital signatures to ensure that the original package wasn't tampered with. Not that hacking of the central repositories never happened, but it's a major (and thus infrequent) event.
But I know for at least gem and npm, while they support signing, they are not used in practice. And those two repositories are used by a large number of people browsing this site.
This is a security red herring that as far as I can see is justified entirely by an aesthetic preference to think of oneself as "able to quickly audit code just by skimming it."
Compare it to alternatives like "gem install NAME_ANY_GEM_HERE", which also executes arbitrary code and which, for the typical Ruby/Rails developer, is totally impenetrable. (If you think otherwise, tell me, when's the last time you did a line-by-line audit of every single dependency prior to installing a gem?)
Even the embedded assumptions like e.g. the Rubygems server is, as of this instance, being operated by Rubygems and not being operated by The Adversary are really, really tenuous.
Meteor dev here.. We actually think this is more secure, or at least does more to raise awareness about security! We want people to BE AWARE that they're running arbitrary code, secured only by the certificate authorities in their local curl install.
Just about every other way of installing software ends up letting the remote run arbitrary code on your machine. The disadvantage of the other approaches is that you don't think about it, so you feel safer than you are, and you are more likely to make security-compromising mistakes.
- When you download an OS X installer package and run it, it can run arbitrary code during the install. Is that how you installed Postgres or Rails? Hope you downloaded that disk image over http. (The last time you downloaded a disk image, did you check the link to make sure it was https? ... Are you sure you never forget to do that?)
- OK, so let's say you download a tarball instead, and untar it into /usr/local, and put meteor in your path. Then the next thing you do is.. you type 'meteor', letting the tarball run arbitrary code. There's not much security difference between letting the remote code run at install time, and letting it run two seconds later when you actually start the program fo the first time.
- OK, let's say you downloaded a Meteor tarball, checked its SHA1-- wait, how did you get the correct SHA1? Did you get it off our website? (Best case, over https, bringing us back where we started?) Or did you call me on the phone.. using the phone number you got off of Facebook.. secured by https? (Best case, and only if you manually added https to your Facebook URL. Did you remember to do that?)
- No problem, I'll get it out of macports, fink, or homebrew, and hopefully they'll have the correct authoritative hash and validate the download. Well, how do you know you have the real macports? The chain of trust still goes through https and the CA. Arguably this is a little better because presumably many people will notice if the macports download site is hacked, but just as arguably, it's less secure because there's one more potential compromise point (volunteer macport maintainers -- how are they vetted? do they use two factor auth? what if their email account is compromised?)
There's really two separate issues here:
- Do you trust Meteor enough to run our code? If so, you shouldn't care whether you run curl | sh or whether you download a tarball and unpack it, and then run the program in it. If not, you shouldn't do either. They're equally bad.
- Do you trust https and the certificate authorities to protect you from MITM attacks, so that you get the authentic bits from meteor.com and not an imitation? If so, then curl https://foo solves your problem. If not, you are going to have to find something better than the CA's to serve as your root of trust.
Maybe there is an argument for "defense in depth" -- maybe you should fetch the tarball from one server with one CA, and the SHA1 from a second server with a different CA -- sure, in practice that could make a compromise less likely. But that's a bit much to ask of the random OS X user that just wants to come to meteor.com and install the tools.
Your best option is clearly to come to the monthly DevShop events at Meteor HQ in SF. If you come to DevShop to install Meteor, I will personally confirm the SHA1 for you :)
All good points, but there's a big difference in trusting my distro's package manager to install packages from their secure repos, verified by certificates I installed with their OS in the first place, and running a shell script from a blog post linked from a news site.
I've never heard of meteor before, and it's likely that many of the people who are reading the article haven't either.
Yes the site is HTTPS, but anyone can buy an SSL certificate for any purpose. It's not even a case of being MITM'd.
Basically we're telling people "read this blog post, run this curl command that runs some random shell script from this server you've never heard of before".
That's a very different from installing packages from your development community's package server, your OS's package repository, or an app store.
I know it's not possible to fully inspect all the code we run, but I'd rather we didn't encourage the habit of entirely disregarding it.
But then how will he really know it's you, Geoff? ;)
In all seriousness, you should consider posting a response like this in your FAQ/Help and linking at the install tutorial. I'm really sick of this knee-jerk security reaction happening every time someone builds an installer like this.
While it's ok for Meteor to keep doing what they're doing, it's hardly a "knee jerk security reaction" to criticize their installation instructions.
Story time. I'm at a hotel, connecting to the Web over Tor and using my distro's package manager (Pacman) to install software. I'm also routing Pacman over Tor because I trusted the hotel wifi even less than I trusted Tor. Anyway, Pacman has this wonderful feature of verifying md5sums - fingerprints of the original source code, as posted by the source code author - from source packages before installing any of the code onto your system. If the md5sums on the software you download don't match the author's posted true md5sums, something is probably wrong. You can tell where this story is going. As I'm installing a few packages, which I've done numerous times in the past, Pacman throws a warning: the md5sums don't match. Slightly annoyed, I then download the software directly from PyPi over the hotel's wifi connection, md5sum it and lo and behold, it's the correct md5. It's the exact same software version and everything.
Importantly, the source code must've somehow been modified between the time it was sent from the AUR/PyPi and when it ended up on my machine. Luckily, the md5sum check failed and the software didn't install, but it did scare me quite a bit.
If I had instead been installing Meteor, as per Meteor's current insecure directions, without checking md5sums or signatures, who knows what could've happened. The Meteor team should really consider releasing an md5sum, sha256sum, or better yet sign their packages, because otherwise there's no way to verify the contents of a download.
The Meteor team clearly has the resources to provide this to the inquisitive. It is SOP for all major FOSS. I get that there's something to be said about the ease of releasing packages from GitHub, but imagine if the Linux kernel did this? What Meteor has right now is ok for alpha software. They certainly have room to grow.
Good response. This is not directly related, but wouldn't it be nice to have some sort of convention where install scripts declare the access that they need and people could allow it (or not)? Something like the Unix permissions systems, but more fine-grained. E.g. perhaps a chroot jail with symlinks to the places that you want to give the script access. Indeed, the first run of the script could be to generate the symlink commands you'd need to execute before it really executes. If you don't like the permissions it wants, you just exit the jail, kill the parent process, and move on with your life.
Unfortunately, it doesn't look like it went anywhere even in the OLPC world... I'm not very familiar with OLPC, but the fact it carries a 2007 timestamp isn't very encouraging. I wonder if it fell victim to the "sugar" watering down of the project :-(
Which is why Linux, BSD's and most Unix versions have a wide range of more restrictive access control methods,such as various forms of containers, jails and VM's...
Personally I run pretty much everything in containers. Not always segregated from each others, but certainly segregated from most of the data I care about. All larger projects get their own containers or VMs, and I have several "scratch" VM's and containers of various types that I don't care if I lose.
Spawning a Virtualbox VM or LXC container (or equivalent) is so quick and painless today that there are few excuses to running all kinds of stuff unrestricted.
Of course they can: Via network interfaces (which can be firewalled). Via shared directories on shared filesystems. Etc. With e.g. LXC the extent of isolation is can be controlled at a very detailed level. In practice, though, very little stuff needs more than a network connection to interact with each others, and very few applications actually have any business interacting with the other applications I run other than in very specific circumstances.
This is not to say that I run everything isolated from everything else. I have a "unsafe" VM for example where I compile and mess around with a lot of public code I don't want to evaluate the security of. To get further into my network from that one still takes a little bit of work. I also group together various things based on tasks.
But random code I don't have a reason to trust won't go straight into my normal user account on my laptop.
Note that a "reason to trust" can be as simple as "has been signed by the Debian packagers" for some systems. It's a trade off.
This. If you give me a shell script, I can curl it without piping it to a shell first so I can see what it's going to do. Unlike an installer on Windows where I have no clue what's going on.
Which is all interesting, except the shell script is a wrapper on "download this tarball and unpack it" or "download this rpm/deb and install it." So whatever security concerns existed on those approaches, you only concealed them. Why exactly?
I wish we had shell script installers that are 1. easily proofreadable, and 2. served over SSL, like this:
#!/bin/bash
#
# Installs a product from the Internet.
# PLEASE READ CAREFULLY!
#
mkdir /tmp/foo-installer
cd /tmp/foo-installer
cat > file_2.sh <<________EOF_file2.sh________________________________________
A very long script here....
A very long script here....
A very long script here....
________EOF_file2.sh________________________________________
base64 -d > file2.png <<________EOF_file2.png_______________________________________
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAAlwSFlz
AAAN1wAADdcBQiibeAAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAAATdEVY
dFRpdGxlAE9wdGljYWwgRHJpdmU+Z7oMAAABkUlEQVQ4jaWSvy9DURTHv6d9ty0tSgivkdBUkGgR
GotNxGoXjY21SJp0ag2CR8SE2oQ0Qiw2RPwDSASLkDL5EbwOlDZpj6mJ5z2/4puc5eZ7P/ec7z3E
zPiPJKPDjsF4q7u2cvj2XvVbhUjuTPd2HhIlAKCd2f0lwD+0KsuVZTGrTTTcPyRfhZBSP3VAzAz/
0KrsLHZsZbNZ8fzyFiemoxzlzg5i/Te/GsFTI08mru7CRpeUmckIwEEQkqHRsPszgIxCVJSJAaZc
H0BtPm9zmc/bnI2vrewTm+KhUHhZY2ZmTU0p4wu7e9tspN29bZ5Sxhc++k2fX2cg0N3VA1V91FV3
Vw8YCOgy0BxIkv3k9Bg+b4tutKvrBCRJsn8LAICK8gpcXJ4jlUpBTT5BCAEAcJaU6ryGALPZjAKb
DSYTwWIRyGTSSGfSsDscOq8uAwAoLMx3SWAA+X8ig63XAYgQXVyaR1FRMaqqXPC469BY3wSXXI2N
zXUQIarxG+3B7JwSYdYa8/CRYGjsR8BfZJjBX/QObiW573fRhdIAAAAASUVORK5CYII=
________EOF_file2.png_______________________________________
While I agree that there should be some more transparency with the install process, my problem with this is more practical: because I've installed via a non-standard means, how do I uninstall? How do other packages of software know I have meteor installed as a prerequisite? How do I easily ensure I have the latest version? How do I lock my install to a particular version to avoid breaking changes in new versions?
Whilst the security aspect is a background concern, these functional concerns are far more important to me. Because npm or some other system wasn't used, meteor is now an outlier and doesn't easily fit into most of my development flow. I've now been burdened with an external maintenance process that requires separate tools and workflow to accommodate.
Honestly, that's the biggest turn-off I have about meteor right now. Hopefully that will change before the big 1.0.
At least it's https; I've seen sites on HN recently[1] that suggest you run code pulled over plain http, as if that wasn't an even more horrible security risk than just blindly running a script from the Internet.
Heh the least they could do is put that into a batch file to be downloaded and clicked on to run.
Chocolatey is sort of like an alternative apt-get for Windows, except that it doesn't need s sudo command and your password to install software. It uses cinst to install stuff:
cinst firefox
Installs Firefox.
The UAC asks the current user to allow the setup program to run and that is about it. No password needed to install like apt-get has.
Oh yeah if your PC doesn't have Powershell installed you are SOL if you try to use that command to install Chocolatey. Some administrators remove it because it can be used to install software without being known to the user.
Right, because UAC assumes someone who is logged in as an admin is supposed to be. I configure sudo like this on some of my dev machines, easier and I don't care about them (usually just VMs).
Why not just restrict the execution policy? I don't really know PS thta well, but doesn't that stop arbitrary (or any) scripts?
I really like instructions like this because I understand easily what needs to be done. Probably the content of the script will also be easy to read. Of course, I will never do a copy paste of these instructions. I will redirect to a file and read it before executing. And if I have doubts, I launch a VM.
When I want to make something unique and truly useful, I'd like to get to it. I want to waste as little time as possible on boilerplate and infrastructure.
Yeah, I feel the sentiment. When I read this I was like "really? 5 minutes? Are we really learning anything other than how to follow instructions here?". But I'm in a bad mood so I have to admit I'm being unfair. There's a part of me that's getting a little tired of these kinds of posts because they're often disingenuous. You're really not going to learn or build anything of real use in under 5 minutes. It's definitely a cool marketing ploy for both Meteor, who get some exposure, and Mailgun who may get some new paying customers.
But again, I'm being unfair. While what I said before still stands, there is the fact that I doubt anyone expects you to truly learn the framework in 5 minutes. It's just supposed to be an example of how easy it is to get started. And it works I guess. I personally have never gotten much out of the whole "X in Y time" genre of tutorials but I'm sure others do. Because I'm not new to programming I prefer to take my time and build out my own ideas as I follow these things. So while I read them I'm not actually following each step. I'm just understanding how you get from A to B, translating that to other tasks, and using pieces of the articles as I need them to suit my purposes if that makes sense.
Fair enough. But this is still not teaching me much about actually writing an app in Meteor. It tells me to type the code in, not how it works or what it all means.
To use the calculator metaphor it would like saying: "enter 75345 + 3455 / 4, there's your taxes!"
I see. For me, a beginner programmer, this type of thing is really helpful in explaining what you can do with the language/framework and what the structure of build/deploy looks like.
Meteor sounded like a really good concept and I wanted to give it a decent shot. However I could not find a getting started project. The ones I found were very trivial and did not go much into details. I couldnt really find a lot of documentation about how to create an app which used 40-50% of the features which will be used by the majority of the crowd. But I will give it another shot and probably write a polls app (ala Django getting started) in meteor.
The parties examples only uses a static map (lame), they make no use of google maps or leaflets. Try using an infoWindow. You can't, it's not easy. You're productive will be stone walled with the simplest of integration. (This is a limit of constant regions and how meteor handles controlling a piece of the dom). Working with maps or third party libraries is a common task.
So, given that common tasks become stone walled and meteor promises productive. I'm waiting for 1.0, meteor is all too young.
I do love some parts of the pattern. I'm surprised that it hasn't been done before; like years ago.
As much as I dislike the whiny tone of your comment, you have a point: Meteor has problems integrating with some libraries. If a smart-package doesn't exist for it, the odds of it working are slim. (Try getting jquery ui to work...)
Part of this is because the Meteor use of reactive programming is very different.
Regarding the whining: projects like this take time and effort to create. Wanting something "a year ago" ignores the reality that this is what we have now, and for all it's warts, it's good!
It is also possible that while Meteor gets to 1.0 other frameworks will incorporate some of its features/patterns..
I'd check it from time to time just to know what it is doing...
That's correct. Here is a quote from the meteor blog announcing this feature: "
But there's more than just an API. We've partnered with Rackspace's Mailgun team so that every app deployed with $ meteor deploy can send email right away, without any annoying configuration process. These automatic accounts are capped at 200 messages a day, but of course you're not tied to them. You can use any SMTP server (your own box, a paid Mailgun account, or anything else) just by setting the $MAIL_URL environment variables, whether you're using our deploy servers or running your own bundles."
I tried it, sent email to myself. Never received it. I typed everything correct except I replaced the email with my own email orionblastar@gmail.com there was no error messages as well.
Do I have to install things like sendmail to make it work? If so that needs to be in the documentation.
Yes I did the meteor add email part, I followed every step.
It looks like you haven't actually deployed the code. Once deployed a free Mailgun account is created for you behind the scenes and assigned to your app. To test locally you need to create a Mailgun account and follow instructions from the "Extra optional step" section.
That is because I don't have a web site to deploy to yet. I wanted to test it on my Ubuntu box on Apache first before deploying. Why do I have to create an account on some other web site just so I can send email on my local Ubuntu machine?
Just curious, how does Meteor deal with concurrency issues where multiple clients are making changes to the same objects? Does last update win? How does this get reflected back to the UI?
Brief example: A grocery list that both my wife and I are editing, deleting, adding, and re-arranging at the same time.
I agree that there's a whole lot of Mongo hate on here, but it falls into two categories:
1) Teams who started with Mongo (which makes sense when your schema is still in flux and you are still feeling out what you want it to finally be) then stuck with it when they should have moved to an RDBMS due to their use case, but never did and then find out that Mongo doesn't support features that any RDBMS from the 90's would.
2) Old school RDBMS people who are, as Steve Yegge would say "software conservatives." They love the way RDBMS's force people to really put thought into their data modeling upfront, and believe that anything that allows people more flexibility is opening the door to increasing amounts of chaos. Plus they hate the thought of returning to the dark ages when databases didn't all use SQL, and everyone had to learn a new query language for a new DB.
FYI: I've heard Meteor is planning on allowing use of other databases. I would particularly be keen on use of RethinkDB. I really like what those guys have been doing so far.
That doesn't seem very accurate. Plenty of "how do I shot database?" people are very anti-mongo too. Some of that may well be because they feel mongo gets more mindshare than their preferred nondb, but don't blame postgresql users for that.
Great tutorial! If only there was an easy way to store the entered addresses in a database? Maybe that could be done in the next 5 minutes? :) I've had a few projects which where basically nothing more than just what was in the article. Meteor's builtin deploy and free Mailgun will fit perfect for cases like that.
The great thing about Rails (and Django) was that it was born in the wild. It was built in the process of solving a real world problem, and generalized/abstracted from there. Meteor lacks that type of genesis, and I wonder if that's important.
Aren't we all scared that some time in the future from now, new kids will have new tools that will make programming a totally customizable and super-performing web application as trivial as for example dragging some component here and there, like for us has been working with new generation programming environments, compared to i.e. coding asm?
This is a part of the hidden feeling I guess..
Also that then, our present efforts and knowledge will be culturally relevant but totally unnecessary for developing great new generation apps ?
But...... we have what we have now, and we still code because we like it NOW, so we should accept the passing of time (and all evolutions it will bring) and think that we are still doing what we enjoy doing and that we have the luck of making a life out of it, possibly :)
Only moment to be concerned about the future is when they'll invent a time machine..
You're likely being down voted because since the invention of programming the field has been continuously becoming "easier" often by leaps and bounds. However, programmers always remain at the edge of the boundary so there is continuously more work for programmers, not less. Every component of what made things "easy" can be improved by making it more flexible, performant etc. and doing this most believe will always require a skilled programmer.
But to play devils advocate, if we were to create true artificial intelligence (I guess it would just be intelligence at that point) then not only would programmers be obsolete, but all of humanity would be obsolete. We'd all just be WALL-E style mouths to feed. This seems difficult to imagine, but we already see it happening in some ways. Unemployment is high almost everywhere and there's no fundamental economic law that every human on the planet can contribute sufficiently to match said human's consumption.
Essentially what this means is we have two pretty rough options. First, all of these people fall under the welfare state. The homeless and hungry all get what they need through governments, NGOs and charities. The other is the Darwinian approach, nature's great equalizer. Both of these options suck pretty hard, but that may be the world we're looking at until our robot overlords turn us into batteries (although it's more likely we'd become pets if anything at all).
Get started to Meteor? I never create web app so quickly! For the customization, it depends what are your needs. Meteor is clearly cool to make collaborative web app;
If it's about Mailgun, you can get started for free without any configuration and if you want to send more than 300 emails/day later, you can create a mailgun account and easily integrate your own SMTP credentials into the app using the steps outlined in the blog.
This is tough for me to answer objectively, but I'll do my best.
Both services offer many of the same features and eliminate the pain of managing your own email server. Both services will achieve better deliverability at scale than managing your own server unless you know what you are doing and most people aren't interested in diving that deep into email.
Mailgun is very focused on serving developers and that guides our product roadmap. Therefore, we don't offer features like WYSYWIG newsletter creation tools. We build everything API first and we strive to make them RESTful, intuitive and well documented. Admittedly, our GUI / control panel is not the strongest part of the product. We also focus a lot on incoming email and we are pretty proud of our inbound email parsing through Routes. Mailgun is owned by Rackspace (acquired in Aug 2012).
Sendgrid is definitely the largest transactional email sender in the market. I recently read they do something like 7 billion emails monthly. They have more tools for non-developers like newsletter creators and support language wrappers that some developers prefer. They also offer inbound through their Parse App. Sendgrid is an independent, private company that has raised $27.4mm in funding according to Crunchbase [1].
My recommendation would be to try both - the docs are all online and both offer free plans to test with.
Mailgun sounds like a really good fit for me. I'm running a couchdb server, and I want to set it up to POST to my DB. Dump straight into my document store, life is good.
I did a quick try at it and ran into a 415 from couchdb, which means mailgun didn't send json. Is there a way to configure a route to do that? If not, I'll have to write a custom _update handler.
Our SendGrid experience has been middling. We have fought a half dozen of bugs -- the week I was implementing it our first app I had seven tickets open in their support system -- with admin screens that time out or don't work, APIs that time out, etc. Everything from the APIs to the admin just feels a bit unfinished and amateurish.
Support has been very lacking. At one point I had waited a long time (a week?) for a ticket response while they said they would investigate, and suddenly they just closed the ticket with no explanation. I felt like I had to fight to get any attention.
That said, its delivery seems reliable.
We have since switched to Mailgun for a lot of stuff, and will be migrating the rest soon. Mailgun has been rock solid from the start, the admin screens are fast, the APIs just make sense, and they were really responsive when we asked about a missing feature. Unlike SendGrid where the delivery log took ages to show results, Mailgun's equivalent page is really snappy. A big time saver when someone complains about not receiving a password or something.
It's basically the same thing as Rails people saying "you can make a blog in five minutes!", because you really can't.
(This isn't a knock against Rails, it's just that five minutes barely gives you time to open the documentation and start to actually get an idea of how a library/framework is designed.)
Why is this getting downvoted so much? Just the language I hope. because there is a point there.
Everytime I see a meteor post, I get the feeling the article is telling me I'd be a fool to use anything else.
Assuming that's so, can we start talking about things like PCI compliant meteor apps. And what the security landscape looks like since you can interact with the data store via your browser's javascript console.
"And what the security landscape looks like since you can interact with the data store via your browser's javascript console."
By default, Meteor is in a "development" mode where all the security is off while you get the app doing what you want on localhost. The security is implemented later by turning off the autopublish feature and using authentication at the pub/sub level in the "model" component of the MVVM stack. At this point, when you try to do what they do in the demo, and change data from the browser console, it will make the change in the client for a split second, but that change is rejected at the model level, and the client resyncs with the model and the change is undone in the view.
BTW, I only "learned" (i'm not at all an expert) Meteor a few weeks ago (although I've been following the project since they first announced it 10?? or so months ago.) It's actually pretty straightforward once you get the hang of it. But it is unmistakably a BIG FRAMEWORK in the Rails sense, whereas everyhing else in the Node world is truly modular in the Node fashion, with full transparency into what's going on. For people who like that, check out Derby, and it looks like there is some more stuff in the pipeline with Rendr by the dudes at AirBnB.
The data store on the client side isn't the whole data store, it's the things you've published and subscribed to, which can change easily based on authentication, your userId, or however else you program it.
Meteor has an "insecure" mode that is active by default where everything is published. Don't use that in production.
If not, it seems like a pretty bad practice for delivering fast webapps.
Edit: In general, Meteor.isServer seems like a great way for developers to shoot themselves in the foot: