Privacy

The short version

I am the controller for all of it: Majed Monem, one person, reachable at me@majedesigns.dev.

The rest of this page is where each of those lines comes from, how long it stays, and what you can ask me to do about it.

1. Who controls this data

Behind this shop is one person: Majed Monem. I am the data controller for everything on this page - I decide what is collected and why - and I am who you contact about it, at me@majedesigns.dev.

A postal address is not published on this page; email reaches me, and I will give you one in writing if you ask.

2. What is collected, and why

• Your email address. The payment provider hands it to this shop on a paid order, and it is what you type in to request a sign-in code. It is how your library is found again and how a receipt or a commission reply reaches you.
• Order and entitlement records. Which items you own, which order paid for them, when access was granted, whether it has since been revoked by a refund and how many times each item has been downloaded. This is the record your library page shows back to you, and it is what the refund rule on the refunds page checks.
• Cart contents. A cart is a set of item ids, addressed by a hash of the selection itself rather than by you, so reloading the review page finds the same row instead of writing a new one. It is linked to your email only once it is paid for.
• A session token. A signed-in visit is one cookie holding a random token; only a one-way hash of it is ever stored, so a copy of the database is not a copy of anyone's working sign-in. It stops working by itself after thirty days, or eight hours on the separate sign-in used to run the shop.
• Sign-in codes. Requesting one stores the address it was sent to, a one-way hash of the six-digit code, and the IP address that asked - kept so the same limits that stop a code being guessed also stop the endpoint being used to spam a stranger's inbox. A code expires in ten minutes and works once.
• A commission brief, if you send one. Your email, the brief text, the shelf and the size band you picked, the budget you typed if you gave one, any catalogue items you chose as references, the search term if you arrived from a search that found nothing, and the IP address that submitted it - the last two for the same anti-abuse reason as a sign-in code. A brief is never shown on any page anyone else can read.
• Counts of what happened on the site. The picker, the commission form, the checkout and the library write a small, fixed set of event names - an item viewed, an item added to a selection, a commission brief started, a checkout started, an order paid or refunded, a brief sent, a quote sent or accepted - so a dead shop can be told apart from one with a broken checkout. Only three of those can be sent by a browser at all: item viewed, added to selection and brief started. The rest are written by the server itself, from a checkout, a payment or a brief that has already happened on its side, so nothing sent from a browser can forge one of those into the count. The events a browser can send carry no visitor identifier of any kind - no cookie, no stored id, nothing that would let one request be joined to the next. Where a rate limit needs to group requests from the same connection for a few minutes, it uses a hash of the address salted and mixed with the date, which changes every day and cannot be turned back into an address.

One more table exists purely to let the person running the shop sign in to answer commissions. It holds no visitor's or buyer's data - only mine.

3. What is deliberately not collected

Every pack page and item page - the great majority of this site - ships with no script at all. That is a design choice, not an oversight: it is what keeps those pages fast and crawlable, and it means there is no analytics beacon, no advertising pixel and no third-party tag anywhere on them to disclose. Even a cookieless one was ruled out when it turned out to inject a script onto those pages; traffic counts come from ordinary hosting logs instead, which is a property of running a website at all rather than something added to watch you.

The one exception is the bot check on the commission form, which loads one script and sets no cookie of its own - see the next section.

One honest qualification. Everything above is about what this shop sets. The infrastructure that serves every page - described in the next section - may set its own short-lived cookies at the network layer to tell a browser from a bot and to keep a connection working. They come from the network rather than from anything on the page, they are strictly necessary to deliver the site at all, and they are not used to profile you or to follow you anywhere else. They exist whatever this policy says, so leaving them out would have been the easier sentence and the false one.

4. Who this is shared with

• The provider that hosts this shop. Serves the storefront and its API on one origin, holds the database this page describes, holds the private file store your purchases stream from (never public, never reachable by a direct link) and runs the bot check on the commission form. It sees whatever ordinarily reaches its network in the course of serving the site.
• The payment provider. The merchant of record for every sale, named on the terms of sale: it takes your payment details directly at checkout, and this shop never asks for or stores a card number. What comes back here is an order id, whether it was paid or refunded, and the email address your library is attached to - nothing else in its own records is read or kept here.
• The provider that sends the shop's mail. A sign-in code, a receipt, a commission notification, sent from send.majedesigns.dev, a subdomain kept apart from any human mailbox on purpose. It sees the address a message is sent to and the message itself, and nothing more.

Nobody else. No analytics vendor, no advertising network, no data broker - there is no fourth party to add here.

5. The lawful basis for each

• Contract. Your email address, your order and entitlement records, and your cart once it is paid for are processed to sell you what you selected and to let you come back for it. There is no purchase without them.
• Legitimate interests. A session token, a sign-in code and the IP address kept beside it, the commission form's bot check and the event counts all exist to keep the shop working and to stop the sign-in and commission paths being abused, without profiling anyone who is not trying to abuse them. That interest has been weighed against your privacy and judged reasonable at the scale this shop runs at, and none of it is used for anything beyond that purpose.
• Legal obligation. Whatever a sale requires this shop to keep for tax and accounting reasons is retained on that basis, to the extent the payment provider's own position as merchant of record does not already carry it.

6. How long this is kept

• Order and entitlement records are kept for as long as the account exists, and normally longer: an entitlement is what proves you own something, so it survives a request to close the account, in the one narrow way section 7 explains.
• A session expires by itself: thirty days for a signed-in visit, eight hours for the separate sign-in that runs the shop. An expired token cannot be used again, whatever has or has not been cleared out of the database behind it.
• A sign-in code works once and stops working after ten minutes even if it is never used. The record of the attempt is kept afterwards for the rate limit described in section 2; there is no schedule that clears it out sooner, but a spent or expired code cannot be turned into a working sign-in by anyone who finds the row.
• A commission brief is kept for as long as it is a live conversation - unquoted, quoted or accepted - and afterwards as the record of that engagement, the same way an ordinary order is kept.
• Event counts carry no name or address to begin with, so there is no clock running on them: they are kept as aggregate counts, and the salted, dated hash a rate limit sometimes needs cannot be turned back into anything to delete individually.

7. Your rights

Under the UK GDPR you can ask me, at me@majedesigns.dev, to:

• See what is held about you.
• Correct it, if anything is wrong.
• Erase it, with one honest limit set out below.
• Restrict or object to a particular use of it.
• Receive a copy of what you have given me, in a portable form.

The limit on erasure. If you still hold a live entitlement, deleting your email address and that record deletes your own ability to sign in and re-download what you paid for. Where that applies, erasure means removing everything else this page describes - your cart history, sign-in codes, any commission brief not tied to a delivered order - and keeping only what your library needs to work. Closing the account outright, entitlements included, means giving up what you bought, and I will ask you to confirm that in writing first.

If you think I have got this wrong, you can complain to the Information Commissioner's Office, the UK's supervisory authority for data protection, at ico.org.uk. I would rather you told me first, but it is your right either way.

8. International transfers

Every provider in section 4 operates infrastructure outside the UK, so your data is processed outside the UK as a normal part of using this shop, not as an exception buried in the small print. Each of them is a large processor with its own published safeguards for that transfer; this shop runs no servers of its own anywhere and has no transfer arrangement beyond theirs.

9. Changes to this policy

This page can change as the shop does. The version published on the day you use the site is the one that applies to you, and there is no separate archive of older versions to consult.