101–110 of 184 posts
As other has pointed out, this is extremely creepy. The easiest solution would have been this one: - The user uses a JS solution to hash the images on the client, without the image being uploaded - She compiles a form with additional information (e.g: capture her account, reasons for uploading, suspect person sharing the picture) - The picture is saved in the DB as un-verified revenge porn. - The first time someone u…
Earlier quoted context omitted.
> I can imagine images of people that aren't "non-consensual intimate images" that they'd reasonably still like to be able to block being posted. If I take a photo of a public landscape and you happen to be there, do you have the right to prevent me from publishing it unaltered? Keep in mind: you're not the primary subject (and no reasonable person would believe that you were) nor owner of the photo. Your likeness is…
Excellent! Then it should be short work for you to photoshop my face out so it won't be blocked. Everybody wins.
Earlier quoted context omitted.
Yeah I'm curious how their hashing mechanism works. Like, is it a straight up sha hash of the image or something a little more sophisticated that wouldn't be fooled by minor edits? Though in the latter case can that even technically be considered hashing? I guess it all depends on how they're doing it which brings us back to my first question...
It is called PhotoDNA and was developed by Microsoft. This is the same tech that is used to find child porn images even when people go to various lengths to prevent simple hashing from being able to determine photo similarity. It works surprisingly well at the task from what I have seen/heard.
Earlier quoted context omitted.
Honestly, I doubt that most of these sorts of algorithms would survive concerted attacks – that's why they tend to be closely guarded. Alex Stamos (Facebook's CISO) implies this is why they can't do it client-side: https://twitter.com/alexstamos/status/928646228472078336
From when security through obscurity is a good idea?
snark-mode off: We use obscurity every day and its a completely valid layer of security.
Earlier quoted context omitted.
Excellent! Then it should be short work for you to photoshop my face out so it won't be blocked. Everybody wins.
Why is Facebook obligated to fulfill your desires for privacy by censoring content you have no legal claim to?
Does a rhinocerous have a right to be forgotten?
https://www.reddit.com/r/dredmorbius/comments/25ll1v/does_a_...
The better solution is to have the image hashed and NOT sent to facebook. If the hash matches an existing image [A]. If the hash isn't found [B]. [A]: human can review the image they already have [B]: Facebook waits until someone uploads an image that matches and then reviews the image (as normal) but with a marker alerting the problem. The benefit is that people NOT affected won't have to upload lots of images of th…
Kind of weird that they didn't do things this way as they supposedly already use hashing to flag child porn cf. http://www.wired.co.uk/article/iwf-hash-lists-child-abuse-im...
Earlier quoted context omitted.
PhotoDNA would be an option, I imagine. Or at least something similar! https://en.wikipedia.org/wiki/PhotoDNA
Honestly, I doubt that most of these sorts of algorithms would survive concerted attacks – that's why they tend to be closely guarded. Alex Stamos (Facebook's CISO) implies this is why they can't do it client-side: https://twitter.com/alexstamos/status/928646228472078336
Whoever designed this system is probably heavy on security, but low on product.
As other has pointed out, this is extremely creepy. The easiest solution would have been this one: - The user uses a JS solution to hash the images on the client, without the image being uploaded - She compiles a form with additional information (e.g: capture her account, reasons for uploading, suspect person sharing the picture) - The picture is saved in the DB as un-verified revenge porn. - The first time someone u…
Now figure out a way to do step #1 (user does a hash client-side) without making it trivial for someone else to create a filter that adds enough noise to invalidate step #4 (uploaded pics that match a hash are quarantined.)
The better solution is to have the image hashed and NOT sent to facebook. If the hash matches an existing image [A]. If the hash isn't found [B]. [A]: human can review the image they already have [B]: Facebook waits until someone uploads an image that matches and then reviews the image (as normal) but with a marker alerting the problem. The benefit is that people NOT affected won't have to upload lots of images of th…
The obvious reason why Facebook didn't go down this path is one of scale - It's easy (and altogether likely) for an attacker to pollute the hashes with innocuous pictures. But, even more importantly, once you reveal your hashing system, it's relatively trivial for people to work around them and modify the pictures in such a way as to render the hashing system useless. Has to be done server side for these reasons.
They can easily scale this by allowing hash uploads, using a trivial client side classifier to guess at whether an image is actually served well by this technology, and confirm positives with CV after a bad actor reposts their media on the site, with human intervention only on the fringes.