Hello /g/ As you might know, Google Photos allows infinite storage

>>59016136
yeah its infinite until google realises dogfucker.03 is using 90TB of disk

>>59016136

This would be only worthwhile if your time is worth nothing.

It would be incredibly inefficient and slow.

Run dd if=/dev/null of=<location of photos> instead and you will overwrite all data on Google's servers.

>>59016152
Is it hard to automatically generate Google accounts? Will Nocaptcha Recaptcha fuck me over?

>>59016183
Seems like a fun project to me

>>59016136
It does work. People used to share images with hidden files inside all the time on 4chan. Never download an image of a sink.

>>59016218
4chan doesn't compress images, that does make it a lot easier (4 bytes per pixel in the r, g, b and a channel)

>>59016136
How much space do you need that you came to think about this?

>>59016187
this

>>59016152

exactly this

>>59016187
Isn't it the other way around?

>>59016203
Ok, so you fly under the radar a bit longer. Then Google finds the metadata and blocks it. Beyond that, this can't be that much data.

Or a person can buy a 1TB hard drive and store their private data locally, without having to constantly waste bandwidth on download and uploading private data to someone else (Google in this case).

>>59016285
Not a whole lot. I was just thinking about this. It would be really cool to have a seamless FUSE filesystem of infinite size that seamlessy creates new google accounts and saves data in pictures

>>59016136
They already did this but for YouTube uploads and encoded files in the same way.

>>59016480
And it was a fucking disaster

>>59016480
Link?

>>59016537
The project is out there and there were threads months back about it. I don't remember its name. I tried jewgleing some keywords but I am coming up empty. Good lack.

>>59016136
It won't work on google pics, might work on flikr since they don't convert the data.

>>59016844
There's still data in the processed pictures, just a little bit less of it. It's just a matter of finding the most efficient way without chance of data corruption.

>>59017158
How are you going to take a big file an run it through the google compressing scripts and after get a file that can be uncompressed in order to get yo shit?

>>59017204
Take a fully black or fully white image for example. I'm able to store 1 bit of data that way. Now split up the image in 4 different squares, and make each of them either black or white. Google wouldn't fully throw away all data, and you would still be able to retrieve the 4 bits of data you put into there. It's just a matter of looking how far you can go. You can probably throw some colors in there too for an even higher data density.

>>59017304
I remember a guy that combined a picture with a big archive and used the picture extension, uploaded all that to flikr(1TB storage) and it worked.
Can't remember how he did it.
Can anyone tell?

>Would this work?
Yes, I already do this.

>What's the most efficient way to store data into a picture

Use GdipCreateBitmapFromScan0 with PixelFormat32bppPARGB to create a blank image
Use GdipBitmapLockBits to get the the pixel data buffer from the blank image
Write the data you want to store into the buffer
Call GdipBitmapUnlockBits
Save image as PNG with GdipSaveImageToFile

You can store 4 bytes of data per pixel. The resulting image will generally look like a bunch of randomly colored pixels. The data can be retrieved by reading the pixel data buffer and writing it to a file.

>>59016218
>>59016262
People still share these images btw.