Implement compliance with GDPR. @patrys is already working on a detailed list of changes to add in Saleor. Once we have it, we'll create specific issues with details.
Let's start a project for this so I can file notes and you'll convert them to issues as you see fit.
Really happy to see all of this ! I have a few (or many) pages of the regulation left to be read for the end of this month.
I have one concern about Saleor & one of my contribution: #2020, which is GDPR compliant... without any surprises.
As I did not make through the whole GDPR regulation yet, I cannot confirm anything. But for now, I have a few points concerning the changes to be done.
What I'm thinking is that, we should not be able to set any cookie. Which means, we need to make sure it doesn't break anything and that we can impose a cookie free usage of Saleor (which is almost already the current case).
Now that we have our user that doesn't want of our cookies (or did not accept), when the user is going to submit a form, without any surprise... It's gonna fail, and the user is gonna get a 400 error. Which is really awesome!
To explain the awesomeness I see: our Saleor fork is not using the default template of CRSF errors, because... they were looking like a debug view.

It seems like a good place to put a message explaining to the user that they need to accept our cookies for security purposes to use those features. And thus explain why, etc.
Then, we have another issue: ajax requests.
Of course, ajax requests without a CRSF token will get a 403, which will make the user wonder why the button does nothing (e.g.: add to cart button). Here, we probably could add a notification on the screen explaining the issue.

By better transparency, I'm thinking that Saleor should list somewhere the cookies they are using.
I don't have made an English translation of the above screenshot, unlike the CRSF error page.
But here is a little summary: "We are using a mechanism of cookies provided by clients' web-browsers. Those cookies are internally used to ensure the correct workflow and secureness of our services[...]"--"Without cookies, the following features will be unavailable for usage: forms, sign-in and sign-up, carts and ordering."
| Cookie name | Expiration | Usage |
|--|--|--|
| cnil (same cookie as #2020 but was renamed) | after 3 months | to remember that you accepted our cookies. This cookie is created when you click on "I accept" |
| csrftoken | at the end of your session | This cookie is created when load a form. This is required to post forms to ensure your browser is not being hiijacked, that it is really you that tried to post this form and not an evil link (e.g.: mail link). |
| cart | after 1 year (10 years for Saleor master though) | This cookie keep in memory the content of your cart. This cookie is created when you click on "Add to cart". |
| sessionid | After 14 days | This cookie allow us to know that you are logged in in your account. |
This is something that may be important. Something we could whether put in the docs, maybe into a regulation section? And/ or in the generated protected pages.
I think the cookie box is enough as it is (except that we would need to add the opt-in). But I think, as the user cannot use the website without cookies, will need a bigger button to really make them click on it, as I experienced this with my users/ customers, despite the big default bootstrap button (#2020 is using the small variant of the button), they were browsing the website without clicking it. Even on mobile, where it's quite huge.
So I think, it's quite an important part to find a solution for.
Many website that want to counter this issue, are putting a modal on page loading. But I feel like it would make a user experience. In my case, even if we only see them once, I feel like they are really bothering the browsing experience as they are blocking the user from browsing.
I will continue to look into GDPR and will wait for @patrys to be on cookies issue.
"Cookies" are not the right term here. There are different kinds of cookies. For example the session cookie is used to keep track of the cart and we don't need a separate agreement to do that since this is the main reason of your visit. Tracking cookies on the other hand are used to gather information that is not critical to fulfill our obligations so they do need an explicit consent and cannot be enabled by default. I think it's more useful to think in terms of processing goals rather than focusing on the means.
Will the user on his account have the opportunity to check what he agreed to?
I think we can close this issue, since we have this project.
Most helpful comment
Let's start a project for this so I can file notes and you'll convert them to issues as you see fit.