Login by Twitter needs too many permissions. It is invasive

I opened a new account. I thought I’d link my Twitter account but look at the permissions I need to give. We should eat our own dogfood and limit the control others have of our data.

See Tweets from your timeline (including protected Tweets) as well as your Lists and collections.
See your Twitter profile information and account settings.
See accounts you follow, mute, and block.
Follow and unfollow accounts for you.
Update your profile and account settings.
Post and delete Tweets for you, and engage with Tweets posted by others (Like, un-Like, or reply to a Tweet, Retweet, etc.) for you.
Create, manage, and delete Lists and collections for you.
Mute, block, and report accounts for you.
1 Like

Logging in with other accounts is fundamentally flawed. It’s insecure, dangerous to privacy, especially because Solid is being marketed using a service model with single providers housing large numbers of accounts.

This replicates many of the problems Solid was suppressed to solve.

It makes no sense to me.

1 Like

Let’s build a “Sign in With Solid” auth option so you can share (and revoke) access directly from your POD.

1 Like

This would be fine if it’s invisible to the service provider, but I don’t see that is likely and the user can’t control it.

It’s exactly the kind of data providers are great for. They may start without it, but once they have millions using it, switch the terms and were in exactly the same scenario as with other services. Or data hovered up, exploited, sold, used for targeting, surveillance etc.

Some will say, well people can move if they don’t like it, but the reality is that very few will in practice. Solid may make moving easier, but providers know well how to optimise surveillance creep to minimise this.

Not sure I’m following. You mean whoever builds the sign in with Solid features will have the ability to see data, thus defeat the point? Is it possible to have logs about what pod or app has “queried” your data?

I don’t think using data for targeting, and improving the user experience is a negative thing. At the end of the day, as long as that individual is in control over the data and can disable the connection, we are in a better spot than we are today. I don’t want to stifle the innovation that data makes possible, I just want it to be stored with the individual.

Thoughts?

Even if not data, metadata is valuable and should not be in the hands of third parties, so any leakage of that is a problem. If you allow a login for one system to be used for another you gain convenience but are leaking information about yourself. The more systems you expose in this way, the greater the value and risk. Few realise this and frankly we can never know the full implications in advance.

If you don’t mind how such data is used, then we have different views and approaches to privacy. I’m going by how I know this kind of data is currently being used, sold on and abused. I believe this is harmful on many levels and I don’t think many people are aware of the extent of this, or the harm it creates.

So that’s bad, but if you are using a third party to host your data then that leakage is much, much worse. I’m not familiar with the design of Inrupt’s just launched product, and I’m not aware if they’ve made the code public. But the model is the problem, you are necessarily trusting corporations whose imperative is profit, to put your privacy before their profit. What we see is that they will do what they can get away with. There are numerous problems with this model in my view.

Inrupt and those designing the service based approach have not responded to these points so it’s not clear why they’re ok with the approach, whether they believe their solution is not vulnerable to the issues and why, or if they don’t regard them as problems and why that might be. For me, the Solid protocol is a great idea and well suited to addressing these issues, if implemented in ways that address these problems rather than replicate much of what has created the problems we now have.