I'm new to meteor and I've reading a lot however I'm a little confused around the meteor.users collection and the best way to use it. My interpretation of the best practice guide is that meteor.users collection should only be used for managing the accounts.ui package; email, password and username. The guide states that profile is insecure, a flaw in the original meteor design and should not be used.
So my question is, if I want to create a user profile that contains things like first name, last name, age, address, avatar etc do I create a separate collection like 'userProfile' and link it using the meteor.userid or am I suppose to keep it in the meteor.users collection somehow
Common practice is to put user profile information such as the kind you're describing into Meteor.user().profile. In fact people often do much more, for example memberships in groups, arrays of postIds, all kinds of things. Keeping a separate 1:1 profile collection is an option but there's no fundamental reason to do so that I can think of. On the contrary it makes things just a bit more complicated.
Update: As @jonatan points out in the comments, the Meteor Guide has now unrecommended the use of the profile field in the user document.
Instead they recommend storing custom user information as top-level keys in the user document. This is not only more secure but also more performant since incremental updates can get published over DDP on top-level keys but on sub-keys.
Meteor.user().profile is always auto-published for the current user even after the autopublish package has been removed. Information about other users is not published at all unless you explicitly setup a publication. In that case care must be taken to only publish those fields that should be visible to other users. For example you may only want to publish the usernames of other users and not their email addresses for privacy. You would do this with:
Meteor.publish('otherUsers',function(){
return Meteor.users.find({},{ fields: { 'profile.username': 1 }});
});
You might also restrict the set of other users that is published based on them being connected in some way to the current user to avoid publishing all users all the time.
You should also avoid publishing the services key which contains security information about the user (ex: the bcrypt of their password). As @David Weldon points out in the comments, you shouldn't put other security information in the profile either and you probably want a deny rule on the user modifying their own profile from the client.