

Store arbitrary files with Flickr's new 1TB storage limit - meltingice
https://github.com/meltingice/flickr-store

======
gfodor
This is kind of a dick move to use IMHO. Clearly they are not giving you the
space to store arbitrary stuff. It's a neat hack and props to the author but
if enough people use this it will not only cause Yahoo! to have to build
countermeasures but will also set an ugly precedent for Yahoo! product
managers to consider before doing nice things like they did today.

~~~
jacquesm
This _is_ hacker news isn't it? Re-purposing things in ways that the original
designers did not envision is one of the cornerstones of hacking.

~~~
jasonkester
Please don't try to imply that the rest of us here agree with you in any way
just because we're on this site. Hanging out on a site called HackerNews and
having a basic sense of right and wrong are things that plenty of us can do
simultaneously.

~~~
jacquesm
There hasn't been a storage facility labeled get 'x'
bytes,Kilobytes,Megabytes,Gigabytes or even Terabytes free that did not result
in people wondering about if they could use it for general purpose storage.

What surprises me is that a service like this isn't hardened from day one
against the most obvious of flaws.

Of course it's wrong, but it is only really wrong when a billion or so people
adopt it, and chances are that this will never see widespread adoption, it's
just a guy saying 'see what I could do', not an army of people overrunning
Flickr.

The cognitive dissonance of seeing a single person perform a neat little trick
versus an army of people performing that same trick bringing down a service
sits well in my head, I don't feel this is in any way destroying Flickr, nor
do I think that it potentially will destroy Flickr.

It didn't happen with Gmail or any of the other services that were 'exploited'
in this fashion before. In fact, those are now trying to get me to put as many
files on their storage devices as possible (which I really don't want to, the
cost of storage is so low I don't need an external service to host my files
for me).

Lighten up.

~~~
swombat
Worth noting that the original comment said:

> _This is kind of a dick move to use IMHO._

Didn't say anything about creating the script, just about using it. Possibly,
using it at scale was even implied.

Creating this is a hacker move. Using it to store your server backups is a
dick move (and also potentially a poor backup policy).

~~~
ohwp
Also: setting up a webserver with over 1TB of storage is probably simpler,
faster and more reliable.

I also think in this case the hack is a little useless. But I've seen examples
where they use it to transfer a lot of 3D data for use in WebGL. And the
author of this script is also linking to a nice usecase where is is used for
game data: [http://blog.nihilogic.dk/2008/05/compression-using-canvas-
an...](http://blog.nihilogic.dk/2008/05/compression-using-canvas-and-png.html)

------
logn
... bonus points for whomever gets an HTTP server running on flickr. Maybe I
can store my music there too and stream from a webapp that plays these PNG
files.

edit: sorry I must be on the wrong message board. Thought this would interest
people. Guess I'll take my idea elsewhere.

~~~
MichaelApproved
That ruins the service for the rest of us. The phrase "this is why we can't
have anything nice" applies perfectly to this post and comment.

~~~
jacquesm
Maybe we should re-brand the service we're posting this on to 'ConsumerNews'
then?

~~~
MichaelApproved
Hacking does not have to equal abusing. I could advocate for fair use of a
service and still hack it.

~~~
jacquesm
What's your position on Daeken's hack of the hotel room locks then?

~~~
MichaelApproved
IIRC, he was responsible about the hole by telling the company first and
trying to work with them to get it fixed. He released the info after they were
unresponsive. I think that's proper way to handle that.

But this thing with Yahoo isn't really the same. One is a security breach
while the other is trying to abuse a service.

I like hacks and fun experiments. The idea of putting extra content in
pictures is interesting but OP was talking about setting up a system around it
to put it into wide spread use.

------
spiritplumber
I remember something similar popping up within days of gmail offering 1GB free
:) Good times.

------
jtokoph
It looks like we'll have a FlickrFS Fuse implementation shortly.

------
ValentineC
Flickr aside, I am surprised nobody (AFAIK) has come up with a way of
sanitizing uploaded image files yet.

I wonder if there's a way for GD/ImageMagick to detect the image data and
strip everything else. (And if EXIF data is needed for photographs, import all
non-binary EXIF data into the system first.)

~~~
nodata
mogrify -strip imagename.jpg

But it won't help. You could just make your data a real image.

~~~
pfortuny
You might as well change a single byte. A tiny modification and BANG! nobody
notices and the service is pretty useless as a general back-up solution.

They could even implement that in their TOS: "whenever you upload a photo you
agree to a random byte being modified on one of the pixels on the border."

~~~
shawabawa3
It would be pretty easy to stick in some redundancy

------
grapjas
Doesn't this already exist? Multiple times?

Oh well, obvious 'exploit'. Wondering how Y! will react. They must've forseen
this, right?

~~~
supergauntlet
Probably poorly.

Question though, how large of a file can you hide with steganography in a
300mb picture?

Would that be big enough to hide an MP3?

On a side note, can you upload files to Flickr that have data appended after
the end of the image data? Like people were doing on 4chan until moot removed
that capability.

~~~
rjbwork
I have a wee bit of Stego experience as I've written a couple of
implementations. Generally for it to be "undetectable", you shouldn't go with
more than 25% of an image file, assuming 24-bit color, being data, as it
quickly becomes apparent that there is something fishy going on. Your best bet
is to create a kind of "keyed stegonagraphy" where you generate a series of
keyed nodes, creating a cycle (in the graph theoretic sense) of nodes, each
node corresponding to a pixel, and the entire cycle determined entirely
deterministically from the key.

This is akin to key schedulers used in various cryptography schemes, I
suppose. The idea is that you REALLY don't want to just shove your data all at
the beginning of the file in order, as it becomes really easy to tease out the
data with some cursory frequency analysis/bruteforcing. "Oh the first 20
pixels encode the first X bytes of <insert well known file type here>,
BALEETED!"

Then you simply have each user pick their own key, stored locally, and have
the cycle generated on the fly when encoding and retrieving data.

------
JoshGlazebrook
I was wondering just how long it would take for this to pop up...

------
adamstac
Couldn't help but plug this on The Changelog: <http://thechangelog.com/flickr-
store/>

