Bitcoin 51% majority miner attack - question on the role of user activated soft forks as defense tactic If one mining entity has alone 52% hash power of the overall network, then this party can block transactions for example and try to "build" up a forked, longer chain while time passes, right?. As I understand this may take several weeks with only 52% hash power... 

Can someone please explain, how the feature of "user activated soft fork" may be an instrument for the network users to rescue and keep the "current" blockchain version, and escape from the attacker? How would this play out ideally from perspective of the users (full node users)

Thank you
A soft fork describes a situation in which the consensus rules of the network are tightened: in simple terms, something that was allowed before is no longer allowed. 

After a soft fork, old nodes will still be a part of the network, even if they are unaware of this rule-tightening. However, miners will need to craft blocks according to the new rules, or else the nodes running the new code will ignore their blocks. 

The term ‘user activated soft fork’ more specifically refers to a soft fork that is initiated by nodes, instead of miners. 

With that in mind, a user activated soft fork cannot protect against a 51% attack, because there is no way to tighten the rules which would exclude a single miner from being able to create blocks. A valid block requires no identifying information from the miner, it is simply seen by the network to either be valid, or invalid. 

Proof of work is the method by which the network’s history is secured. If this method fails, it is unclear how the network’s nodes could coordinate to continue onwards honestly. Some people have suggest changing to a different proof of work algorithm, but if an attacker can gain enough resources to outrun the entire honest network of SHA256 miners, I’m not sure I see any reason why they couldn’t just do the same for the next algorithm as well. 

Forking to a different consensus algorithm (ie, not proof of work) is another option, but I am yet to see an algorithm that provides the same security and economic guarantees that proof of work does, so this option has an unclear future at best. Such a change would likely require a hard fork to execute cleanly anyways, so it seems to be outside the scope of this question.