united-states gdpr software european-union email
GDPR Compliance for Application That Guesses Email Addresses
<p>I live in the U.S. and am developing a browser extension that grabs a person's first name, last name, and company name from their LinkedIn profile and then attempts to guess their email address based on popular email syntax.</p>
<p>The extension <strong>does not send</strong> any emails, but does validate the email addresses it guesses to confirm accuracy.</p>
<p>A couple of questions, based on the above info:<br></p>
<ol>
<li>Is my application/extension considered a <strong>data processor</strong> or <strong>data controller</strong> based on GDPR?</li>
<li>Since I am only providing the user with an email address for the LinkedIn member, am I legally liable for what the user does with that email address (i.e. sending unsolicited messages)?</li>
<li>What information should I store, or not store, for GDPR compliance and my own legal protection? (i.e. should I retain logs of when a user looked up a particular name, and what email was produced? Or should I immediately purge all info?)</li>
</ol>

<p>I decided to rewrite this after the clarification in the comments. You can find the old version in the history.</p>
<p>The question is not, actually, about a browser extension. It is about a web service that can be accessed by the browser extension. The way to access the service should make little difference, it could be clay tablets, homing pigeons, or this browser extension, what matters is the service.</p>
<p>The service has two functions:</p>
<ol>
<li>Receive PII of the <em>victim</em>, sent by the <em>customer</em>, to calculate the probable email of the <em>victim</em>, and return this PII to the <em>customer</em>.<br />
The <em>service operator</em> could argue that the <em>customer</em> is really the data controller under GDPR rules, and that the <em>service operator</em> is only the data processor, but that is not a plausible use case. The <em>customer</em> would need to get and document the consent of the <em>victim</em> before the probable mail is calculated, so why would the <em>customer</em> pay the <em>service operator</em> for a service like this? There is already contact with the <em>victim</em>.</li>
<li>Generate a database of specific company email patterns to enable 1.<br />
This would also use PII, from random employees of the company in question, and there is no <em>customer</em> to shield the <em>service provider</em> by pretending that consent was collected.</li>
</ol>
<p>The way around the first issue might be to sell the database and have all calculations on the <em>customer's</em> system, but that doesn't resolve the second issue, that of creating the database. This involves looking for patterns in PII of individuals, unless the target company is obliging enough to make the pattern public.</p>
