from: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes

  Cookie prefixes

  Because of the design of the cookie mechanism, a server can't confirm
  that a cookie was set from a secure origin or even tell where a cookie was originally set.

  A vulnerable application on a subdomain can set a cookie with the Domain attribute,
  which gives access to that cookie on all other subdomains. This mechanism can be
  abused in a session fixation attack. See session fixation for primary mitigation methods.

  As a defense-in-depth measure, however, you can use cookie prefixes to assert
  specific facts about the cookie. Two prefixes are available:

    __Host-: If a cookie name has this prefix, it's accepted in a Set-Cookie
      header only if it's also marked with the Secure attribute, was sent from a
      secure origin, does not include a Domain attribute, and has the Path attribute
      set to /. In other words, the cookie is domain-locked.
    __Secure-: If a cookie name has this prefix, it's accepted in a Set-Cookie header
       only if it's marked with the Secure attribute and was sent from a secure origin.
       This is weaker than the __Host- prefix.

adding __Secure to the session cookie will make sure that it is available only with
a secure flag and https url. We already set the secure flag if the tracker url starts
with 'https:'.

If received from an http url, the cookie will not be accepted by the browser.