Store arbitrary files with Flickr's new 1TB storage limit (opens in new tab)

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.

Jacques, please consider for a moment that you can be right, and be an asshole at the same time. I don't consider being an asshole a cornerstone of hacking.

I don't mean literally that you're an asshole. I've always enjoyed your posts, and I get that you're not acting with malice, which is a cornerstone of being an asshole :) But this is one of the core tendencies that contribute to the perception that geeks and hackers are "socially inept".

Consider the following made-up scenario, even if it is contrived. Try to avoid the urge to pick it apart on a literal basis and focus on how this breeches basic social contracts. Then consider that normal people work at Flickr, and that those people are trying to do something good for users.

---

Me: This is my library. It's for storing books. You're welcome to store some of your books here as well.

You: <Starts bringing in boxes of random stuff and placing them on shelves.>

Me: Hey, what are you doing?

You: You didn't say I couldn't store random stuff here, and you haven't implemented any counter measures to prevent me from storing random stuff, so I figured it was ok.

Me: You're kind of an asshole. Did you know that?

---

I'm not saying the hack isn't cool. I'm not saying the hack shouldn't exist. I'm just saying that it's OK to point out that using it might be considered a dick move.

Like pooping in urinals?

Well, yes. Until you find out that they are analysing your documents and send you an email explaining why you no longer can access them.

I guess 'noise' does not a photo make.

Of course I doubt they will implement that kind of filtering, but this 'invention' is not that original/difficult/interesting, I guess.

The fact that the original designers did not say anything about this does not mean they did not envision it, by the way. Simply that they may very much either do not care or have a recovery plan.

EDIT: this is obviously easily circumvented with a lot of traffic going on but it is just a simple idea.

The problem with Jacquesm is that he doesn't understand the term 'hacking' in general. Hopefully, I will try to explain what I know.

Jacques,

Hackernews isn't for people who hack stuff that is against the law or something like that. Why would PG want to create a site for criminals? Hackernews is for the other new generation 'hackers' (like growth hackers, design hackers) etc. Not for stuff like this.

Imagine, I rent you my apartment and you 'hack it' into a miniature casino or a drug dealership. When I rented you the apartment, I rented it to you in good faith that you wouldn't do these things. But now, you broke my trust and next time when I rent out my apartment, I would go take some extra steps like installing security cameras inside every single room of the apartment because I have to protect my apartment from unethical usage scenarios. That's the same case with Flickr. So, clearly, this is something that is destructive to someone who gives you something with a good intent. Just because you can do it, doesn't mean you should.

I don't see how the label "hacking" confers anything about ethics.

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

While I understand what you are saying, it does imply that people should not try to experiment or think of new usages because "it will ruin it for everyone else".

Yeah, on the one hand this sort of thing seems like a fun project, but on the other hand it's incredibly exploitive.

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."

Decompress and subsequent recompress would do this just fine.

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.