Modify

Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#8701 closed defect (fixed)

created_by submits too much personal information (operating system details)

Reported by: pendluuum Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: privacy Cc:

Description

Since May (release version) JOSM fills in details of the operating system version without notifying the user about it and with out a way to turn it off (is there one?). This is no good privacy practice!

It should only include "JOSM" and "JOSM version number", if needed.

Attachments (0)

Change History (19)

comment:1 Changed 4 years ago by Manu1400

  • Keywords privacy added

comment:2 Changed 4 years ago by framm

The change has been introduced in r5819 on 2013-03-31 and refined in r5851 on 2013-04-14. The driving factor seems to have been "better bug reports" but I agree that operating system details should not be uploaded to OSM without involving an user decision.

comment:3 Changed 4 years ago by skyper

  • Priority changed from normal to critical

This should have never been uploaded in case of privacy. Thought this information would only be used privately which still is not save as there is no secure connection available.

comment:4 Changed 4 years ago by bastiK

Agreed.

It is customary for email programs and browsers to include details such as operating system in the user agent. So I see no problem if JOSM does the same when JOSM sends requests to a remote host. Also for bug reports, we require this information.

However for the created_by tag in the changeset, "JOSM" and the version number should be enough.

comment:5 Changed 4 years ago by Don-vip

  • Resolution set to fixed
  • Status changed from new to closed

In 5956/josm:

fix #8701 - Do not include OS details in changeset created_by tag

comment:6 Changed 4 years ago by pendluuum

@bastiK: exactly - the difference is: the info in the changeset is permanently public for everybody in the world. The info during a connection is only temporarily accessible (at least it should be) for the communication target (the server).

Thank you Don-vip.

comment:7 Changed 4 years ago by pendluuum

  • Resolution fixed deleted
  • Status changed from closed to reopened

This fix (for a "critical" bug) should have been pushed out to release version much(!) faster. Still version 5939 is offered. Anyway, in the meantime every frequent OSM contributior who is using Webstart or is fastly manually updating has involuntary leaked his operating system details ... So it is not anymore that important to push it out now.

comment:8 Changed 4 years ago by Don-vip

  • Resolution set to fixed
  • Status changed from reopened to closed

This is not so critical, and tested version is coming in a few days, have a look at DevelopersGuide/Schedule

comment:9 Changed 4 years ago by pendluuum

Well, there should be bug fix releases of the "tested" versions ... I will not use the "tested" (which is apparently not that true) via webstart anymore but manually use a .jar and update every now and then AFTER reading the change log. Time which I also could use to contribute to OSM ...

comment:10 Changed 4 years ago by framm

pendluum, I think you are overreacting. The bug was reported and fixed quickly enough, and it never was a critical bug in the first place. OSM contributors tell the world *much* more about themselves than which operating system they use. I agree that there was a bug here and it is great that it has been fixed but now let's put the matter to rest, please.

comment:11 follow-up: Changed 4 years ago by pendluuum

thank you for your comment, framm. Yes, it indeed is very good that the bug got quickly fixed, however this fix is not quickly pushed to the users (makes the quickness of the fix nearly useless). I think it is not clever to not provide corrected versions until the next "tested" release. That way the "tested" users are stuck with the bugs.

Yes, OSM contributors are usually providing much information about themselves - however, that is voluntary and known to them. This bug caused a disclosure of information which was (likely) not known to the contributors. By the way: the OS info string is quite verbose on some operating systems (which may be in addition quite exotic) - I am not talking of Windows 7 x64 here.

Sorry for being quite annoyed by this (I think more people would be if they would know) - the JOSM devs are still doing very good work!

comment:12 in reply to: ↑ 11 Changed 4 years ago by stoecker

Replying to pendluuum:

thank you for your comment, framm. Yes, it indeed is very good that the bug got quickly fixed, however this fix is not quickly pushed to the users (makes the quickness of the fix nearly useless). I think it is not clever to not provide corrected versions until the next "tested" release. That way the "tested" users are stuck with the bugs.

We don't make bug-fix releases except there are major bugs in a tested. See also Releases about our release plan.

Remember that we have limited capabilities - mainly regarding OUR time.

Feel free to contribute to JOSM in any way you want, but don't expect that we change a system which works very well for several years now without real need. If someone will provide a bug-fixed version of josm-tested we have no objections, but we see no need for this at the moment. JOSM release policy may change, but ATM it is unlikely this happens in the near future.

Regarding this issue: In any case this bug does not have enough importance for special care.

comment:13 Changed 4 years ago by stoecker

  • Priority changed from critical to normal

comment:14 Changed 3 years ago by pendluuum

note that the reverter plugin reintroduced the bug! It was fixed 16th June 2013 at 15:04 https://trac.openstreetmap.org/changeset/29663/subversion However, the JOSM tested version does not update to a newer version than 29561 where the *bug is still active*. Not that nice ...

Could the method getAgentString be set to default to not leak the user's OS details? Maybe there are more faulty plugins?!

Last edited 3 years ago by pendluuum (previous) (diff)

comment:15 Changed 3 years ago by Don-vip

So please update to latest. This problem is fixed for good, please let it go.

comment:16 follow-up: Changed 3 years ago by pendluuum

Don-Vip, that does not answer my question.

However, yes it is okay. Thank you for finding the problem before I did (yesterday) in the plugin. I guess that with the next tested release the plugin will also update.

comment:17 Changed 3 years ago by Don-vip

The answer is no. There was a problem (thanks for reporting it), but now it has been fixed, so we don't care anymore about this one but we focus on another ones. We have a pool of 1000+ open tickets and limited resources for them.

comment:18 in reply to: ↑ 16 Changed 3 years ago by skyper

Replying to pendluuum:

Don-Vip, that does not answer my question.

However, yes it is okay. Thank you for finding the problem before I did (yesterday) in the plugin. I guess that with the next tested release the plugin will also update.

If you did not change your plugin policy preferences not to do so, the answer is yes.

comment:19 Changed 3 years ago by pendluuum

Okay. latest versions work (I tested it with latest non-"tested" JOSM and the reverter plugin: JOSM/1.5 (6041 de);reverter_plugin/29663).

I could not find other equally problematic calls in the plugins directory:

Version.getInstance().getAgentString() without "false" is called in the following files, but apparently only used for server download connections:

Add Comment

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.