Add allow_read_email oauth permission #1431
Conversation
|
My main concern here is that I suspect our UI around permissions is not good enough - for example I don't think we allow users to control what permissions they grant do we? They have to either accept or reject whatever the application asks for? Certainly before we can allow this we need to be absolutely sure that the users are entirely clear that they are consenting to reveal this. What's the use case for this anyway? It strikes me that this is really of interest when using OAuth as an authentication mechanism, which we have always considered out of scope - our OAuth implementation was intended to allow users access to OSM rather than to allow other sites to authenticate against our user database. |
|
This would need a legal review for data protection compliance and our privacy policy. This also seems geared towards authentication, not authorization. |
|
Okay, I will send this to LWG.
No, we are better than that. Try Level0 for example: when logging in, you have a choice to uncheck "read user prefs". After that your name won't be displayed in the header, but the editor would still be operational. Also the permissions list is pretty prominent with few words, so users I assume are reading it. I definitely do, every time. Our API provides some information about users, including an avatar, number of edits and messages and some more. Other sites can (and do) already authenticate against our database, and this change would provide them with a verified e-mail address, so they don't have to implement such verification. Again, if facebook, google, wikipedia, github, twitter and many others do that, I don't see a reason why we should not. Especially when users know what they are subscribing to. |
It might make sense to do the review for if this is a desired feature before seeing what the legal issues are. |
|
I desire it: I'd love to have a way to contact users. If application developers won't get an API endpoint to send messages through the OSM website, then getting the user email (with permission) is the next best thing. |
|
Yes you'd love to contact them and I'm sure you'd be nice about it @iandees but we'll cop the flack when a spammer makes use of that! |
|
So then open an API to send messages and rate limit it? |
|
I don't believe anybody has ever offered such an API so I have no reason to believe it would be refused if somebody were to write the code. I would have concerns though I have to say, as it makes the job of a spammer vastly easier and given that we have already had a number of instances of people managing to use the web site forms to spam one can only assume there would be more with an API that made life easy. The rate limit is already aggressive enough that it annoys genuine users while apparently not really constraining spammers that much so I'm not sure there is a good value it can be set at that really helps. Possibly the answer would be an even stricter rate limit along with some way to grant privileged users bulk messaging rights, along with a way for recipients to opt out of bulk messages. |
app/controllers/user_controller.rb
Outdated
| @@ -381,7 +381,8 @@ def api_read | |||
|
|
|||
| def api_details | |||
| @this_user = @user | |||
| render :action => :api_read, :content_type => "text/xml" | |||
| allow_read_email = !current_token.nil? && current_token.read_attribute(:allow_read_email) | |||
There was a problem hiding this comment.
Isn't that equivalent to the (simpier) form current_token && current_token.read_attribute(:allow_read_email)?
| @@ -0,0 +1,11 @@ | |||
| class AddReadEmailPermission < ActiveRecord::Migration | |||
| def up | |||
There was a problem hiding this comment.
If you make that def change then you won't need the down routine at all.
I think this is worth discussing further. However, I think that harvesting emails from OSM - even with the user's consent - is pretty dodgy. Many people just tick whatever boxes are in the UI without reading the content thoroughly. Or, as an alternative interpretation, that the UI needs to call out such "dangerous" permissions more strongly. My opinion is that we'd need to fix that UI issue before even considering allowing 3rd parties to request email addresses. And get LWG's blessing. Even then, it would make me extremely uncomfortable. |
|
Isn't allowing an app to modify the map more dangerous than sharing an e-mail? The list of permissions is usually quite small, so users tend to read it. The e-mail permission goes second, right after the master setting for getting all other data. Instead of making the permissions list more pretty by including warning signs and strong text, I'd put up a blog post highlighting the new permission, as we did with the notes a few years ago. I dropped the idea of universal privacy some time ago, because you have to give out your email address so often now, it makes to sense trying to patch all the holes. As a protective measure, we can introduce a "never share your e-mail with apps" setting in the profile, which will hide the check box in permissions. |
|
Well they're not comparable... The "danger" of allowing someone to edit the map is a danger to us, that they will deface it. The "danger" of releasing an email is a danger to the user, that somebody will something nefarious with it - that does in turn create a danger for us, of reputational damage at the last and potentially of having breached data protection regulations. |
|
Making a blog post would lessen that potential damage: complaining about leaked email after being warned and voluntarily clicking the approval checkbox won't seem like an issue on our side. |
|
Just noticed a website that could also use this feature: Rejecting a PR about emails to me seems not unlike banning a movie in a country because children might see it (happens in Russia). Let's treat users as adults and give them a choice. Is there anything blocking this PR except an LWG response? |
|
Well personally I'm not keen on the idea but if there was a consensus in favour and LWG are OK then I'd merge it subject to any technical queries that might arise on review. |
Is there this? |
|
Not obviously at the moment. |
I decided not to promote this PR in the mailing lists and among OSM developers because "Getting a couple of dozen hard core mappers to agree with you doesn't change anything." If you need a consensus (among whom?), I can do that. |
|
I think that "let's treat users as grown-ups" is not necessarily a good idea. Many of our users simply are not grown-ups. And even grown-ups fall prey to exploits all the time (how often have you read instructions like: "to install this software, perform the following steps, ignore all warnings, check the box that says 'i know that this makes my computer insecure', then when asked 'are you sure' click 'yes'...). Now an email address not the most sensitive bit of personal information but I think we've been entrusted with something here and we should not carelessly participate in schemes to relieve users of their personal information in the name of convenience. I have a technical question: Once we offer some kind of permission that users can grant - can all applications ask for that permission, or would it be possible to limit that permission to certain applications that we have somehow specially authorized? Would it perhaps be possible to implement the share-email feature, but only allow its use to such providers/applications that have convinced us that they are trustworthy? I'm sure that there will be some pre-existing "ethics code" for the handling of email addresses (don't sell them, don't spam, don't go big-data on your pool of email addresses to find out stuff about people) that we could request anyone to follow who wants us to enable this feature for them. |
|
I mean consensus among the developers/maintainers etc of the web site rather than among users. That's how decisions in open source projects are typically made... |
|
Thinking about it some more I think that basically I think there are three hurdles here, namely:
The last is not one that I think is up to the maintainers of the code as such - my personal view is that we probably shouldn't but I don't for a minute think that it's a decision for me to make. |
|
As @tomhughes has said we really need to get the policy aspects of this decided before legal and technical (both of these are doable). On the policy side I would want to note, as this has got a bit lost in the discussion, that providing an API to our messaging system is a clear alternative to handing out e-mail addresses (we could limit apps that have access to that, just as we would likely have to do with e-mail access). And one nice aspect of doing that is that it creates a level playing field between those app/service operators that know what a burden keeping personal information safe is and would rather not have to store the addresses themselves, and those that don't know that yet. I suspect that I don't need to quote all the recent and past issues even quite large organisations have had. |
Thats a very important point. This function should not be implemented on an "all or nothing" base. |
I still don't see why. A malicious app aimed at collecting emails can simply ask a user to enter their email address. As you've written, "grown-ups fall prey to exploits all the time", and there is no need to make an exploit such elaborate just to get an email address. People share their addresses on the web now right and left, and those who don't, by this time should have learnt to read things they agree to. To me, "all or nothing" is the only way to go. We don't vet software to edit the map or post notes. We have made a dump of all GPX traces in the past, which users ten years ago didn't think would be made. They could find very private traces in that dump, and no way to remove them from the public. Signing the wrong document can lead to worse outcomes than leaking an email address.
We are discussing existing open pull requests. Providing an API for messaging is obviously an alternative. Not doing anything is also a clear alternative. Can we do both? Because from my point of view, an API for messaging is much more hassle, with potential spamming and rate-limits and possible vetting and so on. It is much more complex issue than this one.
Is this about email addresses still? Because I have heard about only one service that does not store addresses for profiles, and I wrote it myself. I assume there is virtually none services that having access to a user's email addresses, do not store it in a profile. It is not a phone, not a physical address, not a facebook account. Email address is an absolute minimim required for using many services, and because of that it is hardly considered a secret to protect at all costs, including the cost of worsening the user experience. |
|
@Zverik From @mikelmaron diary entry on the Local Chapter Congress notes he said this PR needs support for the ability to do push notifications. From reading here it seems like the PR is kind of on hold. I'd like to know what you think it will take to move forward. As a user I am concerned about spam. I just have to look at the spam diary entries to know that without some controls we will have a problem. To start off, I'd like to see those controls only allow a small segment of the community to have the ability to send bulk messages. Two ways this could be accomplished is either having the local chapter provide a list of users that could send bulk messages or only users with an OSM email account. As a local organizer, I would dearly love the ability to contact mappers in selected geographical areas to invite them to special events or get input on major changes to the area, either from an import or a change in how a major feature is tagged, such as a highway. For a current example, one of the major trails association in our state is planning on redoing their website, possibly switching to using OSM as a basemap. Being able to contact mappers that have made a number of trail edits in the state to get their support for the switch would be beneficial. |
|
@cliffordsnow I assume @mikelmaron simply referred to the wrong PR, he likely meant the work on the group feature which is undisputed but stuck. This PR is about handing out our contributors e-mail addresses to third parties, quite the opposite of push notifications and controversial for a number of easy to guess reasons. (As pointed out in the discussion providing an API access to the messaging system would be more fitting specifically for the issues you mention, but nobody has coded that). |
|
Hey, this PR is exactly what I meant. Appreciate the support @cliffordsnow. Agree @simonpoole, the main blocker is policy. With a smart policy, it can help advance communication options for the OSM community. The Board did discuss this at the March Board Meeting and have taken up further discussion over email, but we did not get to it in the April Meeting agenda. Will revive this now. |
|
Once you've given e-mail addresses away you've given them away. No policy is going to change a jota wrt that. Naturally you could enter a contract with 3rd parties with perhaps a tad bit more control, but again that is not this PR. This PR is about giving all-comers unfetered access to the e-mail addresses. |
|
I wonder if there's really a need to hand out the real email address to third parties. We already have a mechanism for proxy email addresses when sending out messages to other mappers (i.e.. c-xxxxx-yyyy@messages.openstreetmap.org). If I'm not mistaken, the receiver of such a message can immediately reply to it and it would end up in my OSM inbox, as well as being forwarded to my email address. Can't we hand out such a proxy email address via |
|
Well that amounts to the same thing as providing an API for messages, except that an API would be more secure. Note that the system used for replying to diary comments and messages by email deliberately uses addresses that are tied to a specific message so that they can't be guessed or spammed and that would be harder to do for a generic address of the type you are proposing. |
|
My idea was to have a proxy email address tied to a certain oauth client (rather than a diary comment or message). If two different oauth clients would request my email address, the two of them would get different proxy email addresses, rather than some generic address which is the same for everyone. Once I revoke the rights for a given client, the respective proxy email address would also be gone. Here's how I see this approach: osm.org user:
Third party (Oauth client):
OSM website:
OSMF:
|
|
@mmd-osm while your proposal has nice properties, it only addresses the "sending mail" side of things, not the receiving part, which is why I would in principle prefer an API to the messaging system as we then could directly integrate that in to apps instead of relying on users receiving and not ignoring the notification e-mails (which might naturally be a moot concern if the HTML format mails are working well). |
|
@simonpoole : well as said before the third party notification would turn up in my osm inbox and forwarded to my personal email as well. Do you mind elaborating a bit further in how far that would be different in a messaging API setup? Also, can you describe in more detail how your use case looks like? |
|
@mmd-osm it is simply the reoccurring theme that users claim that they haven't received the notification e-mail and so don't go to check their OSM inbox. Naturally we can't check if these claims are really true ..... |
|
@simonpoole : ok, fair point, but isn't this at least partly covered today, e.g. JOSM checks every x minutes for new messages and would notify me? |
|
NB: a messaging api for tools like osmcha was proposed as GSoC 2018 project (see wiki page) |
|
I'm going to put my head above the parapet, and decline this pull request. It's been a couple of years without any clear progress, policy or otherwise, and the PR has bit-rotted too. But more importantly, I don't agree with the idea. There could be several aims with third-party applications wanting to gain email addresses - linking third-party accounts, dis-intermediating OSM, address harvesting, or whatever. But lets stick to the simple use-case of contacting our mappers for legitimate reasons. In this case, I would prefer to see an oauth permission to allow third-party apps to message our users, through our API, rather than take their email addresses and going to town with them. That would leave OSM(F) with at least some mechanism to step in and protect our mappers from messaging overload, in case of any problems with the way the third-party behaves. It might seem obvious to many people the difference between OSM emailing them, vs a third-party application emailing them, but I don't think that's clear to everyone. ("I signed up for OSM and I'm using your app and now you are spamming me please stop" etc) If the third-party really really needs an email address from our mappers and can't possibly live without it (e.g. for account linking), then they should ask for the user to provide it directly to them instead. So to reiterate, I would prefer to see an oauth permission to allow third-party apps to message our users, through our API, rather than handing out their email addresses. |
Which API are you referring to here exactly? AFAIK, we currently don't an API to support this use case. |
Yes, we would need to add an API either for messages, or for a more unified notifications system.
I'm not sure about this approach. We would then end up with a third party calling our API, to receive a proxy email address, that they then create and send emails to, in order to create messages in our API programmatically via emails, which need to be queued and parsed and acted on internally. That's instead of creating a message or notification directly via an API call. It seems a bit indirect to me, and it makes some things (like rate limiting API calls) harder to manage. If all we were doing was accepting messages and/or notifications then it would make more sense, but each client app will already be using our API anyway. |
We already have this in place as of today! Try sending a direct message via osm.org from user A to user B, and have user B reply to the email they receive. Currently, that email address has the format <m--@messages.openstreetmap.org>, but the underlying mechanism is pretty much what this proposal is about (+ additional "muting" of annoying senders by removing OAuth permissions). This email address can be easily reused and represents a one-way communication channel between those two users.
Depends a bit on the use case. I'm really having notifications in mind, where your Garmin or map download is ready to be picked up. In any case, sending emails would be more universally available and avoids the extra effort for everyone to implement some new (osm proprietary) messaging API. |
|
Is this going anywhere? I would really like to be able to notify my users without the need to make them fill a long form. |
|
@HarelM the way I think most people have been thinking of this up to now, is that whatever mechanism is in the end implemented, it would be primarily for sending a message to the website messaging system and, just perhaps, additional ways of notifying users of such messages (besides just sending an e-mail). |
|
For any alternative solution to work, we should first merge #1462 (after corrections), so that user have an easy way of revoking messaging permissions. |
Most social networks and other OAuth providers allow users to opt in to providing their email addresses to third-party services. This PR adds an
allow_read_emailOAuth permission, which adds a<email>what@ever.com</email>into the/user/detailsAPI output.