ClickOnce applications can request that they be granted permission to contact their site of origin.  In Visual Studio this is done by clicking on the Advanced button in the Security tab of the project properties and checking "Grant the application access to its site of origin."

This has the effect of adding a SameSite attribute onto the requested permission set XML:

<PermissionSet class="System.Security.PermissionSet" version="1" ID="Custom" SameSite="site">
  <IPermission class="System.Security.Permissions.FileDialogPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Access="Open" />
  <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Allowed="ApplicationIsolationByUser" UserQuota="512000" />
  <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="Assertion, UnmanagedCode, Execution, ControlThread, ControlEvidence, ControlPolicy, SerializationFormatter, ControlDomainPolicy, ControlPrincipal, ControlAppDomain, RemotingConfiguration, Infrastructure" />
  <IPermission class="System.Security.Permissions.UIPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Window="SafeTopLevelWindows" Clipboard="OwnClipboard" />
  <IPermission class="System.Drawing.Printing.PrintingPermission, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" version="1" Level="SafePrinting" />
</PermissionSet>

The SameSite attribute is ignored by the CLR unless we're reading the PermissionSet XML from a ClickOnce manifest.  In that case, if we see the value of SameSite="site", we'll add in any appropriate permissions for the ClickOnce application to communicate with its site of origin.

So what permissions does SameSite="site" grant exactly?  The answer is basically what you would expect, a WebPermission with Connect access back to the site the application was deployed from.  So if your application lived on http://www.fantasticsoftware.com/KillerApplicaton/KillerApplication.application you would be given a web permission with connect access to anything matching the regular expression:

(http|https)://www.fantasticsoftware.com/.*

Applications deployed over https will only receive permission to connect back via https, and applications deployed over a non-default port will have connect access back to that port instead of the default one.

If the application is run directly from the file system, for example off of a network share, instead of a WebPermission it will get a FileIOPermission for read and path discovery back to the path it was deployed from.  \\InternalSoftware\Software\AccountingApplication\AccountingApplication.application will get access to \\InternalSoftware\Software\AccountingApplication for instance.

In the event that the application already had a WebPermission or FileIOPermission in its requested permission set, then the same site permission will be unioned with the existing permission to form the final request set.  You can see the final permission set by examining the DefaultRequestSet property of an ApplicationSecurityInfo object constructed with the ActivationContext of your ClickOnce application.

Why go through all this trouble instead of just hard coding the WebPermission or FileIOPermission into the manifest itself?  By adding this level of abstraction, the application author does not need to know where the application will finally be deployed from.  If your group builds a ClickOnce application, specifying SameSite="site" allows the IT group which is hosting the application to decide which location makes the most sense.  It also gives them the freedom to move the application's location if need be without having to contact you to get the application updated.