Peer information requirement
kjetilk opened this issue · comments
I'm in a meeting where people are talking about information needs, and it made me think about how a peer can report their information requirements, so that you can update your ACLs accordingly.
The peer in question may be a business, when you're a consumer in a B2C relationship, or a governmental agency when you as citizen is reporting e.g. tax data.
For example, when I'm flying to the US, I need a airline ticket and I need an ESTA. The airline requires my name, contact details, passport number, etc. The US government also wants a lot of data. These data should be in my POD, and if they are not, the peer should ask me not to enter it in their systems, but into my POD, and then to change my ACL to allow them to access it.
We should have a standard for asking for permissions to access to my data.
Thanks @csarven , Yeah, I think LDN would be a good mechanism to propagate such a request, and possibly as:Question could be the superclass, but it seems we need a much more detailed vocab to automate or provide good UX around this?
Actually, I believe this is a rather important feature, because it could set off network effects, i.e. peers asking people to enter data could promote the richness of PODs, and therefore their adoption.
Yea, use cases around the general idea of a request of some sort was discussed/considered eg. "can I have read-write access to resource x?" The vocabulary/modal in the payload would naturally follow the use case. As you said, as:Question is broad (although it can be further detailed within the payload).. it was just an example.
If you want to set constraints, announce ldp:constrainedBy with a machine-readable description for what the sender should do eg. coupled with SHACL/ShEx or whatever on the server.
After processing/verifying the payload, if the server is expected to automatically act eg. grant read-write permission to any of my contacts wanting to play with resource x, or send me an email for certain kinds of requests, then this gets into the territory of server doing something beyond the basic read-write operations. So, that's similar to the idea that ActivityPub server-server interactions take.
Yeah, I think LDN would be a good mechanism to propagate such a request
But, how do you prevent inboxes filling up?
Also you can easily spoof a request from someone other that you. Security issue?
Having worked with inboxes for a looooong time, I dont know of any solution to the inbox spam problem. But one thing I've found that helps is to have a sub folder for a certain type of common request. This leaves other inboxes relatively free.
If a profile advertises its inbox publicly - which is the current default - it is subject to filling up. However that's prevented from filling up or managed, it'd be similar. Point being that, the concern is not unique to this particular use case (about requesting permissions)... that I can think of.
re spam problem, sure, that's definitely a concern, and it is not unique to inboxes either. It is a system-wide concern where any container that has append or write privileges given to public. Resolving that, will resolve the inbox issue. Having some constraints on the container can help to filter, but not ultimately reliable by themselves. Proof of sender would be another.
However the inboxes are organised.. ultimately the discovery starts by the target of the inbox. If the requests are always directed at a particular target (eg. a person) then it'd be their inbox - and whatever happens behind the scenes on the processing/organising further is perhaps implementation specific. It would also be reasonable to send notifications to the system/storage/service's inbox - which is different than the person for general purpose communication. Here we can start treating any resource (document, person, software agent..) to potentially have an inbox. So, I think that might work out well to keep the system's inbox separate from person's. After all, the Webspace is not necessarily restricted to one individual - although we usually refer to it as the "pod", it could be shared.
[Just putting this on the table so that this bit is at least acknowledged at some point]
Another reason why it might be a preferable to send those kinds of requests ("can i haz permission?") to service's generic/catchall inbox as opposed to any particular person's is for privacy reasons. Just as the system currently doesn't disclose who has what permissions on a resource, it may be better off to not signal that at all. Of course it can be equally argued that it can be handy for the requester to know that so that perhaps they contact by other means.
If there are other use cases where notifying the service's inbox makes sense, might as well approach that up front. Surely not all pods would want to disclose individuals' WebIDs associate with it.
We need an inbox processing agent.
I think that's a good starting point.
I think one inbox is best; senders should not need to know how to sort.
This is really a huge management issue. Have you ever tried, or spoken to a sysadmin that's tried to run a serious email service. There's a whole host of issues, that can destroy a user experience. Mail bombs for example. Spam assassin and tools like this are whole projects in themselves. Consider how much harder this can be with HTTP.
This is one reason email is so centralized. There's a large overhead to running an email server, or, at least there used to be. We need robust solutions here, until that point, I have found it helpful to compartmentalize on a per use case basis, so that one inbox folder does not take out all the others.
Have you ever tried, or spoken to a sysadmin that's tried to run a serious email service.
I have been running an email service since 2002 for my family and a few others. Whether that is serious is a matter of opinion of course. The first few years of that, it was an arms race, but SpamAssassin got pretty much on top of it, and broke the problem's back in 2008-ish, I think. At the max, I had about 400 spams impinging on my system a day, without it causing me much grief. And that's even without FOAF based whitelisting ;-)
Consider how much harder this can be with HTTP.
Yeah, so SMTP is a much more forgiving protocol in some senses, like you have a 72 hour period where the sender MTA is required to retry. But you also have to consider all the advantages, like we're probably going to have a trust network that can help us filter stuff, and a lot of structured data.
I don't think of an inbox as something the end user will monitor, as @RubenVerborgh said. There has to be automation there that does most of the work.
So, yeah, there are problems, but I don't think they are more severe than problems that have already been resolved.
I have a random thought on the spam problem. Correct me wherever I am wrong.
The origin of the spam problem is the low cost for the sender. The difficulties faced by the recipients is just a collateral damage.If we make it costlier for the sender, this might reduce spamming to an extent, except for a very rich spammer.
What if every message sent is kept in the outbox of the sender, until the recipient acknowledges. So if a spammer or a legitimate sender makes 100 copies of a message and sends it to 100 different recipients, he will have to keep 100 different messages in his outbox. The cost is 100 times compared to the existing systems.
What if every message sent is kept in the outbox of the sender, until the recipient acknowledges. So if a spammer or a legitimate sender makes 100 copies of a message and sends it to 100 different recipients, he will have to keep 100 different messages in his outbox. The cost is 100 times compared to the existing systems.
Mmmm, yeah, that's an interesting idae, @febinkk ! I'm not sure how we would do it in practice, but it is worth entertaining.
@febinkk What you're proposing is similar to ActivityPub's informative verification: https://www.w3.org/TR/activitypub/#security-verification ie. receiving server goes to check that the primary object of an activity is accessible from sending server's outbox. Either way, this is not spam prevention but one way to potentially mitigate maybe for some kinds of notifiers. One issue to count on something like also means that the verifying server has to leave a fingerprint - like clicking on a link that a spammer sent.
This is now addressed by https://github.com/solid/authorization-and-access-control-panel in solid/authorization-panel#26 and solid/authorization-panel#27