Does anybody have a sense of whether this is best seen as "a proposal by the UK House of Lords", or "a proposal by three fringe whackjobs in the UK House of Lords"? I honestly don't have any idea. How influential are the proposers? Who else has made noise about such things?
The amendment from the same three people about requiring all phones to "have installed tamper-proof system software which is highly effective at preventing the recording, transmitting (by any means, including livestreaming) and viewing of CSAM using that device" strikes me as in the fringe whackjob range.
> Yes, but doesn't IPv6 also increase the "maximum safe UDP packet size" from 512 bytes to 1280?
Sure would be nice if people used IPv6. Even if you're actually sending data over IPv6, that doesn't mean the DNS lookups are going over IPv6. Infrastructure like that lags.
> This has been a flagged issue in DNSSEC since it was originally considered. This was a massive oversight on their part and was only added because DNSSEC originally made it quite easy to probe entire DNS trees and expose obscured RRs.
... probably because the people who originally designed DNSSEC (and DNS) couldn't believe that people would be crazy enough to try to keep their DNS records secret (or run split address spaces, for that matter). But anyway, whatever the reason, the replies are big and that has to be dealt with.
> Fair enough but are network clients actually meant to use DNSSEC?
You should be validating as close to the point of use as possible.
> Isn't this just an issue for authoritative and recursive DNSSEC resolvers to and down the roots?
If by "resolvers" you mean "local resolution-only servers", then that's common, but arguably bad, practice.
Anyway, using TCP also neuters DNS as a DoS amplifier, at least if you can make it universal enough to avoid downgrade attacks.
> probably because the people who originally designed DNSSEC (and DNS) couldn't believe that people would be crazy enough to try to keep their DNS records secret
I wonder if it's time to just retire this mechanism. In 2025 you'd have to be crazy to not use encryption with an internet-facing host, which in practice usually means TLS, which means your hostname is already logged in Certificate Transparency logs and trivially enumerated.
> couldn't believe that people would be crazy enough to try to keep their DNS records secret
You'd hope people working on DNS would have had broader actual experience with it. There was an ironic lack of paranoia in the DNSSEC people and they seemed overly focused on one peculiar problem, which is, it's easy to spoof DNS responses when you typically only have at most 2**16 - 1024 ports to choose from. They sort of ignored everything else.
> If by "resolvers" you mean "local resolution-only servers", then that's common, but arguably bad, practice.
I haven't kept pace with DNSSEC, but originally, this was the _recommended_ configuration. Has that changed?
> Anyway, using TCP also neuters DNS as a DoS amplifier,
We're ensuring all servers support TCP, but we're not anywhere near dropping UDP.
They did recommend it at one point. But I don't think that makes it not-bad. It was long enough ago that they might have been worried about crypto performance; I don't know.
Both of them, still, in some places, although she may get more lenient treatment because she's a juvenile. Other places have cleaned that up in various ways, although I think he's usually still at risk unless he actively turns her in to the Authorities(TM) for sending the picture.
And there's a subset of crusaders (not all of them, admittedly) who will say, with a straight face, that there is abuse involved. To wit, she abused herself by creating and sending the image, and he abused her either by giving her the idea, or by looking at it.
Obviously, the laws were originally intended to protect children from malicious adults, but nowadays, when every child has a phone with a camera, they technically are one tap away from committing a crime even without realizing this. Maybe we should do surprise phone inspections at schools, or maybe we should restrict using camera app only to verified adults.
> There are some concerns that an individual perceptual hash can be reversed to a create legible image,
Yeah no. Those hashes aren't big enough to encode any real image, and definitely not an image that would actually be either "useful" to yer basic pedo, or recognizable as a particular person. Maybe they could produce something that a diffusion model could refine back into something resembling the original... if the model had already been trained on a ton of similar material.
> If Microsoft wanted to keep both the hash algorithm and even an XOR filter of the hash database proprietary
That algorithm leaked years ago. Third party code generates exactly the same hashes on the same input. There are open-literature publications on creating collisions (which can be totally innocent images). They have no actual secrets left.
They're not very good at all (it just uses a GAN over a recovered bitmask), but it's reasonable for Microsoft to worry that every bit in that hash might be useful. I wouldn't want to distribute all those hashes on a hunch they could never be be used to recover images. I don't think any such thing would be possible, but that's just a hunch.
That said, I can't speak on the latter claim without a source. My understanding is that PhotoDNA still has proprietary implementation details that aren't generally available.
> They're not very good at all (it just uses a GAN over a recovered bitmask),
I think you're making my point here.
The first one's examples take hashes of known headshots, and recover really badly distorted headshots, which even occasionally vaguely resemble the original ones... but not enough that you'd know they were supposed to be the same person. Presumably if they had a better network, they'd get things that looked more human, but there's no sign they'd look more like the originals.
And to do even that, the GAN had to be trained over a database of... headshots. They can construct even more distorted headshots that collide with corporate logos. If they'd used a GAN trained on corporate logos, they would presumably get a distorted corporate logo when they tried to "reverse" any hash. A lot of the information there is coming from the model, not the hash.
The second one seems to be almost entirely about collisions. And the collisions they find are in fact among images that don't much resemble one another.
In the end, a PhotoDNA hash is 144 bytes, made from apparently a 26 by 26 pixel grayscale version of the original image (so 676 bytes). The information just isn't there. You might be able to recover the poses, but that's no more the original image than some stick figures would be, probably less.
Here's [the best "direct inversion" I can find](https://anishathalye.com/inverting-photodna/). That's still using machine learning, and therefore injects some information from the model... but without being trained on a narrow class of source images, it does really badly. Note that the first two sets of images are cherry picked; only the last set is representative, and those are basically unrecognizable.
Here's [a paper](https://eprint.iacr.org/2021/1531.pdf) where they generate collisions (within reasonable values for the adjustable matching threshold) that look nothing like the original pictures.
> That said, I can't speak on the latter claim without a source. My understanding is that PhotoDNA still has proprietary implementation details that aren't generally available.
For original PhotoDNA, only for basically irrelevant reasons. First, actually publishing a complete reverse-engineering of it would be against many people's values. Values aside, even admitting to having one, let alone publishing it, would probably draw some kind of flak. At least some and probably dozens of people have filled in the small gaps in the public descriptions. Even though those are unpublished, I don't think the effort involved in doing it again is enough to qualify it as "secret" any more.
Indeed, it probably would've been published regardless of those issues, except that there's no strong incentive to do so. Explanations of the general approach are public for people who care about that. For people who actually want to compute hashes, there are (binary) copies of Microsoft's actual implementation floating around in the wild, and there are [Python](https://github.com/jankais3r/pyPhotoDNA) and [Java](https://github.com/jankais3r/jPhotoDNA) wrappers for embedding that implementation in other code.
There are competitors, from openly disclosed (PDQ) to apparently far less fully reverse engineered (NeuralHash), plus probably ones I don't know about... but I think PhotoDNA is still dominant in actual use.
[On edit: but I probably shouldn't have said "third party code", since the public stuff is wrapped around Microsoft's implementation. I haven't personally seen a fully independent implementation, although I have reason to be comfortable in believing they exist.]
That just encourages people to keep using old, unmaintained, insecure versions of libraries. Then, when they're still on version 2.1.1, and your maintained version is 5.7.3, and somebody finds a major security bug in 2.1, they will come whining at you to release a 2.1.2.
Code that is not being maintained is not usually suitable for use, period.
Library maintainers have no right to police how people use their open source code, period. Maintainers are also not obligated to backport security fixes. Anything else is effectively against the concept of open source.
Notably, even this policing doesn’t fix the whining. The whining will just be about what TFA is whining about. You’re just moving the whining around.
It also does nothing to actually force people to upgrade. Instead, people can just cap against the minor version you broke your package on. Instead of being user hostile, why not make the user’s job easier?
Correctly following SemVer disincentivizes unnecessary breaking changes. That’s a very good thing for users and ultimately the health of the package. If you don’t want to backport security fixes, users are free to pay, do it themselves, or stop using the library.
> I don't think we should normalise children on platforms where the content contains political agitation, sexual and violent content, crypto and fintech scams, etc.
You mean like the outside world?
What happens when these hot house flowers of yours reach whatever magic age and get dumped into all of that, still with no clue, but with more responsibilities and more to lose?
I haven't noticed a whole lot of governments, or even very many parents, worrying about doing much to actually prepare anybody for adulthood. It's always about protection, never about helping them become competent, independent human beings. Probably because protection is set-and-forget, or at least they think it is... whereas preparation requires actually spending time, and paying attention, and thinking, and communicating. Maybe even having to answer hard questions about your own ideas.
... and since when are kids supposed to be protected from politics? We used to call that "civics class".
If your children are being exposed to sexual and violent content in the real world, that is called an "Adverse Childhood Experience" and it is predictive of everything from poor adult earnings to heart disease: https://www.cdc.gov/aces/about/index.html
> and since when are kids supposed to be protected from politics? We used to call that "civics class".
The whole "don't talk about politics" is so toxic IMHO.
Sure you might not want to ruin your dinner with the family members you see a single day every year. But otherwise, making it sound like a taboo could be widening the tribalization and anchor the feeling deeper into people's identity. Let the people talk about what they care about, including when that affects who the next president is.
On the one hand, you have violence and pornography, and also other crude content. There is nothing good about exposing children to these. It does not contribute to their growth or to their maturity as human beings and it is ridiculous to think it could. On the contrary, this content will cause psychological harm, causing distortions in their emotions, in their habituated appetites, in their self-understanding, and their understanding of normal relations. When deviance like that is tolerated, it shifts the Overton window. Children observe this tolerance and roll it into their sense of normality. Individuals suffer. The quality of society degrades substantially.
On the other hand, we have political agitation. This one is more difficult to define and handle, especially in a liberal democratic society. There are examples of obvious political agitation, of course, but children should generally not be exposed to political agitation at all, except as a subject matter at an age appropriate level and in an appropriate pedagogic setting. Children don't have the intellectual or emotional maturity to examine such material in the wild on their own where they would be at the mercy of unscrupulous adult manipulators who couldn't care less about the well-being of children. (Ask yourself what kind of person would want to involve children in their political agitation to begin with.)
So, there's a big difference between common sense things like these and coddling children. We want to prepare children for life, not teach them adaptation to depravity. You throw them into the filth of social and psychological pathology. Neither violence nor pornography should be normalized even in the adult world - it is harmful to the adults who consume it as well - so the idea that we should prepare children for life in some violent and twisted pornland is preposterous. Nobody has to put up with that garbage, and the law should be making sure they don't.
> If you have a new warning on upgrade you probably want to work on it "next week", but that means you need to ignore it for a bit.
So you create a bug report or an issue or a story or whatever you happen to call it, and you make sure it gets tracked, and you schedule it with the rest of your work. That's not the same thing as "ignoring" it.
Why does your codebase generate hundreds of warnings, given that every time one initially appeared, you should have stamped it out (or specifically marked that one warning to be ignored)? Start with one line of code that doesn't generate a warning. Add a second line of code that doesn't generate a warning...
> Why does your codebase generate hundreds of warnings
Well, it wasn't my codebase yesterday, because I didn't work here.
Today I do. When I build, I get reports of "pkg_resources is deprecated as an API" and "Tesla T4 does not support bfloat16 compilation natively" and "warning: skip creation of /usr/share/man/man1/open.1.gz because associated file /usr/share/man/man1/xdg-open.1.gz (of link group open) doesn't exist" and "datetime.utcnow() is deprecated and scheduled for removal in a future version"
The person onboarding me tells me those warnings are because of "dependencies" and that I should ignore them.
It's rare that I work on a project I myself started. If I start working on an existing codebase, the warnings might be there already. Then what do I do?
I'm also referring to all the warnings you might get if you use an existing library. If the requirements entail that I use this library, should I just silence them all?
But I'm guessing you might be talking about more specific warnings. Yes I do fix lints specific to my new code before I commit it, but a lot of warnings might still be logged at runtime, and I may have no control over them.
If this code crashed all the time there'd be a business need to fix it and I could justify spending time on this.
But that's not what we're discussing here, we're discussing warnings that have been ignored in the past, and all of a sudden I'm supposed to take the political risk to fix them all somehow, even though there's no new crash, no new information.
I don't know how much freedom you have at your job; but I definitely can't just go to my manager and say: "I'm spending the next few weeks working on warnings nobody else cared about but that for some reason I care about".
Because most people are working at Failure/Feature factories where they might work on something and at last minute, they find out something is now warning. If they work on fixing it, the PM will screaming about time slippage and be like "I want you to work on X, not Y which can wait".
You found that out at the last minute. So then you did a release. It's no longer the last minute. Now what's your excuse for the next release?
If your management won't resource your project to the point where you can assure that the software is correct, you might want to see if you can find the free time to look for another job. You'll have to do that anyway when they either tank the company, or lay you off next time they feel they need to cut more costs.
> Fixing deprecations is unfortunately the lowest prio of any kind of work for majority of the projects.
... and the right answer to that is to make it entirely their problem.
> Part of the problem is probably lack of pressure to do so it if the timeline is unclear. What if this is actually never removed?
In this case, the warnings said exactly what release would remove the API. Didn't help.
> Why going through the pain?
Because you're not a feckless irresponsible idiot? I don't think it's an accident that the projects they said didn't react were an overcomplicated and ill-designed management layer for an overcomplicated and ill-designed container system, a move-fast-and-break-things techbro company, and what looks to be a consolation project for the not-too-bright.
You probably get an extra measure of that if you're operating in the Python ecosystem, which is culturally all about half-assed, 80-percent-right-we-hope approaches.
The right answer is to remove it when you say you're going to remove it, and let them pick up the pieces.
It also helps if you design your API right to begin with, of course. But this is Python we're talking about again.
The amendment from the same three people about requiring all phones to "have installed tamper-proof system software which is highly effective at preventing the recording, transmitting (by any means, including livestreaming) and viewing of CSAM using that device" strikes me as in the fringe whackjob range.
reply