Recent searches
Search options
LB: I don’t have cookie consent banners on my websites because I don’t need cookies: a result of not needing to keep any creepy persistent state about visitors (and not doing it just cause everyone else does)
@sinbad same. There's literally no legitimate need for cookies beyond tracking. Sessions have been around for decades and make way more sense from every security and privacy perspective. They just don't work well for cross-site data sharing... i.e. tracking. 
There's even local storage, if data really needs storing client-side. Works the same as cookies but as RAM for JS, rather than ROM, and inaccessible by other sites.
"Essential cookies required for functionality" is a straight up lie.
@dev_ric @sinbad that's just wrong. Sessions are built on top of cookies... And using localstorage for tracking would also require consent banners.
In the law the tech doesn't Mather. What matters is whether it's necessary and logical for the functioning of the website. If is, then regardless of the tech you don't need consent.
@sgued @sinbad session cookies only store an ID, which the server uses to fetch server-stored data associated with that ID. Session cookies also expire after a set time of inactivity - has to be less than 15 minutes for ecommerce sites, as per PCI-DSS compliance requirements. Thus session cookies are exempt from opt-in requirements.
Localstorage doesn't support XSS access and thus can't be used for tracking. It also doesn't create files so isn't a privacy concern. LS is exempt from opt-in too.
PCI-DSS is a payment thing. Not relevant to most websites sessions, which use another session, generally handled through a third-party service to handle payment...
Very few websites have 15min long sessions...
XSS is a type of vulnerability, not a thing you can "support".
You don't need cross-site access to do tracking, and first-party tracking (through IP, cookies, LocalStorage or whatever) also requires consent.
...PCI-DSS is actually relevant to everybody with a merchant bank, not just ecomm and not even just websites.
Few websites comply with the expiry requirement, granted. But as a web host we enforce it across all websites.
XSS itself is a tech, not a vulnerability. There are tonnes of XSS vulnerabilities for sure, where data is unreasonably exposed via the tech, but there are also legitimate use cases. Sadly, such as profiling by ad networks.
@dev_ric @sinbad
1. XSS refers to the vulnerability. Nobody says XSS to talk about intended cross-site scripts
2. Cross-site scripts have access to the LocalStorage
3. You don't need cross-site scripts to track users with third party cookies. You can have a first-party script that makes requests to a third-party that sets cookies for tracking.
If you use a third-party payment provider, PCI-DSS is irrelevant because the card info never goes through you: https://stripe.com/en-fr/guides/pci-compliance#handling-card-data
@sgued @sinbad PCI-DSS compliance comes in 3 tiers. A, AA, and AAA. If handling card data directly, you need AAA compliance. You're still generally handling things like billing and delivery address info though even if using a hosted payment solution and thus, at the discretion of your merchant bank, may still require A or AA level compliance. Compliance isn't just a website test - it's all about employee privileges and office security etc too.