It's hard to take you at your worldly-wise word when you completely ignored his point that photojournalism doesn't require optimal photo/video quality (and it's very high bandwidth demands) to be effective. Refusing to acknowledge someone's argument and trying to out-nerd them isn't very civil either.

It's a fair point and why I stopped and grilled some chicken a few hours ago instead of going deeper down the XKCD386 rabbit hole.

I feel that. It's easy to get carried away in an environment where social cues are so attenuated.

For me, old habits sometimes come back. If there had not been return fire to the second comment, it might have been deleted.

> It also seems that we conceptualize war zones in diverse ways. For me, when there are combatants in technicals [1] it's perhaps better not to assume good manners and wifi etiquette are prevalent social behaviors.

You misunderstand - it's nothing to do with etiquette, it's simple practicality. "Jamming" wifi over a city or town sized area simply isn't a technically feasible thing to do, which is why it doesn't ever happen. To be effective you'd need a device on every other block, more or less (urban environments need very high jamming density, mfr range claims tend to assume no obstructions). The level of organization this would require is simply astronomical, and it's nonsensical to think that somehow a government in the grip of a civil war is going to do this.

> TLS or Transport Layer Security [2] is a protocol to secure network communications using encryption. Building encryption into the cameras is what the concerned journalists are asking for.

Please try to avoid being overly patronizing - I'm perfectly well aware of what TLS is. There is a huge difference, however, between implementing a TLS-encrypted TCP request (e.g. simple file upload over HTTPS), and encrypting files locally. There's more levels of difference than I can reasonably cover in a HN post, however to pick one from the giant list: Locally encrypting files would require the user to enter a password every time they switched the camera on. Which is a usability nightmare. And they can't leave it on the whole time, as they may not get the chance to turn it off when the camera is demanded at gunpoint. I don't think I can stress enough how much professional journalists would not accept constantly having to enter and reenter a password to use their camera.

> As an aside, calling someone else's reasoning "silly" can easily be interpreted as uncivil and not in keeping with Hacker News guidelines. I've found Paul Graham's essay How to Disagree provides a useful perspective. [3]

Interpretations can vary. I apologize if I offended you, however at least by my reading of the essay, it's not covered in the guidelines. Calling an argument silly is not a personal attack, it's an observation that none of the arguments presented made any real sense.

> Locally encrypting files would require the user to enter a password every time they switched the camera on. Which is a usability nightmare.

This isn't true: you could use asymmetric crypto and encrypt the photos/video with the journalist's public key, leaving the private key at home. Encrypting to a private key does not required a shared secret. This prevents the journalist from decrypting the photos even if pressed to by authorities, assuming that "home" doesn't include the authorities' jurisdiction.

Not trying to nitpick, but it wouldn't necessarily be the case that you would have to enter a password. You could encrypt against an HOTP on the device and perform secure key erasure for the N-1th photo and previous. You'd then have a server which would be able to decrypt based on a one time shared secret (the HOTP root).