Live data from Hacker News

A proof-of-concept system for counter-surveillance against spy drones

wired.com

41–50 of 71 posts

Re: A proof-of-concept system for counter-surveillance against spy drones

#41
post #39
post #33

Earlier quoted context omitted.

Or and even easier way: just have the drone fill up the stream with random data so that the data stream never goes "quiet" when the image is mostly unchanged. No sacrificing video quality or freshness required.

So you compress the video to a smaller size, and then fill in the bandwidth you saved with random data? Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video?

> Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video?

Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage, especially if the radio channel is congested.

Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any prediction from the observer useless.

Re: A proof-of-concept system for counter-surveillance against spy drones

#42
post #39
post #33

Earlier quoted context omitted.

Or and even easier way: just have the drone fill up the stream with random data so that the data stream never goes "quiet" when the image is mostly unchanged. No sacrificing video quality or freshness required.

So you compress the video to a smaller size, and then fill in the bandwidth you saved with random data? Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video?

It's very likely that the drone doesn't have enough bandwidth to send the raw video, so you need to compress.

Re: A proof-of-concept system for counter-surveillance against spy drones

#43
post #41
post #39

Earlier quoted context omitted.

So you compress the video to a smaller size, and then fill in the bandwidth you saved with random data? Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video?

> Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video? Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage, especially if the radio channel is congested. Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any predic…

> Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any prediction from the observer useless.

If it's actually random, wouldn't the average bitrate of "still scene + occasional random data" still be lower than "active scene + occasional random data"? Given enough samples, of course.

Re: A proof-of-concept system for counter-surveillance against spy drones

#44
post #33
post #28

Earlier quoted context omitted.

Couldn't this be bypassed by regulating a drone's bitrate to a constant steady flow? The sacrifice will be either video quality or freshness of data, but it would be a straightforward way get past that protection.

Or and even easier way: just have the drone fill up the stream with random data so that the data stream never goes "quiet" when the image is mostly unchanged. No sacrificing video quality or freshness required.

You can't compress truly random data, though. I guess you'd have to sufficiently pad the stream with data that compresses to a constant bit rate.

Re: A proof-of-concept system for counter-surveillance against spy drones

#45
post #43
post #41

Earlier quoted context omitted.

> Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video? Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage, especially if the radio channel is congested. Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any predic…

> Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any prediction from the observer useless. If it's actually random, wouldn't the average bitrate of "still scene + occasional random data" still be lower than "active scene + occasional random data"? Given enough samples, of course.

The average doesn't really matter. The researchers are looking for "steps" in data streamed caused by changes in the video. If you're adding random levels noise it will drown the signal that the researchers are looking for.

Re: A proof-of-concept system for counter-surveillance against spy drones

#46
post #31

I expect image detection in a video stream is pretty advanced these days but I'd imagine you'd need to rotate the image being recorded 3D space to match the plane of the window so you can compare them both? If you know the position of the drone relative to the window, that's doable. Maybe the algorithms are clever enough to account for that these days. Interesting article - thanks for sharing.

Their technique doesn't actually do any image analysis at all, since the video stream from the drone is encrypted and they can't view it. Rather, they monitor the bitrate of the video stream and exploit the fact that static/unchanging scenes compress well and have a low bitrate while scenes which are changing have a higher bitrate. They then deliberately change the scene (by blacking out a window) and see whether the…

Got it - thank you.

Re: A proof-of-concept system for counter-surveillance against spy drones

#47
post #33
post #28

Earlier quoted context omitted.

Couldn't this be bypassed by regulating a drone's bitrate to a constant steady flow? The sacrifice will be either video quality or freshness of data, but it would be a straightforward way get past that protection.

Or and even easier way: just have the drone fill up the stream with random data so that the data stream never goes "quiet" when the image is mostly unchanged. No sacrificing video quality or freshness required.

> No sacrificing video quality or freshness required.

Just drone battery life

Re: A proof-of-concept system for counter-surveillance against spy drones

#48
post #33
post #28

Earlier quoted context omitted.

Couldn't this be bypassed by regulating a drone's bitrate to a constant steady flow? The sacrifice will be either video quality or freshness of data, but it would be a straightforward way get past that protection.

Or and even easier way: just have the drone fill up the stream with random data so that the data stream never goes "quiet" when the image is mostly unchanged. No sacrificing video quality or freshness required.

Constant-bitrate codecs modes are what you want.

Re: A proof-of-concept system for counter-surveillance against spy drones

#49
post #41
post #39

Earlier quoted context omitted.

So you compress the video to a smaller size, and then fill in the bandwidth you saved with random data? Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video?

> Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video? Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage, especially if the radio channel is congested. Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any predic…

All that would do is increase the number of intervals that would need to be observed. Adding noise to a channel only reduces the bandwidth of the channel.

Re: A proof-of-concept system for counter-surveillance against spy drones

#50
post #43

Earlier quoted context omitted.

> Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any prediction from the observer useless. If it's actually random, wouldn't the average bitrate of "still scene + occasional random data" still be lower than "active scene + occasional random data"? Given enough samples, of course.

The average doesn't really matter. The researchers are looking for "steps" in data streamed caused by changes in the video. If you're adding random levels noise it will drown the signal that the researchers are looking for.

But you are still open to a timing attack, no?

The random noise becomes the background and unless it is a constant addition of noise (which wouldn't save any bandwidth, might as well use uncompressed stream) you could still time changes in the signal.

Post reply on HN