Drop suggestion of using "From" header
aaronpk opened this issue · comments
Section 4.1 says:
In the context of social web applications, it is considered good practice to include a From HTTP [RFC7231] header (as described in section 5.5.1 of Hypertext Transfer Protocol [RFC7231]) to indicate on behalf of which user the subscription is being performed.
From what I can tell, there is no actual benefit to including the header, especially since there is no guidelines on the verifiability/security of the value. On top of that, the From header must be an email address, and there are very few situations in which sharing a user's email address like this is acceptable.
My proposal is to drop this quoted sentence entirely. It will have no effect on the interoperability of existing implementations.
Agreed. If the idea is to keep track of which user a subscription is for, there are better ways.
This probably originates from the thoughts described in eg. https://www.slideshare.net/mobile/Blaine/social-privacy-for-http-over-webfinger which at the time of PuSH 0.4 was considered to be the way to handle social privacy, but which lost its momentum when WebFinger lost its because of the resulting inability to do any lookups of the included e-mail and thus to actually have a functioning mechanism.
Same mechanism without WebFinger would need to use some other header, but perhaps it could still be useful to somewhat hint somewhere about the possibility of social privacy over PuSH without mentioning any specific tech for that?
I am ok with dropping this from the spec. Yet I think this is an interesting mechanism that may have its room in a "best practices" section?
Great. I made a PR for this change. I'm pretty sure sending users' email addresses around would not be considered a "best practice", so I'd rather not even make that suggestion.
@aaronpk Just want to point out for future reference:
It's never been about sending e-mail addresses around – it's been about sending identities around – saying that accountname@example.com (eg. voxpelli@twitter.com) wants to subscribe to your updates. In an IndieWeb-context you would instead want to send the domain name of the person, as that's what represents the identity there, so instead sending eg.http://kodfabrik.se/, but since that's not a valid value according to the specification of the From:-header something other than the From:-header would hen need to be used in that post-WebFinger landscape.
So – it has never been about sending around users private e-mail addresses – it has always been about providing identities that enables social privacy.
Sure, but sending account@example.com for anything other than silos that don't actually route that email is likely going to actually be an email address. (Don't forget that for a while, Facebook actually routed email from username@facebook.com to your facebook messages) And like you mentioned, the From header doesn't support non-email-like identities such as plain URLs.
I don't disagree that the concept of this mechanism would be useful, having some indication of the user ID that is subscribing. It's just that this particular mechanism has no place on the modern web.
Perhaps more importantly, have any existing 0.4 hubs actually done anything with this header value? Do any subscribers actually send it?