shartte

Hashes of known good drivers should be whitelisted explicitly if they are known to have been signed correctly before revocation. Direct trust should trump a PKI here.

> Security bugs aren't really an issue because you are just using the Steam app to navigate 1 site, Valve's. You only see what Valve presents.

I don't think you want to explain that to the payment processors that also run within that same embedded Chromium when you buy a game on steam.

It looks interesting, but seems to be dead.

The repository has virtually no activity since september 2020.

I think the parent poster meant that if X.509 Name Constraints were widely deployed, Visas CA could be limited to Visa's TLD+1s. In the same way, government affiliated CAs could be limited to their own country TLDs, or a development CA could be limited to localhost.

If they are using GMail for work, the DNS just points to GMails actual server and authenticates using DKIM as well. Google for Work will provide you with the necessary DNS entries to set. Obviously this will not work with their free offering, you'll need to fork over $6/month for this.

I believe this is the default in Spring Boot. Logback is used by their starters (see https://docs.spring.io/spring-boot/docs/current/reference/ht...).

You can disregard a combination of log4j-api+log4j-over-slf4j (as is used by default by Spring Boot) since the actual vulnerability is not in the Log4j2 API, but rather in the actual logging implementation. So forwarding of the Log4j2 API via slf4j to logback is unaffected.

The sole reason really is that the contents of a HttpOnly cookie cannot be exfiltrated by an XSS-exploit, while a JWT stored in localStorage could be. This would probably only make a difference if the JWT either has a long lifetime, or is usable outside of the site's origin.

> It is good practice to always use the SameSite directive with cookies as this provides protection against CSRF attacks.

Be careful with assuming SameSite fully protects from CSRF attacks. I thought it does, but then I read what "site" actually refers to in the context of same site (eTLD+1).

If the eTLD+1 (i.e. company.com) is not listed on the Public Suffix List, even SameSite=strict cookies for a.company.com will still be sent for requests initiated from b.company.com