Aqivex

That is illegal under GDPR, if true

This statement is unfortunately doing a lot of work with the word “that”, even if I dearly wish it wasn’t so. Like, I really wish it were that easy, it would even the playing field back to the non-corporate webmaster almost instantly.

But alas.

The GDPR doesn’t have some special category where data only becomes data once you hit Submit. Article 4 literally defines “processing” to include collection, recording, and storage. So yes, depending on what the site is actually doing, it can absolutely be processing what you type before you submit anything:

https://eur-lex.europa.eu/eli/reg/2016/679/art_4/oj/eng

But that does not get you from “they captured it” to “therefore illegal.” GDPR doesn’t prohibit processing personal data; it regulates how and why you can do it. Article 6 gives six possible lawful bases for processing, including consent, contractual necessity, and legitimate interests (and it is bastardizing the spirit of how these six interconnect that these companies use to skirt intent of the law):

https://eur-lex.europa.eu/eli/reg/2016/679/art_6/oj/eng

The actually interesting question is what they’re capturing, why, how long they retain it, what they do with it, whether they disclosed that processing, and what lawful basis they’re claiming.

That’s where you can potentially have a GDPR problem.

Article 5 requires, among other things, fairness/transparency, purpose limitation, data minimization, limited retention, and appropriate security:

https://eur-lex.europa.eu/eli/reg/2016/679/art_5/oj/eng

And Article 13 requires the relevant information to be provided when the personal data is obtained. There isn’t a magical “well technically the user never clicked Submit” exemption from transparency:

https://eur-lex.europa.eu/eli/reg/2016/679/art_13/oj/eng

There’s also a separate ePrivacy issue if we’re talking about storing or accessing information on the user’s device. Article 5(3) generally requires consent unless the storage/access is strictly necessary to provide a service the user explicitly requested:

https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX%3A62017CJ0673

And this is where the details get important again, because regulators have explicitly recognized things like short-lived, first-party “user-input” session cookies for multi-page forms as potentially falling within that necessary-function exemption. See WP29 Opinion 04/2012:

https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf

That is a very different animal from silently retaining abandoned form contents indefinitely, sending them somewhere unexpected, profiling somebody with them, or reusing them for advertising.

So if somebody actually wants to know whether their abandoned input was retained and what happened to it, GDPR gives them tools for finding out instead of having to speculate from browser behavior. Make an access request to the controller and ask what personal data they hold, the purposes/legal basis, recipients, retention period, and the source/context of the collection.

They normally have one month to respond under Article 12:

https://eur-lex.europa.eu/eli/reg/2016/679/art_12/oj/eng

If they don’t respond, or the answer establishes something questionable, then you have something concrete to take to the relevant supervisory authority under Article 77:

https://eur-lex.europa.eu/eli/reg/2016/679/art_77/oj/eng

The EDPB has the list of national authorities here:

https://www.edpb.europa.eu/contact_en

GDPR is leverage, not a magical force field that prevents a server from receiving bytes. The useful part is that it gives you a mechanism to make the controller explain what those bytes became, why they kept them, and what they did with them—and a regulator to complain to if the answers suck.

Nothing can. Not for any website. It never has.

Even if the site’s platform wasn’t set up with a simple and trivial to implement function(s) to undo posted changes on the front/back end interfaces, and even if it does allow the delete button to actually delete the entry from the database (to my knowledge, this wasn’t even the norm before the corpo takeover of the web)…

It’s like, 2-3 simple SQL queries to pull a backup pre-the changes, and merge back in whatever form you want into the live database.

This was always possible, since the day we started using DBs to better serve dynamic content.

Again, this applies to pretty much any web property.

It’s stupidly common and easy. Practically any text field can be made to capture and cache “unsent” data, because it’s not actually a standard text field that only does POST when you submit, but rather something that is continuously polled (usually AJAX) and the data saved to whatever database tables they got set up for it.

Wonders of scripting.

NoScript will stop it, but then the platforms that rely on this bullshittery for ill, usually are the kind to try to force you into having JavaScript or worse enabled.

Some examples of this I’ve seen/used in the wild:

When I worked at a credit union, the last upgrade to the “online banking” towards Lumin(link to their marketing site in case you want to see their screenshots, almost no CU/Bank who uses them bothers to customize it) the then “hot and new” vendor platform that was hot then amongst digital banking solutions for small to midsize institutions, uses it on every text field.

E.g. the search omnibar input from atop the accounts where you can search help topics, and the input from the fields around the FAQ sections (input meaning both sent queries and anything typed but not submitted) were all visible to the call center folks, with strings like “user typed ‘how do I hide my 10k deposit through mobile banking’ into [field name] but did not submit”, as these were expected to be data for the reps to use in their servicing or whatever.

Another (much bigger) example: The omni bar at Google.com specifically (and I have no idea how many in their Android apps, but given that they have more control there than over your browser I’d just assume every single one…Google Keyboard included).

If you get yourself through all the trouble and effort to somehow arrive at search site unknown (your customized FF privacy fork is really fucking good or something) and for some reason need or allow scripting on their page and type ad targetty helpful info but never search…it’s still gonna make it into whatever shadow profile they’re prepping for linkage to the real you ASAP, and eagerly wants to personalize those ads with your unsent data.

My own community writing website:

It came bundled with a Xenforo add-on I used for some stupid feature I wasn’t smart enough to do myself 5-7 years ago. I don’t run any sort of ads or tracking whatsoever on my site, so it’s pretty much useless.

Ocean is too tired to hold in extra Co2, and far too blue and not white anymore where it matters either.