Wrote up an idea about using profile images to store metadata for syncing open-source apps
Wrote up an idea about using profile images to store metadata for syncing open-source apps
Saw the post on Mastodon that linked over here and decided to give it a shot. I just wrote up this piece which feels like maybe it would fit.
How will the robot dj go about retrieving the metadata, and what will it do with the contents?
Initial metadata will come from the Spotify Web API. It provides the top songs and all the playlists for an individual. It also has a basic recommendation engine. The DJ will use all those as input to produce new playlists (which can be created via the API as well). I'm not doing any AI/Machine Learning. Just coming up with a bunch of if/then statements, randomization, etc... to see what I can pull off
The metadata is a genius idea; I didn't even think of that when running through ideas after reading your post. Thats probably the best location actually.
This is a fascinating concept. I used to store encrypted private keys in images on social media sites I never used as a way to have a good backup.
You can even break up the data and store it across multiple images, instead of say a single avatar. If the site like facebook did support a gallery.
Your prose is good too, very clear, I wish I could write as well as you do.
Another method is having two accounts on a social media site say reddit, and storing data within PMs between the users. You can be explicit and store the data unobstructed or use come up with a type of hash like a mnemonic hash that converts your block of data into somewhat meaningful lorem ipsum text.
Again you can split the data across multiple messages and reconstruct them to get bigger file sizes without overloading a single image or message.
__
A different technique but also side-channel based, so you might be interested in it; is storing data not in the transmission of the packets themselves but the distance between the messages. So for example you encode your message into time durations, then connect to a computer using ping or DNS lookups, or hitting a specific page from an IP. And the server stores the durations between connections from the expected IP address and reconstructs the data. That way the data itself is never actually in a packet, but help in a side-channel.
oh, a side-channel based on durations. Very cool idea. You've got me thinking of ways to use playlists where the duration of the songs is what's important. I don't think that's exactly the same as what you were talking about, but it's another potential way to store data. The docs says you can put 10,000 songs max on a playlist, but there's no limit to the number of playlists. Of course, that's also interesting because there's a plain-text "description" field. I don't see details in the API docs, but it sounds like maybe there's a 200character limit for those. Lots o bits to play with
(also, thanks for the compliment on the writing! that post took about three hours to write and edit so I really appreciate it)
Yeah, that could work. I'd recommend trying to find other side-channels to store data in too so you don't require a massive play list. For example, length of song name, or difference from last song name + the time difference. Thinking of these is fun because it really gets your brain working. There are so many clever techniques to either hide, or transmit data without anyone ever knowing its happening.
I think it's a really cool idea. My first concern is about the amount of information that could be stored. I'm betting that syncing for certain services or use cases means transporting a significant amount of data.
You would definitely want to compress your message before adding it to the image. Using smething modern like ZStd provides incredibly high compression rates. And ideally this type of storage is best suited for backing up private keys in places that you can locate later, and are unlikely to be either noticed or deleted.
Size could definitely be a concern. I've got no idea what my requirements will be, but I at least know what the constraints are. For a baseline, each image can be up to 256KB. In theory, you can have 10,000 playlists (each with an image), but I wouldn't actually want to have more than one or a handful at the most so that it doesn't get in the way of the actual user's playlists. Of course, there's a good chance you wouldn't get all 256KB. They may let you send in arbitrary data, but I wouldn't be surprised to find them erase anything that's not a valid jpg. Also, if they re-compress after upload, that would be another hurtle.
But, generally speaking, this is a way to allow folks to write arbitrary data to the net that you can use for syncing (or whatever, but syncing in my case) without having to run a database or user accounts. And, once you can do that, it's game on.
This is done all the time using github. Especially by malware.
Yeah even with nice compression like zstd and newer encryption algorithms like SUPERCOP you are going to still end up with quite a bit of data. Its always easier to sneak it into a binary or image than side-channels. And if the music is coming from an API then obvio you lose a lot of the places you can hide things.