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.

Committed in: changeset:   8168:3f0f4746dc7e

Manually verified that the new cookie when used under https has the prefix. However
no automated test has been created. The liveserver tests uses http and I verify
that he cookie is missing the __Secure- prefix in this case. But I have no mechanism
to create a wsgi server with an https endpoint.

Opened issue 2551373 to address this testing issue.

Also note because people could want to run a tracker on a subdomain (i.e. path != /),
the __HOST- prefix is not applicable. Also we send the domain attribute.
Hence use of __Secure-.