"Diez B. Roggisch" <de...@nospam.web.de> writes: > Your web-based chat uses HTTP, no P2P-protocol, and thus the service > provider *can* log conversations. I don't say he should, I don't say I > want that, I don't say there are now laws that prevent them from doing > so, all I say is he *can*.
Sure, my complaint is that the default setup caused this to actually happen so lots of people using that software were recording user conversations without realizing it and maybe without caring. This is a bad erosion as I see it. > Then stop logging. Or get a hosting-provider that allows you to > configure it to strip QUERY_STRINGS from log-entries. And if they > refuse to, maybe using POST solves the issue. I did stop logging. There wasn't an issue with the hosting provider since I was running the server myself. But I had to resort to some ugly software kludge to stop logging those particular strings. More frustratingly, I filed a bug report about the issue against the chat software but the conversation was sort of like the one you and I are having now. I just couldn't convince them that there was a problem and that they should change the default. > http://www.cyberciti.biz/faq/apache-mod_dumpio-log-post-data/ > So what if they run that? That sounds like something someone would have to go out of their way to install and use. It's not the default. Of course if someone is malicious they can do all sorts of nasty stuff. A coffeeshop that wanted to mess with me on purpose wouldn't have to do high tech crap like recording my conversations--they could just poison my coffee. I have to trust them to not do this on purpose, but then I see a situation where their coffee sweetener accidentaly has a harmful chemical, so of course I'd ask them to do something about it. > So, for the umpteenth time: data sent over the wire can be recorded. And for the umpteenth time, I'm less concerned about "can be" than "is". POST isn't logged unless you go to some lengths to have it logged. GET is logged unless you go to some lengths to prevent it. It's not enough in a software deployment to only consider what actions are possible. It's important to make sure that the default actions are the right ones. > If they have a positive obligation not to do it, it doesn't matter if > they run their service over GET or POST. GET makes it harder for them to fulfill their obligations. As a security nerd, I saw what was happening and took measures against it, but a more typical operator might never notice or care. There is also the matter of the referer header which an anon mentioned, though it didn't apply to this particular situation because of how the application worked. -- http://mail.python.org/mailman/listinfo/python-list
