[josm-dev] Mandatory login for JOSM wiki

[Dirk Stöcker]

On Sun, 27 Feb 2011, Frederik Ramm wrote:

>>  First of all, if you have a fresh JOSM install, there is no way anyone
>>  can inject anything into it. The worst that can happen is someone puts
>>  spam entries into one of the lists. I'm not aware, this ever happened, but
>>  it wouldn't do much harm. You'd only see it in the preference dialogue and
>>  not somewhere in the main menu.
>
>>  Each extension (preset, style, plugin, wms url, remote control) is
>>  explicitly activated by the user.
>
> Ok. It seems I have indeed misunderstood Dirk's "JOSM mappaint styles, mapcss 
> styles and JOSM presets can now be made in the JOSM Trac wiki pages.". I read 
> into that that even the default settings were maintained in trac which they 
> don't seem to be.

No. As long as I'm maintainer the base functionality will not be 
crowd-based.

> But still I think the potential for malice in these should not be neglected. 
> Anybody can, anonymously, change the list of map layers in trac, and that 
> will become the default list for any newly started JOSM instance from that 
> second on, isn't that so? This means that I can easily add some non-allowed 
> sources there, or change the Bing URL to one pointing to my ad server, or - 
> and I tried that out just now - make the imagery menu look like this: 
> http://www.remote.org/frederik/tmp/sucks.png

We could prevent the possibility to use or change "true" in the default 
column and handle that internally. This would reduce the effect a lot.

I think about a nice solution, which will not make the column completely 
useless (maybe I find a solution, that only admins can change it) and 
implement this soon.

> You could then revert that change after you notice it, but everyone who has 
> started their JOSM instance for the first time between the change happening 
> and you fixing it would have the manipulated setting on his machine until he 
> actively takes steps to fix it (provided he finds out). And you wouldn't even 
> know who did it, and they can do it again and again and again until you 
> require a login for the page.

Actually it is not that critical.
1) Not all, but only these, which are over the 1 week caching would be
    affected.
2) The spamfilter is very effective and catches a lot of "sucks" and texts
    alike.
3) To get rid of one person usually training the filter is enough, as it
    soon adapts.
4) Pages can be temporarily write protected.

And it is much easier to deface the JOSM start page.

>>  In [3936] I changed plugin descriptions, so the user can spot plugins that
>>  come from an external source. What else can we do?
>
> I would feel much better if there was some accountability to changes in the 
> plugin list - i.e. I would like to know that user XY with email address Z 
> added a certain plugin to the list, rather than having that edited 
> anonymously. If it is too much trouble to flag individual pages in trac for 
> that, then maybe just have the list in another system - even OSM SVN if need 
> be.

We can flag pages to have different restrictions. It requires some work 
with Trac to get this done. But it also means other infrastructure 
changes. To get valid E-Mail addresses we would need to verify login 
addresses.

I'm not conviced in this case that this work is necessary (yet). Changes 
to plugin page are watched with an open eye and when we get troubles, we 
simply could deactivate edit function for some time.

> What are the risks with the remote control mechanism?

It can exploit bugs in JOSM on a large scale and users will accept that as 
they think what they do is correct (assume a hack in one of the error 
spotting pages having some malicious JOSM related code). DOS is another 
issue here.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)