Hi Johan,

I think the answer depends on how you're using the blocks. At its most basic, you can apply permissions to blocks in the same way as pages, the difference being that, if you want to set permissions on a folder of blocks, you need to do that via admin rather than in the CMS as asset folders aren't editable in that way via the CMS:

If you are rendering blocks in a contentarea via PropertyFor() these permissions should be taken into account. If you're accessing the contents of a contentarea programmatically, use the FilteredItems method rather than Items to get the items remaining when personalisation and permissions have been taken into account.

When showing or hiding individual blocks based on the context of the page view (e.g. whether the user is logged in), I would generally use personalisation to achieve that as it gives you the flexibility to replace the missing blocks with an alternative, something you wouldn't get through using permissions alone.

If I understand your scenario correctly, you have a block type which should never show to users unless they are logged in. Assuming you're adding this block to pages via a contentarea and rendering using PropertyFor(), you could create your own implementation of ContentAreaRenderer and override RenderContentAreaItems, removing any items of that block type.

Finally, it's worth mentioning that you can use FilterContentForVisitors on blocks given the right circumstances as, confusing as this may sound, blocks are sometimes IContent. When blocks are used as a property in another model they are not IContent, if they are standalone blocks (and hence are persisted in IContentRepository) then they are IContent.