Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Neural-hash-collider – Find target hash collisions for NeuralHash

github.com

Post reply on HN
Print view View original

331–340 of 363 posts

Re: Show HN: Neural-hash-collider – Find target hash collisions for NeuralHash

#331

Post by saithound »

user-the-name wrote: post #329
saithound wrote: post #328

Earlier quoted context omitted.

There's a massive difference. In fact, the data describing the trained model is not at all analogous to a cryptographic key. A cryptographic key is a piece of information which, as long as it remains secret, should be sufficient to protect the confidentiality and integrity of your system. This means that your system should remain secure even if your adversary knows everything else apart from the key, including the de…

> E.g. just knowing some inputs and outputs of the secret model allows you to train your own classifier which behaves similarly enough to let you find perceptual hash collisions. This seems highly unlikely. You could train a model to find those exact known hashes, but I highly doubt you could get it to accurately find any other unknown hash. > You'd have to keep all of the following secret: the model, all its inputs,…

> This seems highly unlikely. You could train a model to find those exact known hashes, but I highly doubt you could get it to accurately find any other unknown hash.

Your "highly doubt" is baseless. Black box attacks (where you create adversarial examples only using some inputs and outputs, but not the model) on machine learning models are not new. They have been demonstrated countless times [1]. You don't need to know the network at all.

> These are all, in fact, secret.

This is not the case, since regular, unprivileged Apple employees can and will look at the inputs and outputs of the model (the visual derivatives and their hashes). It's also irrelevant.

You insist that there is some kind of analogy between "keeping the model secret" and keeping a "cryptographic key" secret. There is no such analogy. It makes no sense. It is simply not there. Keeping a cryptographic key secret keeps confidentiality and integrity. Keeping your model secret accomplishes neither of these.

[1] https://towardsdatascience.com/adversarial-attacks-in-machin...

Re: Show HN: Neural-hash-collider – Find target hash collisions for NeuralHash

#332

Post by foerbert »

zepto wrote: post #174
foerbert wrote: post #167

Earlier quoted context omitted.

That bit you quoted seems to be actually correct. It does not mention visual derivatives at all. That said I think your statement is a bit too strong, but generally true. A hash collision is not going to inherently be visually confusing. However you claim that it is impossible for an image to be both visually confusing and a hash collision, which seems unlikely. The real question is going to be how much more effort i…

I didn’t claim it was impossible, just that hash collisions won’t match both. Also, the information needed to create a full match simply is not available.

Are those not the same statement?

Unless you're relying on it being computationally infeasible, but I'm not sure we know enough to consider that true at this point. Usually when we make statements on those grounds we do so with substantial proof. I don't think we know enough to do so here. I'm not even sure how feasible it is when you throw DL into the mix.

Re: Show HN: Neural-hash-collider – Find target hash collisions for NeuralHash

#334

Post by ThinBold »

undecisive wrote: post #315
ThinBold wrote: post #156

Despite that Apple scanning our images is a horrible privacy practice, I don't get why 𝚜̶𝚘̶ ̶𝚖̶𝚊̶𝚗̶𝚢̶ some people think this is an ineffective idea. Surely you can easily fabricate innocent images whose NeuralHash matches the database. But in what way are you going to send them to victims and convince them to save them to their photo library? The moment you send it via WhatsApp FB will stop you because (they th…

It's a good question, and unfortunately you're probably right. It boils down to this: If you can prevent [some organisation] from potentially destroying civilisation, how much effort would be too much effort, and how much uncertainty is too much uncertainty? For most, there's a trade off. If someone believes that the technology is sufficient for any country to implement a brutal civil rights destruction campaign, and…

  save hundreds of lives, would you?
Sure, why not.

But let me ask some questions, because at this point I am not sure if people want Apple's system to be robust or jammable. If our fear is that Apple will tune the system to detect pictures of two men kissing, wouldn't an easily jammable system works in our favor because we can DDoS it or threaten to do so anytime we want?

Re: Show HN: Neural-hash-collider – Find target hash collisions for NeuralHash

#335

Post by Fnoord »

vermilingua wrote: post #310
Fnoord wrote: post #307

Earlier quoted context omitted.

To assume CP is reviewed manually is simply wrong. You don't want to put such weight on an individual. You want to automate it as much as possible, with as little false positives (and false negatives) as possible. For example, in case of a wallpaper, let's say its the Windows XP wallpaper. There's no human skin color in it at all, so you can easily be reasonably sure it isn't CP. You would not need an advanced ML for…

To assume it’s never reviewed manually is absolutely terrifying.

That is not what I asserted. I asserted that it is only done when other options are exhausted.

Re: Show HN: Neural-hash-collider – Find target hash collisions for NeuralHash

#336

Post by robertoandred »

silisili wrote: post #216
robertoandred wrote: post #38

Earlier quoted context omitted.

LEO is not alerted automatically, where’d you get that idea?

They'd more or less have to be. Well, not necessarily 'police', but NCMEC. I did work in automating abuse detection years back, and the US govt clearly tells you are not to open/confirm suspected, reported, or happened upon cp. There's a lot of other seemingly weird laws and rules around it.

Those laws don’t apply if it’s part of the reporting process. Apple’s stated that they do a manual to decide whether to send a report to NCMEC or not, just like other companies do.

Re: Show HN: Neural-hash-collider – Find target hash collisions for NeuralHash

#337

Post by simondotau »

Dylan16807 wrote: post #312
simondotau wrote: post #149

Earlier quoted context omitted.

Photos in the database are classified for their content. Only images classified as A1 (A: prepubescent minor, 1: sex act) are being included in the hash set on iOS. So this doesn't even include A2 (2: lascivious exhibition), B1 or B2 (B: pubescent minor) let alone images which are in the database and aren't classified as any of A1, A2, B1 or B2. While I've no doubt that there's a lot of "before and after" images (whi…

If someone is deliberately targeting you with them, 30 isn't very hard to reach.

I think it’s implausible that someone can become aware of 30 images which are miscategorised as A1 CSAM. How would this malicious entity discover them? What’s the likelihood that this random array of odd images could make it into a target‘s photo library?

And what’s the likelihood that a human reviewer will see these 30 odd images and press the “yep it’s CSAM” button?

More likely as soon as Apple’s human review sees these oddball images, they’re going to investigate, mark those hashes as invalid, then contact their upstream data supplier who will fix their data and now those implausible images are now useless.

Re: Show HN: Neural-hash-collider – Find target hash collisions for NeuralHash

#338

Post by sennight »

ThinBold wrote: post #330
sennight wrote: post #309

Earlier quoted context omitted.

> I don't get why 𝚜̶𝚘̶ ̶𝚖̶𝚊̶𝚗̶𝚢̶ some people think this is an ineffective idea. Because such architectural flaws become absolute train wrecks when scaled. Remember the Clipper Chip? This is like that: cryptographers pointing out fundamental flaws that may seem like minor issues to most of the users who were going to be compelled to use it - but at scale those flaws result in the direct opposite of the stated ob…

Unless Apple implements this with a backdoor on iCloud, the worst case scenario here is that they receive millions of false positives per day and terminate the program after two weeks. The scalability issue seems to work in our favor because, perhaps, the normal usage will overwhelm the human reviewers Apple prepared and we don't even need to send troll images. And for the entire time, our data remains untouched.

So Apple customers go from paying for a status symbol luxury item to paying for the privilege of participating in this, at best, pointless exercise wherein they rely upon the goodwill and competence of Apple's employees to not get them swatted. The mental gymnastics needed in order to guard one's ego on this issue can't be healthy either.

Re: Show HN: Neural-hash-collider – Find target hash collisions for NeuralHash

#339

Post by seph-reed »

nseggs wrote: post #126
seph-reed wrote: post #96

Earlier quoted context omitted.

I would gladly have a mobile phone full of memes that have been modified to match, just for the lulz. I honestly think every meme should be put through just to have "illegal memes"

Illegal memes. Finally. Illegal Pepe will be the crowning jewel of my rare Pepe collection.

Holy cow. An Illegal Pepe is just too good not to have.

Re: Show HN: Neural-hash-collider – Find target hash collisions for NeuralHash

#340

Post by sigmar »

fay59 wrote: post #185
sigmar wrote: post #151

Earlier quoted context omitted.

What happens if someone leaks or guesses the weights on that "secret" classifier? The whole system is so ridiculous even before considering the amount of shenanigans the FBI could pull by putting in non-CSAM hashes.

For better or worse, opaque server-side CSAM models are the norm in the cloud photo hosting world. I imagine that the consequences would be roughly the same as if Google's, Facebook's or Microsoft's "secret classifiers" were leaked.

but in the cloud setting they have the plaintext of what was uploaded. The attack described above is about abusing the lack of information apple has so they will report an innocent user to the authorities.
Post reply on HN