> This is a fundamental hole in security with no logical workaround.
There is no hole in anything. You're not violating anyone's privacy or stealing anything from anyone. Even the bandwith is given to you for free. It's how things are supposed to work.
You're just exercising your right to privacy by using such a thing.
One can tolerate someone re-inventing/re-discovering steno and making it sound like it's smth new... but not someone having no f idea whatsoever of what "security" means and what his "right to privacy" is... ffs!
Right. The article author seems to have re-invented steganography.
The hard problem is finding a way to encode data in video in a way that will survive recompression, resizing, or other video processing. The watermarking people have struggled with this for years. There are various spread-spectrum like schemes with good noise immunity that can do this.
YouTube has an ongoing battle between the copyright-infringement identification system and versions of audio and video modified to evade it.
Can't they simply use the least significant bit from each color channel to carry data? I think a single bit flip would change colors by a factor of 1/128, indetectable for the eye. Of course, use compression, encryption and redundancy too.
You can significantly increase the bit rate. For example, overlay a QR code over each of four consecutive frames. You can do this without frame dropping. You only need to add about 6dB of the code for this to be recoverable. Similarly, if you know how the codec works, you can exploit that. (Your proposed method is actually pessimal for a modern B frame codec!)
Then there is hiding modem transmissions in techno music sound tracks ;-)
I wonder how difficult it would be to find the optimal "storage" method for data within YouTube videos.
On the video side, you're dealing with at least VP9 and H264 which I'm assuming "destroy" your data somewhat in the encoding process. The audio side is Opus and AAC, with similar challenges.
H.264, VP9, etc., are all macroblock-based DCT codecs with I-frames that contain a full still image (like a JPEG), and other kinds of frames that contain instructions in terms of motion vectors of how those macroblocks move around. They also use colorspace transforms and color subsampling, so they intentionally sacrifice some color accuracy.
But writing a data stream into a 2D still image in a way that can be decoded later is a solved problem, ie. 2D barcodes like DataMatrix, QR Code, and Microsoft Tag (which has up to 8 colors to further increase data density). These formats have built-in error correction that compensates for some missing blocks. However, we can tune the format to be closer to the video codec's internal structure, to make them play nicer together.
For example, we can set each barcode block to be within 50% to 100% of pixel size of the video's macroblock, to make it more likely that the video codec can reuse the macroblock with motion vectors in a P/B-frame, instead of having to put more bits to it, or have it accidentally mangle it.
Realistically, we can also increase our color palette, as we're not going to be scanning these barcodes in bad light conditions -- all we need to do is get the color mostly right. But the more we increase the palette, the less video codec can reuse blocks; so this is something we'll want to experiment with.
The biggest problem for the barcode approach comes from the addition of the 3rd, temporal dimension. We can have each frame form its own independently scannable barcode, but doing so, we'll want to build in some temporal redundancy, ie. have a chunk of data, or error correction for said chunk, be present in more than one frame -- to protect against occasional frame drops, very inconvenient frame drops (like when you lose an I-frame and the video is grey- on green-blocky for several more frames), and offer some extra protection against "normal" decoding errors.
By the way, there are existing implementations of this concept:
You know those youtube videos which offer additional content in the description ? We can just enable a browser plugin to retrieve these files from a small corner of the video (displaying dynamic qr codes).
You can generate .wav files with all sorts of modulation methods centered at the frequency of your choice with transmission measure in kbps with https://github.com/quiet/quiet which provides a wav file encoder. You could then just add this wav on top of your video.
And if you're really feeling adventurous libquiet provides floating point output that can be put into any channel like video if you're willing to plumb it in there.
This makes no sense. If you have the ability to run software to decode the youtube video, then let's be honest, what is actually stopping you from just using Tor browser, or a proxy site to get to your content? Or just a USB stick with whatever data that you downloaded elsewhere?
Couldn't this be done with two live streams for TX/RX? effectively creating a VPN? As the author said there's plenty of modulation techniques possibly. Surely some much faster ones could be used.
The biggest downside I could think of would be the lag: data > render frames > encode frames > network > decode stream > render frames > scrape data
I think the author has not thought of frame reordering in error scenarios. If UDP is used, frames could even get dropped in the middle, and in case of TCP, frames could arrive out of order. That would wreck havoc in the odd-odd numbering sequence of the encoding.
> Once they identify videos that might contain encrypted data, they can then begin to work on decrypting that data. The amount of video data on the internet is massive and it is growing at an exponential rate (the zeta-bytes of data they would have to sift through, I cant even imagine the headache).
um. they already do that. They scan all the uploaded videos for copyrighted audio, fingerprinting and comparing the uploaded audio of a bajillion videos against 1/2 a bajillion songs.
While this is little more than simple steganography, I'd be curious to see what kinds of encrypted data size / video size ratios are achievable, perhaps using some more nuanced techniques or approaches.
It's definitely an interesting idea, but it's really nothing new. I remember a few years ago reading about people hiding compressed .zip archives inside of jpegs or something like that.
There is no hole in anything. You're not violating anyone's privacy or stealing anything from anyone. Even the bandwith is given to you for free. It's how things are supposed to work.
You're just exercising your right to privacy by using such a thing.
One can tolerate someone re-inventing/re-discovering steno and making it sound like it's smth new... but not someone having no f idea whatsoever of what "security" means and what his "right to privacy" is... ffs!