Don’t worry, this does not affect the security of your Internet connection, but it does affect how the .NET platform views your application. So - yes, you can activate it without danger, but if possible, you should declare the access level of your application in your code to increase security. Explain the details:
Full trust means that your application needs all the rights granted by the .NET platform. As a developer, you announce what level of trust your application requires in order to run, this is called "code access protection." Code access security means that you tell the compiler through the attributes what actions your code needs to succeed.
The .NET framework, in turn, evaluates the degree of trust in the application: For example, if you deploy the application to a remote computer that can be accessed through a network resource outside your intranet *), then the .NET Framework gives it less than Full Trust. This is known as the “evidence-based” security model , which is implemented using so-called managed code .
Managed code means that your .NET application is compiled in MSIL (Micros oft I ntermediate L anguage) and "just in time" (that is, when you execute it, unless you decide to create your own code explicitly through NGEN before ) into a machine language specific to the processor. This allows you to set an additional level of abstraction, which, in turn, allows the .NET Framework to control what your code is doing and allow it or, if not, throw a security exception.
All the code that you write for the .NET platform in one of the C # or VB.NET languages corresponds to the default-driven code. However, there are (very rare) situations where you want to inject unmanaged code - also known as "unsafe code" (in .NET terminology). One way is to create a "unsafe" section in your code (which I mention here only for completeness, i.e., in the event that you may have encountered it in the source code).
As I mentioned earlier, you specify what the code does through the attributes, but you can also change the rules that apply on your local computer to change this behavior using the .NET security settings. It is usually recommended that you specify as accurately as possible what rights your application needs and how you can limit them.
If you're interested, you can find more here: Exploring the .NET Framework Security Model
*) Thanks for your hint, Damien! In fact, earlier versions of the framework gave resources on the network (network resources) less trust, and for desktops and local .NET 4 intranets, full trust.