As everyone knows (or at least should know) it is not that Hive cannot have censorship, but the points of opportunity are decentralized, therefore if there was actual censorship on the platform, it would be possible to detect and expose, harming reputation of the tool that does censoring. It also means that as long as some app is not decentralized, it can censor all it wants.
Front-ends can block or alter user content, in fact they constantly do. They reinterpret crude formatting of posts into something appropriate for the web. They also reduce visibility of low reputation or muted posts. Finally, actually outside blockchain, they remove pictures uploaded to their image cache servers, if those pictures contain something illegal. All of above is expected and good, but if they can do that, they could repeat the process with malicious intent. That's why we have many ways to see the same content.
Hivemind, the backbone of many front-ends, has even more possibilities. First the database itself can be modified and such change would be later reflected in any tool that uses Hivemind APIs. But that would only last until replay. Not very convenient. However there is a mock mechanism. It is used for tests, but it is also perfect way to add elements to any block altering its effective content. Such change survives regeneration of database (f.e. you could add operation that deletes some "undesired" post). That's why we have many instances of Hivemind, many tools also use their own way of gathering and providing blockchain data to their users.
There is also a sort of "censorship" in the nodes - soft fork mechanism. Each node is free to decide which of incoming transactions to accept (as long as it is valid) and broadcast further. There is nothing strange in it. After all the transaction could have not reached the node at all, so not broadcasting it further does not break the rules of consensus. Of course, if only one node does it, there is no actual stopping effect, but the mechanism is used f.e. by RC plugin - formally not part of consensus, but mandatory for broadcasting nodes. When many nodes in the network agree to not broadcast transaction due to violation of RC rules, such transaction might not even reach producing witness. Witness plugin uses the same principle to limit amount of custom operations per user in single block or detect and not let private keys in memos to reach blockchain. There is a catch, a hole in the mechanism. Once dubious transaction reaches a block, it is accepted.
But what if we moved one step further? Hive was founded on sort of original sin - during struggle preceding the Steem-Hive split, the extra rules were put into consensus to not allow certain transactions from selected accounts to be executed (I actually have not seen those changes, but I've seen similar ones put in Steem later in retaliation - I just assume the original changes were of the same kind). The rules were explicit, users could still decide to either accept them or vote out witnesses that were using nodes with such code change. However the same can be achieved in covert way, just requires collusion among enough witnesses. Totally unavoidable. A true metal banhammer wrapped in plush.
The mechanism uses forking. All within existing consensus rules.
Let's say bob is a backup witness and he includes transaction from alice into his block B (built on top of block A). carol is next in schedule (block C) followed by dave (block D) - both colluding top witnesses. There is unwritten rule to drop all transactions from alice, but bob didn't know or did not follow. First, carol starts with not broadcasting B further and obviously by not confirming it for irreversibility - maybe fork will happen naturally? Low chance, since it is broadcast to many nodes, but still better than nothing. Before HF26 it would suffice for just the two consecutive witnesses to collude to drop block from bob (effectively also blocking alice), but with OBI there has to be enough collusion to at least prevent block B from becoming irreversible. carol knows that block B is breaking the rule and that dave is going to follow the rule. Therefore she can be confident that if she builds block C on top of A instead of B, dave will switch fork and build his block on top of C as alternative to B instead of on B, which is still main fork. This way other witnesses and nodes, even those that did not collude, will also switch fork, because once D is built, longer fork wins.
Since there is no guarantee that colluding witnesses are going to be scheduled after one that does not follow unwritten rules, it is preferable for the effectiveness of the mechanism if majority of witnesses are colluding. In fact, for total impregnability of the barrier, agreement of all top witnesses is required. If any of top witnesses did not collude, they are scheduled too frequently for the barrier to work and have too much backing to just hit them with fork every time. The witnesses don't need to know in advance if they are going to follow the rules or not. With a bit of risk it is enough if the colluding witness interprets lack of OBI confirmation for the "problematic" block as encouragement to drop it.
"But if top witnesses need to collude for the mechanism to be effective, isn't it as good as having the rule explicitly included in consensus?"
No. People might be "skeptical" if POTUS orders assassination of some American citizen, they might protest or even call for impeachment, but heart attacks, accidents and suicides happen. If no one knows, no one cares. The same with such mechanism. From the outside it will look like bob has problem with his network if he misses some blocks.
Why am I writing about such dangerous way to "rule from the shadows"? As a warning I guess. It is not just a thing specific to Hive. F.e. people are worried about Ethereum falling into the hands of powers-that-shouldn't-be. If those powers gain enough advantage, they could use similar mechanism to punish validators that don't follow suit, and slashing gives them even more leverage. They would probably even do it in broad daylight. But why have I even thought about it? Ok...
Before HF26 there were many bugs in RC, some of which caused nodes to include transactions that could not be afforded. There were also many transactions that were included due to nodes disagreeing on RC, mostly from tumultuous period of couple months after RC was introduced. Those bugs were fixed, also all messages from before HF26 about such events were silenced. Since then there should be no messages indicating such events in the log.
However instead of being all over the place like before, happening to random users and confirmed by random witnesses, now they follow certain pattern. For those that run RC enabled nodes: grep your logs for "Accepting " and draw your own conclusions. I have thought about above mentioned mechanism as a way to deal with the problem. However I've realized that the cure would be much worse than the disease. Thanks, 
The main problem is that currently users don't get a chance to see that the witnesses they are backing might be bending some rules. Maybe it would suffice to add virtual operation for such events and collect statistics to present on list of witnesses, similar to missed blocks? Certainly losing votes and reducing frequency of production pay would be enough of a deterrent. We could increase the depth to which you can fall into negative RC (no one should ever fall into negative so it wouldn't affect anyone except those that choose to circumvent the rules). The only true solution would be to include RC into consensus. It has many pros, but also some cons, and it is not trivial to switch such big mechanism as RC from non-consensus to consensus without starting from zero (which would mean for example that all RC delegations would disappear and need to be set again with some new consensus operation).
Anyway, above train of thought can be an example that solutions have to be looked at from all angles before being implemented, even if there is a legitimate reason for them to be needed. In particular, "how can this be abused" should be the first question.
