$secure Indicates that the cookie should only be transmitted over a secure HTTPS connection from the client. When set to TRUE, the cookie will only be set if a secure connection exists. On the server-side, it's on the programmer to send this kind of cookie only on secure connection (e.g. with respect to $_SERVER["HTTPS"]).

I have sympathy for such a change. However, we have to be aware of the consequences:

• sites that are accessible over both, http and https might currently rely on the "false"-flag for $secure to share cookies between both connection modes. If we change that flag, it's going to break these usecases. Looking at the adoption of HSTS and the fact, that many browsers don't easily fall back to http once they've accessed a site via https, I'm worried that the b/c impact of such a change does not outweigh the advantages.
• the flag must only be set to true if the site is on a secure connection - that means, that the Cookie class in both framework packages needs an additional check to only use a default-true for that flag if the site is running on an https connection
• the last comment also means that the default value for the flag in the function declaration will not reflect it's real default value in one of the connection modes

With that in mind, I think that changing the default to true on https connection would be a sensible decision for 5.x /cc @laoneo

$httpOnly When TRUE the cookie will be made accessible only through the HTTP protocol

I'm against a default-true for that flag. There are plenty of valid uses cases to access cookies via JS - pretty much every cookie, that is not security-related (like the session cookie is - that's why it has that flag set). So, deliberately using that flag when necessary is the more sensible default

pretty much every cookie, that is not security-related (like the session cookie is - that's why it has that flag set).

The session cookie has the same value as the CSRF which is widely available cookieValue = Joomla.getOptions('csrf.token') (if a page has a properly instantiated a Form) which invalidates (in most cases) the argument. Ok, this is missing the expiry date and some other flags but still gives Devs the main part and they could recreate the cookie client side. In sort, I'm supporting the idea for a default true value.

My 2c

The session cookie has the same value as the CSRF

Nope. The CSRF token is a random token which is stored in the session, it does NOT have the same value.

The CSRF token is a random token which is stored in the session, it does NOT have the same value.

My bad, you're right.

closed due to lack of interest