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.
@sgued @sinbad your ref to tracking requiring consent regardless of the tech used though, I'll admit is a trickier subject I'm not well versed in the legalities of.
AFAIK, in the UK at least, we don't have consent laws as such for that. GDPR includes clauses on the right to erasure, and as a person you can issue SARs to learn what information a party holds about you, making it possible to obtain and then request deletion of such data, but generally their collection just requires privacy policy.
@sgued @sinbad in other words, companies tend to just rely on implied consent for actual data grabs. Their grab is outlined in their privacy policy, as should be a list of other parties they share with, and your use of the website + registration to, and submission of your data via forms and such, acts as implied consent with that policy.
It's specifically the dumping of data into cookies which we have actual, explicit opt-in requirements for. And also the use of contact info for email marketing
@dev_ric There may be some country-specific questions, but the GDPR is pretty clear. The first point covers the case "the cookie/localstorage/whateverstorage is required for the site to function", which is what covers sessions cookies (as long as the session is not also used for tracking). GDPR is generic over any automated data handling. Not referencing a specific technology, and it shouldn't. It also applies to games, native apps, or even digital notes taken by support in a phone call.
@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.