Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

wired.com

Post reply on HN
Print view View original

61–70 of 71 posts

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

#61

Post by electrograv »

_jgvg wrote: post #41
Drakim wrote: 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…

These are opposite things:

> Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage

> Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data

You cannot simultaneously reduce network bandwidth and also increase it. Of course padding with noise increases bandwidth, but it's silly to do that when you could instead be padding it with more bits relevant to the video stream.

The vulnerability here isn't inherent to video compression; it's that the compression rate (and therefore network packet rate) is variable (so as to minimize global size of a video stream). It would not be that difficult to modify an encoder to guarantee fixed bit rate over whatever time chunk you want (depending on how many frames is tolerable to buffer before sending out), then send out those chunks at regular intervals.

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

#62

Post by electrograv »

anigbrowl wrote: post #56

Constant bit rate compression isn't a cure-all. It's generally inferior to VBR which is why the latter took off in the first place. CBR is easily degraded by just increasing the amount of visual complexity. Leaves moving on trees in a breeze is a typical problem case. So if you're worried about being spied on, high-resolution mosaic patterns are your friend. Mirror or high specularity pigments will enhance the effect…

The minimum bar for usable quality can be defined precisely, and an encoding algorithm designed around it.

One obvious extreme example of this would be no compression at all, but it's easy to imagine much better designs.

For example, imagine I define a spec where I require quality no worse than a lossless 500x500x24bit/frame video stream. If we budget a bit rate higher than is required for the naive raw transmission of those frames, we can first encode the naive frames, then encode the deltas between them (upscaled to full resolution) such that the reconstruction error is minimized while not exceeding any maximum tolerated error per pixel.

With this approach, you are not crippled when facing an adversarial pattern generator of some kind, yet when transmitting regular natural scenes, you can benefit from significant quality increase.

As you suggest though, it's true that generating the most complex patterns possible will reduce any drone's video quality as much the codec's design permits -- however accomplishing this seems much more expensive for relatively little benefit versus other counter-drone approaches.

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

#63

Post by yjftsjthsd-h »

alistproducer2 wrote: post #13
lb1lf wrote: post #11

Earlier quoted context omitted.

Buffered transmission is unlikely to help; after all, the surveillance target could store the received stream and look for patterns - it would only delay detection for the length of the buffer (which often would need to be kept short due to the real-time nature of much surveillance. Granted, you could obfuscate things by varying the buffer length and padding the data stream (as suggested near the end of the article)…

>Granted, you could obfuscate things by varying the buffer length and padding the data stream Or maybe sending the blocks out of order to be reconstructed according to a shared ordering key?

I don't think that helps with metadata analysis? Assuming I'm following correctly, we're already encrypting, so it shouldn't matter what order we send... Unless you mean to shift around bandwidth spikes, which could help some

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

#64

Post by yyzhero »

nullbyte wrote: post #58
_jgvg wrote: 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…

It takes more CPU and battery to compress the video than to leave it raw. So sending a lossless or semi lossless version of the video should theoretically work.

wireless transmission costs magnitude more then CPU cycles hence delta frames.

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

#65

Post by princekolt »

wyc wrote: post #28
personjerry wrote: post #19

My tl;dr understanding: Drones send video back to operator. Video is typically compressed so that it only updates part of the picture that have changed. Even if the video is encrypted, the researchers are able to measure the bitrate. Thus when the researchers make a significant change like putting a board against a window, and seeing if the traffic increases, the researchers can determine whether the drone is looking…

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.

Indeed. However, it is a very good practical example of why encryption alone doesn't do much. (If the attacker can measure your data stream, they can make statistical assumptions and pull a lot of useful data out without breaking the encryption).

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

#67

Post by rebuilder »

_jgvg wrote: post #33
wyc wrote: 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.

A constant bitrate video codec seems much simpler, IMO.

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

#68

Post by a3n »

> All of that may seem like an elaborate setup to catch a spy drone in the act, when it could far more easily be spotted with a decent pair of binoculars. But Nassi argues that the technique works at ranges where it's difficult to spot a drone in the sky at all, not to mention determine precisely where its camera is pointed.

This technique could also be used in legal proceedings to establish that someone or some org was spying illegally.

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

#69

Post by Hupriene »

totalZero wrote: post #53
Hupriene wrote: post #49

Earlier quoted context omitted.

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.

I could be wrong, but I don't know if that is true here. First, if the receiver is aware exactly what parts to ignore, and the transmission itself is not interfered with or altered, then it's not really noise as far as the channel is concerned. Second, the assumption here is that spurious packets would be sent when data is not being transmitted, so this principle probably wouldn't hold anyway because the "noise" is i…

1. The receiver here is the person determining whether or not they are being spied on. Not the user of the drone.

2. In order to make the real spikes fit into your random pattern you'd need to be able to predict when they will happen.

Post reply on HN