Problem: The initially unconfigured Consent Management Platform ('cookie banner') covers the link to the privacy policy.

Explanation: An accessible privacy policy is an independent page linked through the footer and not blocked by overlays. Art. 12(1) GDPR requires controllers to provide information about data processing in a transparent, intelligible, and easily accessible form. If the Consent Management Platform ('cookie banner') blocks the link to the privacy policy, the Consent Management Platform itself should link the privacy policy.

Fix: Placing a reference to the privacy policy in the Consent Management Platform and disabling the Consent Management Platform on the privacy policy page fixes the problem by making the privacy policy always accessible.

Problem: There is no "reject all" button next to the "accept all" button on the Consent Management Platform (cf. Figure 1).

Explanation: The Consent Management Platform must follow the principle of equally simple withdrawing and giving consent according to Art. 7 par. 3 GDPR. This means that withdrawing and giving consent must be achievable with the same number of clicks. This requirement is further reinforced by ePrivacy Directive Recital 66, which states that consent to data processing should not be more burdensome to withdraw than to give. Additionally, Art. 4(11) GDPR defines valid consent as a freely given, specific, informed, and unambiguous indication of the data subject's wishes – a standard that cannot be met if refusing is significantly harder than agreeing.

Fix: Adding the button to the same layer as the "accept all" button solves the problem.

Problem: All switches on the custom preference modal are enabled by default.

Explanation: The Consent Management Platform must follow Data protection by design and by default according to Art. 25 par. 2 GDPR. That means that in every possible way, the visitor always has to opt-in for any optional data collection and processing. The Planet49 judgment of the European Court of Justice confirms in 2020 that pre-ticked checkboxes are not a valid consent from the user. Art. 4(11) GDPR defines valid consent as requiring an unambiguous indication of the data subject's wishes — a standard pre-enabled switches cannot meet.

The European Data Protection Board (EDPB) further classifies misleading toggle designs as the dark pattern 'Hidden in Plain Sight': color schemes or visual designs that make the non-consenting choice less noticeable are considered unfair and result in invalid consent, even without an outright deceptive layout.

Fix: Set all non-essential cookie switches to 'disabled' by default and make their state clearly perceivable to users. The visual difference between an enabled and disabled toggle must be unambiguous.

Problem: The Consent Management Platform groups all essential cookies (nuxt-session, cookie_control_consent, cookie_control_enabled_cookies) under a single vague description: "These cookies are needed for the stores functionality." No individual purpose, retention period, or legal basis is stated for any cookie. Users are presented with technical identifiers they cannot reasonably interpret.

Explanation: The transparency principle under Art. 5(1)(a) GDPR requires that personal data is processed in a transparent manner. Art. 13(1)(c) and (e) GDPR specifically require that users are informed about the purposes of each processing activity and the period for which data will be stored at the time of collection. Art. 5(3) of the ePrivacy Directive additionally requires that users receive clear and comprehensive information about cookies before they are placed. For optional cookies, the EDPB Guidelines 05/2020 on consent require that consent is informed — users must understand what they are agreeing to. A technical cookie ID such as nuxt-session without any explanation of the data it stores, why it is necessary, and when it is deleted does not meet any of these standards.

Fix: Each cookie (or at minimum each consent category) must be described in plain language, stating: (1) what data is stored, (2) why it is necessary or what purpose it serves, and (3) how long it persists. This applies to essential cookies too — the fact that they do not require consent does not remove the obligation to inform users about them.

Problem: Consent for the trailer video, although hosted by a third party ('krimskramskarton.de', can be seen using the developer tools), is hidden in the category "functional cookies." (This problem becomes apparent when functional cookies are deactivated and the trailer video on the start page is clicked on.)

Explanation: Following Art. 4(11) GDPR and Art. 6 GDPR, the Consent Management Platform's third-party service descriptions must be specific and accurate. Consent must be clearly distinguishable from other matters and written in clear, plain language. Hiding a third-party service under a vague or incorrect category is an example of the dark pattern 'Sneak into Basket' — the user is led to believe they are consenting to one thing while unknowingly consenting to another.

'Essential' cookies do not require user consent but must be strictly necessary for the website's core functionality (e.g., keeping a user logged in or maintaining a shopping cart). A third-party video host is not essential to core functionality.

'Functional' or 'functionality cookies' are used to remember user preferences and settings to enhance the browsing experience. Functionality cookies require user consent and must be listed separately from essential cookies.

Third-party services require their own distinct consent entry. Additionally, Art. 13 GDPR requires that users are informed about all third-party recipients of their data and the legal basis for that transfer.

Fix: Self-hosting the video is the easiest solution because it does not require consent. If the video should stay on a third party's server, separate consent for the third party is required. The third-party server has to be located in the European Economic Area (EEA) or a country with an adequate level of protection. Otherwise, a conflict between EU privacy law and US surveillance law could make it impossible to ask for the user's consent.

Problem: The X (formerly Twitter) button, whose scripts are hosted by a third party (can be seen in the network tab and through storage inspection), is not blocked by the Consent Management Platform and cannot be blocked by the user at all.

Explanation: The Consent Management Platform must block by default any foreign web content to follow the principle of required consent for processing (Art. 6 par. 1 lit. a GDPR). Including foreign web content leads to a direct connection between client and foreign server. The connection exposes user data to the foreign server to which the user has not consented. The Consent Management Platform must include a content blocker that requests explicit consent before establishing a connection to the third party and exposing user data.

Fix: Removing the button or blocking it as long as no consent is given is a possible solution. Self-hosting is not possible because the scripts are not open-source.

Problem: The main font is another problem. Like the X (formerly Twitter) button, the page loads the font from a third-party server without obtaining consent first.

Explanation: Even fonts must be hosted locally or require the visitor's consent to follow the principle of Lawfulness of processing according to Art. 6 par. 1 lit. a GDPR. Every request to a third-party font server transmits the user's IP address to that server — constituting a transfer of personal data without a legal basis. The LG Munich (source) decided that using fonts hosted by a third party cannot be justified with legitimate interests.

Fix: Using a different font, obtaining user consent or self-hosting the font are possible solutions.

@font-face {
  font-display: swap;
  font-family: 'Merriweather';
  font-style: normal;
  font-weight: 400;
  src: url('../fonts/merriweather-v30-latin-regular.woff2') format('woff2');
}

body {
  font-family: 'Merriweather', serif;
}

Problem: The privacy policy is incomplete. The right to data portability is not mentioned. Furthermore, the following information is missing or vague:

1. Details regarding duration of processing or the time of deletion of the data or, if this is not possible, the criteria for determining this duration.
2. The existence of automated decision-making, including profiling.
3. Details regarding the type of data that is being collected, especially the exact purposes for which the personal data is to be processed and the legal basis for the processing.

Explanation: Art. 13 GDPR (data collected directly from the subject) and Art. 14 GDPR (data obtained from other sources) together require the website owner to inform the user (among other things) about their data subject rights, the purpose, duration and legal basis of processing of all data that is collected by the website.

Fix: Add all missing information required by the GDPR (right to data portability, collection and duration details/deletion time, existence of automated decision-making, purposes and legal basis for processing).

Problem: The address form is leaky - form data that has been entered is sent via POST request to a third party as soon as the user stops typing, as can be seen in the network tab of the browser's developer tools.

Explanation: It is a common problem that forms send their data without any consent to third parties before the user has clicked the submit button. If a visitor enters multiple email addresses before submitting, all these addresses are stored by third parties. This violates the principle of required consent for processing according to Art. 6 par. 1 lit. a GDPR and the principle of data minimization according to Art. 5 par. 1 lit. c GDPR, which requires that only data that is adequate, relevant and limited to what is necessary for the purpose is collected. Sending interim keystrokes to a third party goes far beyond what is necessary. Sending a form's content to a third party before submitting requires consent from the user.

Fix: One solution is to request consent via the Consent Management Platform and otherwise do not send any data before submitting. A much more privacy-friendly approach would be to not using Leaky Forms and sending form data only after the user has submitted.

Problem: The shop forces the user to agree with the privacy policy for an order.

Explanation: A website's privacy policy is purely informational and does not require confirmation or consent. Asking for general consent or agreement to the privacy policy violates the principle of lawfulness, fairness and transparency under Art. 5 par. 1 lit. a GDPR, because it creates a false impression of valid consent where none exists (further reading here).

Fix: The checkout page's checkbox must be removed because it does and cannot have any effect. If there is something in the privacy policy that needs the user's consent, it has to be moved to the Consent Management Platform.

Problem: The account page does not provide any help to make use of the right of access according to Art. 15 GDPR.

Explanation: Good design practice is to make the usage of the right of access by the data subject according to Art. 15 GDPR easily available. This could be a simple download button on the account page that exports all stored user data. Companies like Google and Facebook do provide such features.

Fix: Adding a "Download a copy of my data" button that provides a copy of the user's entire data would make exercising the right much more accessible.

Problem: The review page and public user page show a users' name and mail address even after account deletion.

Explanation: A website has to delete all user data if the user makes use of the Right to erasure according to Art. 17 par. 1 lit. b GDPR.

Fix: At least the author and his email address must be deleted, anonymizing the author at first sight. However, the review itself could contain personal data and could make the author identifiable again. The most secure way would be to delete all reviews of the deleted user and disable the public author page.

Problem: If a user consents to tracking, almost every user click is send via POST request to audeinces.com. and tracked with a unique id - which is stored in the user's browser - by a third-party provider.

Explanation: This is a best-practice issue rather than a strict GDPR violation provided that the user has given valid (informed) consent. However, even with consent, the principle of data minimization under Art. 5 par. 1 lit. c GDPR requires that only data adequate, relevant and limited to what is necessary for the purpose is collected. Tracking nearly every user interaction with a persistent unique identifier goes significantly beyond what is necessary for most analytics purposes. Good design practice is therefore to track the visitor as little as possible and, if tracking is done at all, as anonymously as possible.

Fix: Tracking the user's action without a cookie would improve the privacy of the shop users against the third party. Removing the entire extensive user tracking would be the most privacy-friendly step.