Security Threat Model Review of the Apple Child Safety Features [pdf]
1–10 of 393 posts
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#2My immediate thought is that this could still be poisoned by Five Eyes participants, and that it does not preclude state actors forcing Apple to replicate this functionality for other purposes (which would leave the integrity of the CSAM database alone, thus not triggering the tripwire).
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#3FWIW, I actually did an amateur threat model analysis in a comment in separate HN thread. I always thought this was called for because the initial document set was just the mathematics, not the people/process/implementation/policy risks and threat model that was the source of widespread concerns.
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#4Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#5It’s pretty lonely over here in technical discussion land. Have we considered Reuters’s intern’s take on this?
https://news.ycombinator.com/newsguidelines.html
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#6It’s pretty lonely over here in technical discussion land. Have we considered Reuters’s intern’s take on this?
Please don't post unsubstantive comments yourself. If other threads/comments aren't good, options include posting something better, or not posting. Degrading things even further is not a good choice (edit: particularly when the thread is new—threads are extremely sensitive to initial conditions, and a flamebait/unsubstantive comment early on can have a strongly degrading effect). https://news.ycombinator.com/newsguid…
I have seen many on here.
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#7Earlier quoted context omitted.
Please don't post unsubstantive comments yourself. If other threads/comments aren't good, options include posting something better, or not posting. Degrading things even further is not a good choice (edit: particularly when the thread is new—threads are extremely sensitive to initial conditions, and a flamebait/unsubstantive comment early on can have a strongly degrading effect). https://news.ycombinator.com/newsguid…
Sincere question: why doesn’t this policy apply to the innumerable number of hot takes which are variations on the exact same, often misinformed, reaction? I’m thinking of comments like, “Apple will send me to prison for taking bath tub pics of my infant!” I have seen many on here.
Second, there are degrees of these things. It's definitely bad for comments to repeat the same shallow things over and over, but the GP was particularly information-free and snarky, and mucking up this thread while claiming to be speaking in favor of technical discussion is particularly counterproductive.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#8Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#9Could someone tell me how that inspection works? Are there researchers who are given the source code?
(I posted this on another thread [0] earlier, but it's more relevant here) [0]: https://news.ycombinator.com/item?id=28175619
Re: Security Threat Model Review of the Apple Child Safety Features [pdf]
#10Their use of the phrase "This claim is subject to code inspection by security researchers like all other iOS device-side security claims" stood out to me. Could someone tell me how that inspection works? Are there researchers who are given the source code? (I posted this on another thread [0] earlier, but it's more relevant here) [0]: https://news.ycombinator.com/item?id=28175619
For example, as soon as an OS update is released, people will take it apart.
Having source might be nice but it’s not necessary.