[OSM-talk] threats

[Immanuel Scholz]

Hi,

As the other in this issue, I think you expect some words from me..


> First, if anyone uses it to delete all the nodes or anything else stupid
> then I have to deactivate the entire account. I can't sit around pouring
> through the history. Currently you can't look through the history easily
> as an end user.

Ok, so the real problem here is NOT that Steve HAS to deactivate the
account, but that there is no possibility to revert changes done by the
user. Is this correct?

In other words, if there is a possibility to look at history and revert
changes, then the above concern is nil?

*finger crack*.. This item was long enough on the wishlist..


> Second, if anyone uses that account to upload copyrighted data and we
> get a cease and desist then I have to remove everything that account
> did.

Removing everything that is copyrighted is another option,
removing everything that was contributed the last 2 days over this
account is an option.
And removing everything that was contributed by a specific IP-Address
over this account is an option too (but would mean that we have to log
IP's - like wikipedia does).

Removing everything is an (very drastic) option, sure. But it is not the
only and probably not the best.


BTW: Having many bogus accounts does not help this issue much, as long
as accounts can be created automatically. Captchas?


> Third, it's just not due diligence to allow it.

I don't understand this.


> There are arguments for allowing ip address-based editing like wikipedia
> but it's not implemented at all.

Ok, so if I implement IP logging, this concern vanishes? I am fine if
the IP is not displayed along with the data.


> So we went on to IRC as jabber instant message was having problems
> (transcript below, please read, I've just removed his password). Imi
> published his user/pass for OSM (thus compromising everything above) and
> said if I deactivate the account then he's off for sure. I asked him to
> reconsider, see below.

My announcement about the deactivation was, of course, if the account
get deactivated only because I made the password public.



> These kind of threats are _unfair_, and having them linger is unfair.

I don't see it as a threat. Instead, I want to show by example, that
Steve can not stop people from beeing anonym if they want so. 

I showed this by example and made my account public, so everyone can use
this.

(Steve wrongly assumed, that an identity can be associated to a people
by a secret, even if that people does not want to be identified. That's
a common mistake in cryptography. Everyone can reveal his own secret and
claim not to be the associated because the secret was revealed)


> The other thing is the claim that I am trying to stop anonymity. Given
> the flak/flames I took for not releasing everyones login details, their
> gps traces etc (the entire database)... I'm just perplexed.

I want to make a clear cut between
- allow people to be anonym
- try to reveal identities of people, even if they want to stay anonym 
- since currently there is no (official) anonymous account, we can
assume, that all people who want to be anonym have used bogus accounts.


> Imi, please reconsider and let me change your password now its out in
> the open.

Well, ok. Change the password (it was silly anyway :). I just want to
demonstrate, that anonymity can not prevented by knowledge of secrets.

(hm.. I thought the bug "add a possibility to change passwords" was
fixed?)



Ciao, Imi.


PS: A bit of theory.

It is the same for anonymity (specific to a given value) to either use a
random number or use a constant value - both does not yield any
information.

So to prevent anonymity, you have to eliminate random numbers AND
constant values.

My revealing of my secret shows, that anyone can create a constant
number. Since currently everyone can create an account quite fast (and
this is good!), a random number can be created too.

So it is my conclusion, that people can be anonym (regarding the login
details). If we want to prevent spam/copyright attacks, we should choose
a different measurement than login details.