Store files in your Flickr account | Hacker News Reader

Store files in your Flickr account

github.com

104 pointsricardobeat34 comments

As someone stated in the other HN thread, this is a bit of a dick move.

https://news.ycombinator.com/item?id=5741905

I must have missed that thread. It's almost the same implementation.

It's just a fun POC. It's not reliable, efficient or fast enough to be something you'd use daily. I imagine it would be quite easy to filter out (and revoke API keys) if something like this started becoming popular.

The act of abusing this script to store large files at Yahoo's expense is a dick move, but writing this script is not a dick move.

The act of abusing this script to store large files at Yahoo's expense is a dick move

Why?

...is it mutually beneficial, if you store legitimate images? Yes.

...does it benefit Yahoo in any way, if you exploit a currently open loophole to store data that is not an image? No.

How are you defining "a dick move"?

Oh please. You know exactly why.

Actually, I don't, otherwise I wouldn't have asked.

Why are you so mean?

Heh, sorry. Perhaps I should have used a ':P' emoticon. I didn't intend on being mean.

It's a dick move because it takes advantage of their systems to do things they clearly don't want you doing.

I read the flickr TOS. I don't think this violates it.

How is this a dick move? Get over yourself. They're valuing the company at $1.1 Billion. If you can actually drain any significant amount of their resources then sure it's a dick move, but crazy impressive.

Besides, you really think Yahoo! would be so upset that hackers are using their site for a public CDN? Sure they might make a big fuss, but they probably would think it's cool too. Afterall, flickr started as an online game. Who's to say they won't pivot again?

Further, as much as anyone wants to complain about the downfall of hacker news quality, this has made me more cynical than anyone's nit or snark or trolling.

>They're valuing the company at $1.1 Billion.

Flickr != Tumblr

>I read the flickr TOS. I don't think this violates it

Doesn't mean your account won't get suspended. I'm sure the TOS has a "we can do whatever we want to your account" clause somewhere in there.

You can't use Flickr as a public CDN AFAIK. Their terms require if you use flickr to host an image displayed in another page that page must provide a link to the photo's page on flickr.

Flickr also only allows photos, illustrations and screenshots. (and video). Nothing else.

These terms are not spelled out in the ToS but in their community guidelines and faq

There are plenty of examples of people having their accounts closed for not following these rules.

It isn't a dick move. It doesn't hurt Yahoo, and most likely will hurt the 'abuser' since Yahoo will just suspend such accounts whenever they feel like it, and the stored data will just be gone.

If you say you'll store images, and I make you store things that are not images - taking up hard drive space you didn't intend to let me use - that hurts you financially.

Any other reading of the situation is based on fantasy.

The "financial hurt" is mitigated by the fact that they can just ban your account and your access to your terabyte of stored data and possibly other yahoo services, anytime they want.

>Any other reading of the situation is based on fantasy.

Not necessarily. It is possible that Yahoo engineers may actually be amused and supportive of the way their service was remixed.

How is that "mitigated"? You're saying there's a natural defense to this first attack, so therefore the attack doesn't hurt.

Except it costs engineering time to fight back against this attack.

Then, someone starts putting the file into the RGB channels.

Then, it costs engineering time to fight back.

Then, someone starts putting the file into the low-order bits... which happens to make the file compress terribly, compared to a normal PNG.

Then, it costs engineering time to fight back.

Talk about cynicism. As I wrote, it is possible that Yahoo could be amused and supportive of this project, no? Corps react in various ways, and Yahoo could go either way. So unless you're representing Yahoo, why go about bitching at people for a clever remix that technically doesn't violate the TOS and doesn't exploit any vulnerabilities, when Yahoo hasn't even made an official statement.

Second ... you're characterizing it as an "attack"... really? The people who'll try to use it would be people who just want some cheap cloud-storage. And as I said before, they should use at their own risk, else they may wake-up one day and find their account is banned, and the terabyte of data they uploaded (which takes a non-trivial amount of time) will be gone, along with their yahoo mail and anything else yahoo was hosting for them.

Seriously, why the stick up your ass?

This version makes files 2-4x larger than the original. You think engineers and devops like something inherently 2-4x more demanding of storage than it could be? You think CFOs like that?

I've supported similar services, and people who think they're being clever, to exploit my FREE SERVICE to do things it was never intended to do, really piss me off.

Here's an idea: ASK.

Hey, Flickr, a free TB is awesome! Mind if we store arbitrary files on it?

Yes, it's an attack. It's a classic predator-prey relationship. When you proposed that they prey could exert energy to defend the service, you were merely describing the next single step in that relationship.

> The people who'll try to use it would be people who just want some cheap cloud-storage.

...and they won't pay, and they don't care who they hurt.

Would you defend them, if they each made 100 Flickr accounts, just so they could get some more cheap cloud-storage? 1000? What if Amazon decided to implement their S3 storage on top of this free Flickr storage?

Is your argument that there's nothing inherently wrong with exploiting people who offer you something... only if you REALLY, REALLY exploit it?

I definitely thought this was going to be storing data as the image.

I'd be interesting in the (computational) detection for that. Of course, if you just encode/decode it, Yahoo could do the same.

If you encrypt the data, they could just check to see how high the entropy is. If it's higher than what's plausible for a real photograph, they'd delete it. (using ent [1])

Else, you could use good ole stenography. In researching this response I came across the term Steganalysis[2]. Pretty interesting!

[1] http://www.fourmilab.ch/random

[2] http://en.wikipedia.org/wiki/Steganalysis

Already done 7 years ago :)

http://search.cpan.org/dist/Net-FS-Flickr/

Stores versioned files by encoding them in the lower order bits of PNGs in a Flickr set.

Example stored file: http://www.flickr.com/photos/simonwistow/sets/72057594097765...

This starts to get my imagination going. What if you would use all kinds of websites, which allow user-submitted data, and encrypt and distribute the content. You could create an underground internet hosted unknowingly by other people. You could even encode your data so it looks like real image or natural language data.

I've been thinking about such a thing for a while now. Imagine a tool that uses DHT (distributed hash tables) for indexing and search plus a set of plugins that speak the protocol for each individual datastor be it dropbox, regular http, flickr, etc. It could include redundancy and maybe even bittorrent as one of the datastors.

Well, yes. The fact is you would be at the mercy of minor changes in that data which would make your 'data' worthless. As simple as, for example:

'Next month we are going to transform all our utf-8 fields into utf-32 and we are going to add some padding to your data, for analytics'.

You would have to cope with that.

Which, honestly, would be a lot of a mess. Distributed mess, also. Something like the proverbial fan & sh*t thing.

Not really. As long as you build in redundancy. Ie, automatically distribute multiple copies of the same files or blocks over multiple different sites. Yes, all of the sites could make breaking changes at the same time, but then all of the disks in your raid array could die at the same time too... Hence backups.

Dog-slow-array-of-free-websites. Definitely needs a sexier acronym.

This could be done with git annex http://git-annex.branchable.com/

What I would like is a program for uploading RAW files to Flickr, but clearly Flickr is opposed to this.

If you're unable to use zTXt, you could store the bytes in the RGBA pixel values. Those are compressed, and you get some interesting images as a bonus :)

It was only a matter of time before someone did this, wasn't expecting something so fast though. I bet Yahoo! aren't anticipating people using that whole 1TB, but with something like this I could easily fill 1TB in music/videos very quickly.

Now if someone takes it one step further and creates a Site44 for Flickr: http://www.site44.com/ — we'll truly have it all.

Isn't videos is perfectly allowed so long its self-produced?

It was only a matter of time until someone came up with something like this. Use at your own risk, and make sure you don't have anything you wouldn't mind losing on the Flickr service since Yahoo can just arbitrarily close your account at any time.

Well that didn't take long.

I figured this would happen eventually, obviously yahoo will spend a considerable amount of time trying to detect this and remove it...

I knew something like this was going to pop up. Now we just have to wait and see how long people can get away with it.

Reply on news.ycombinator.com