How can a website contact back their users if they use solid and don't host any user data?

Hello forum, we are studying Solid to implement in our project vectoria.org. The point we are stuck at is website data. If solid hosts all the user information in a pod it means that websites do not host any user data so I wonder how can we do different actions, most basic is sending an email to our user since we don’t have access to it unless the user comes to our website.
If the first time user visits a website we can check and know their email and we can copy it, but if we do, isn’t it the same as hosting it directly at websites? at the end, if you want to avoid websites to host user information, how can we contact back users, mine user data to infer desires, study behabiour etc?
Solid seems very promision however we don’t understand how can this duplicity of data be avoided, if we want to connect with our users at a later time or similar.
Many thanks for your clarifications. Regards. Julio

“…how can we …mine user data to infer desires, study behavior etc?”

Its simple: use fear.

If users fear that they will be excluded from your community and as a consequence they will not be able to get something that they perceive they need, whether that perception is accurate or not, then you can coerce them into giving up their data.

If you have a monopoly on something like electricity or water or internet service or government services or health care then all the better, you can easily create that fear. In the long run, only those able to create such fears will have all the data and be able to compete.

A, Your website says “I want to know XYZ about you, may I?” If I agree that you may, I say yes, here’s the link to the place on my pod where I store that data. You store that link on your website but you do not store my data. On my pod I give your company permission to see the data. When your company needs the data, it looks up the link and retrieves the data.

B. Your website says "I want to track your online behavior so I can let non-transparent algorithms infer your desires and study your behavior. " I say “Note to self - don’t come back to this website”.

2 Likes

Thanks @tag42git tag42git for your answer. The point here is, given that a project is able to “seduce” any user to provide their data, the project will need to store it, and therefore both user and service are storing data. Might not bbe PII but it is data. So I see a duplicity here. Therefore users will have to host their data but services will have to either, since they want to create a relation, fear, you name it…

thanks @jeffz for your answer.
A- So you can keep ueer pulling from you, but you can’t push to them if you don’t store, lets say, their email. If you do, then user getting pods for storing their data privately looses meaning, to my point of view, since websites need to do it anyway.
B- That is exactly my point: if you want to source information from data, you need to mine it at some extent. If the user hosts it, then websites can’t and therefore websites can not personalize services. Think about transactions, let’s imagine you have a music download business, you as service provider have to track downloads to pay royalties, so you have to host that info, so from the business point of view, it is a duplicity rather than a time and resources saving. I understand there are business that could do the job without hosting user data, but at the cost of scalability. From user perspective, and given this situation, I see no gains on hosting my own activity data (I let apart Personal information PII, which use case is easier to see for me but you don’t need a pod, but a wallet.

The users could store their email address on their Pod, and give you access to that. That way, you can read it out every time you want to send an email, while still having the user be in control. Theoretically, at least; in practice, interoperable and understandable access controls in Solid are still challenging.

That said, I think there’s also something to be said for being pragmatic, especially when there isn’t yet widespread production use of Solid with proven patterns. So you could also just focus on minimisation of data collection: holding less data is not as good as holding no data, but better than gathering lots of it. In other words: you could decide to store email addresses only, while keeping other data on the user’s Pod.

2 Likes

Many thanks @Vincent for your answer. Have two issues with your answer. (1) Can a business access users email if users is not connecting and sending it? I think you can’t. If services can only access when user visits them, then it is almost useless in terms of engagement to have access to contact data. (2) If you are to store just “some” data and let user store the “lots” then (a) user is not going to be very happy about hosting so much data and (b) if websites store emails then they have to comply with GDPR and be accountable for hosting it, what makes, to me, Pods to loose most of their meaning, again, in favour of wallets. Of course I’m trying to understand how Solid could be implemented in our business case but I’m finding it very hard to understand where it does make sense. I understand the use for PII, Authentication, Authorisation and UGC. However for activity data mining (basic for info extraction and value creation) and transactions I can’t see the point, if feasible. UGC sits in the middle but for PII and Auth a wallet does the job. From the business point of view, it would be great for a business if it doesn’t have to host and be responsible for user data, specially SMEs, but as soon as you need a simple contact email, then GDPR applies. Hard to me to understand how to avoid data and accountability duplicity.

Yes, you can :slight_smile: For example, I created an example resource here, which lists a fake email in my Pod, and which you can read without my being present: https://pod.inrupt.com/vincent/tmp/test#email

(Of course, I set up that one to be publicly accessible. In the scenario described, a user representing your application would need to be authenticated and be granted access.)

let user store the “lots” then (a) user is not going to be very happy about hosting so much data

I mean, that’s pretty much the point of using Solid? :stuck_out_tongue:

if websites store emails then they have to comply with GDPR and be accountable for hosting it

Yes, if that’s what you’re trying to avoid, then you should indeed prefer storing the email on the user’s Pod.

The short answer here is: this is not something that Solid concerns itself with. If you want to contact people who use your applications, then you’ll need to setup a mailing list or have some other means for them to provide that data to you, and yes, you would need to comply with GDPR. That is a responsibility you have when collecting personally identifiable information.

On Solid’s part, one of the nice things about writing Solid apps, is that you don’t have to store PII, and therefore don’t generally have to consider GDPR. However, other privacy directives such as ePD or Cookie Law may apply.

Whilst we’ve not written about it in the context of the Inrupt SDK, @inrupt/solid-client-authn-browser does indeed use LocalStorage for storing data required in order to handle the authentication process. This would mean you’d need to list that in your Cookies disclosure, much the same as how you have to for AWS Cognito or Amplify.

Thanks @ThisIsMissEm for the clarification. Not being an expert in Solid, my opinion is that if, in one side, Solid promotes user hosting all data and, on the other side, business feel they have to host some user data to better know their clients, then it is going to be confusing to understand and might eventually create data duplicity. Thanks you all for your support.

@Vectoria.org right, at the end of the day, if you want to track your users or contact them for support, then you’re going to have to do that in a way that complies with existing privacy laws — Solid does not change that. Solid simply says “give your users more control over their data by storing it in their pod”