A parachuting flamingo? An aardvark driving a bus? It should be easy to randomize the animal and the mode of transport (or vary it with animal playing a sport) to create images not in the training data.
> I feel like the pelican test can't be relevant anymore;
It never was. The point of this "pelican test" was for performative reasons, or just for attention of the joke.
It is like trying to test whether if an adult elephant could actually climb up a tree and reporting that some elephants are slightly better at doing that than others while also reporting at the same time that they are all bad at tree climbing anyway.
This is an example of testing for the sake of testing. The "pelican test" tests for nothing.
What about an armadillo playing a piano? There are so many potential combinations
It would say something if the pelican looked great but the armadillo looked terrible
I feel like this is with 2026 view where browsers are so mutually compatible.
In the bad old days there were so many differences between html, css and js behaviors that if you wanted your site to be nice you had to change it for the browser. The way css padding worked wasn't even the same. Feature detection was rarely viable for any of this.
No user agent would probably have only entrenched IE6 dominance even more by blocking you from deliberately making a site that works at all on other browsers (including IE7 for that matter)
I'm aware of that history and the User-Agent header was a mistake even back then. It took the pressure off of browser vendors and gave them an excuse to not fix their bugs.
road to hell is paved with good intentions. one could argue it would've made browser vendors fix their bugs, but with the side-effect that any behavior that isn't bug-compatible with IE becomes a bug. this would've ironically entrenched IE permanently.
The mistake was not claiming features rather browser client versions...
JS devs were kinda able to patch around the nonsense because they were able to feature-detect - part of the reason this stuck around was because no legitimate user or dev cared (or should care). But the header was mostly (useless) noise, and the people spoofing were dealing with the couple bad apples of the time.
Of course, defining features is easier said than done, and a standards body is a challenging environment to define these in...
I get why people are fingerprinting bots and others are working around it, but neither are "legitimate" applications - if your content is public, it's public, end of story. And working around these controls to sell botnet access to sites is equally illegitimate - nobody has a right to resell content they do not own...
I just can't see how it could make sense to define features when a ton of the the behavior wasn't even intentional but just tons of bugs. I recall debugging issues that only reproduced in "IE7 compatibility mode of IE8" which didn't reproduce in either IE7 or IE8. And that was already after the standards were taken at all seriously
> I feel like this is with 2026 view where browsers are so mutually compatible.
I wish this was the case. Unfortunately, companies that work on non-Chromium browsers need to employ dedicated web compatibility teams to either a) help website users fix non-standard (i.e. Chrome only) HTML/CSS/JS, or b) replicate Chromium-like behaviour for specific (very popular) websites so that they work "correctly".
There's also the websites that deliberately block certain browsers which is what tools like "chrome-mask"[1] are built to solve.
And you can see how well that worked by how many user-agents are such a sane, terse description of the browser rather than a hodgepodge of random words that give the impression that they're trying to seem like every browser at once.
Sure that part is a specific problem which is that new browsers basically want to declare their hacks profile against people who have already written sites and won't update them.
In practice when you make your new set of hacks the string you can always evaluate whatever cruft in the useragent today, but next browser shows up.
It does make the user agents insane but I don't know if there's any obviously better system for the problem, even with hindsight
GoGo was not a completely separate implementation but deeply hooked into the official GoProto implementation. So it wasn't "Protobuf the binary wire format" or "Protobuf the schema language" which changed over time here, changes to the Google's Go library caused it problems. It's like building a library that integrates with Jackson (a JSON library) and Jackson details changed in ways that added toil, versus JSON changing.
Engineer who works on Google Protobuf here, commenting as myself and not as an official statement.
It's great to have a healthy ecosystem in the world around Protobuf. Google can't possibly fill all use cases, there's many tools and Buf makes good tooling. The Protobuf team at Google intentionally tries to enable an ecosystem around Protobuf including examples like this. Google Cloud APIs are intentionally usable with any compatible thing that can understand Protobuf encoding including this one.
Kudos to Buf for making something that I'm sure a ton of people will find useful and which takes conformance so seriously.
Just to chime in with some context about Google's own implementations here though (since that's a lot of the discussion otherwise).
Google definitely takes Protobuf seriously including for the long term: you can't really understand how engrained it is within the Google stack without seeing it for yourself. It's not just RPC layer, it's storage, logging, FFI. Html templating is driven off Protobuf messages. Systems which interact with bank XML based systems uses Protobuf schemas. Internally it's widely used for in-memory library api types even without any direct/obvious connection to serialization just because it makes internal details like logging easier. This extremely large surface does create constraints and use-cases to balance. You can see Buf's reported numbers reflect that it is faster for a usecase they expect is typical, but at scale users do fall into the other buckets shown, affecting the performance of preexisting code is a major concern for our implementations that a greenfield implementation doesn't have.
Wide exposure in critical paths alongside long term support directly causes some quirks: for example some of our APIs followed PEP8 when it was created but PEP8 changed. It looks stupid that we have wrong style APIs but also it would be stupider to break compatibility for style reasons. JavaProto as another example still supports Java8 and the runtime is compatible with 2014 gencode which is a pretty major constraint.
Google Py Proto implementation has one extra interesting choice of the same gencode is reused with 3 different implementations (upb, a complete pure python one, and one that uses C++Proto as the in memory representation which libraries like TensorFlow can use to share memory between Python and C++), which is why design the way that it is with runtime created classes, the pyi files are readable but the .py files not.
This definitely has pros and cons, and the direct approach taken by Buf here really makes a ton of sense. It's just that Google's maintained implementation falls into a different spot in a larger technical tradeoff space.
If you see things that appear to make no sense with the official implementations, feel free to file an issue on GitHub and we can look, sometimes there is no reason and we can fix it, and sometimes there's a reason which we can explain.
Kudos again to Buf here, I'm fully sure this will solve some set of real business needs better than Google's (but not because Google isn't maintaining our offerings too).
> ... that uses C++Proto as the in memory representation which libraries like TensorFlow can use to share memory between Python and C++
This is a valid explanation for the odd implementation of the Python protobuf library (the only convincing one I've heard). But, the last time I looked into it (just a couple of years ago), it didn't seem reasonably possible to make use of this.
I can't remember the exact issue I think maybe the C++ library would be statically linked into the Python C extension module, which made it virtually impossible to use it from your own C++ code. Or maybe the issue was just that there was no C++ version prebuilt on pypi (the default is the upb version).
Anyway, it seems a pity to go to such enormous lengths for one feature and then make it essentially unavailable.
Well, there's still two implementations even without getting into the quoted case. But yeah, narrowly about the C++Proto shared memory thing, unfortunately it's so hard to make this work for many different reasons that we don't even advertise support for this functionality at all. This is a bit in the weeds but inside Google we static link everything which makes is far easier to do it, and static linking is how we recommend you use C++Proto in general.
But its kind of a clear example of a surprisingly complicated technical space. The big picture is that it's actually not weird when a simpler thing which has less constraints can be better on some axes users when compared to a complicated thing that delivers on many advanced constraints.
If "readability of the .py gencode instead of the .pyi gencode" was the worst pain point (or pet peeve) here then I actually suspect Buf wouldn't have even bothered, it's just one of these that is easy to see and explain.
> This is a bit in the weeds but inside Google we static link everything which makes is far easier to do it, and static linking is how we recommend you use C++Proto in general.
Statically linking everything doesn't work in this case because each C extension module (i.e. each Python package with some native code in it) is, in effect, a shared library.
If you statically linked the C++ protobuf library into both the Python protobuf library and the Python tensorflow library then you'd end up with two copies of the library in the process (with two copies of globals/statics such as the protobuf global descriptor pool). That's not a problem in itself, but it wouldn't be possible to pass protobuf objects between them.
(In principle, you could perhaps statically link protobuf into the CPython executable, but I really don't think Google is doing that.)
The usual solution is the exact opposite to static linking: you have to build the C++ protobuf library as a shared library (libprotobuf.so) and then link to it from both of your C extension modules (i.e. from the other two shared libraries).
Following the tiny crumbs of evidence of how to do this for protobuf, it seems like that was previously how you would do it. But it's possibly not now? It seems like proto_api.h [1] has a way to get the global descriptor pool, possibly to work around needing a common shared library? But also now that header is deprecated anyway [2]? (I think this is roughly where I got to before when I gave up.)
> principle, you could perhaps statically link protobuf into the CPython executable, but I really don't think Google is doing that.)
Yes, we actually do exactly this (not just protobuf but generally all of the other C code with it for the given application). But there are other approaches that can work.
> But also now that header is deprecated anyway
It's deprecated exactly because the preferred/supported/default runtime is the upb based runtime. The odd gencode design is what made that transition possible as an implementation detail. So the deprecation is just the same topic here, that people successfully setting up the dynamic linking is not really realistic/viable unfortunately, and the effort for open source support is spent making the best behavior on the upb runtime which can't have that feature.
The regular proto-to-python feels fine to me. I quit Google a while ago and have still been using protobufs, and the main things that usually make teammates wary are: 1. No way to load .proto specs at runtime (there are GH issues about this) 2. No clear and easy way to use it with HTTP/1.1. Neither is specific to Python.
Both of these might sound silly if you're used to protobufs, cause you can build little helpers for both, but plenty of people have never used protos. They would shrug proto away if there weren't someone like me to attest that it won't get in the way. It seems like Google focused on gRPC, but the real prize for adoption would've been going after the simple HTTP+JSON use cases. Like an official protobuf Express middleware.
> No clear and easy way to use it with HTTP/1.1. Neither is specific to Python.
> It seems like Google focused on gRPC, but the real prize for adoption would've been going after the simple HTTP+JSON use cases. Like an official protobuf Express middleware.
We'd flag https://connectrpc.com for you :-) HTTP/1.1 out of the box, switches on Content-Type between binary and JSON, and fully-compatible with gRPC. cURL with JSON just works.
Can you spell out the ramifications for the plebs?
As far as I can tell home smart speakers are being used for warrantless mass surveillance, unlike Flock for example. Do you mean the possible future situation where they are?
I don’t quite understand how after twenty five years of the modern internet and every single consequent revelation about state surveillance you’re still at a point where you can look at a corporate-owned camera or microphone and say, “my priors suggest this isn’t being used for state surveillance and/or won’t be in the future, I’m gonna need evidence it is before I consider the consequences of that.”
Sorry, you're going to have to spell out the risk for me here. What other cases have we seen that indicate that mass surveillance via smart speakers is a risk?
We all also have phone in my pocket 24/7 and my laptop on my desk, both with microphones in them. In the event of the government doing warrantless spying on all devices it seems like that is a strictly higher ROI target for them?
No, you’re right, we have not seen a case specifically of state surveillance specifically using a smart speaker yet.
Re: phones - yes, they’re a strictly higher ROI target, which is why they’re regularly targeted by state-level adversaries, who also seem to enjoy using every other tool and opportunity available to them to surveil and collect data on whoever they’re considering this week’s bete noire, including both warranted data requests from phone manufacturers, service providers, and cell networks, buying data from commercial brokers when that doesn’t work, or just outright hacking whoever they’re interested in.
But no, you’re strictly correct that to the best of my knowledge we do not currently have specific evidence that state level adversaries have leveraged the notably piss-poor security standards and data protections on IOT equipment containing multiple microphones capable of collecting room-level audio and separating out that audio into individual actors to surveil persons of interest, so, no need to worry.
I'm not trying to agitate you here and won't keep looping on the same question after this reply: I just do not understand the threat model here, and you're still being oblique as though its obvious what the threat model by being sarcastic instead of just spelling it out in plain language.
Are you worried about some foreign state actor like Israel targeting you specifically, hacking your devices to listen to you chatting? Or you're worried about US warrantless mass surveillance wiretapping all citizen's smart speakers, and you're worried the US government may spin up such a program?
In the latter case, the scenario you expect will happen is we'll have ~100 million US households are live wiretapped 24/7 without anyone knowing, you'll be part of the remainder living your life blissfully wiretap-free thanks to not having a smart speaker?
I'm old enough to have used computers before having any Internet, and in 2026 the idea of plugging in devices to transfer files to it does feel like a fiddly relic of the past to me.
I believe the feature is that you have a pending unreleased video and go to an llm for tips. When getting the tips it uses the pending video content and your recent videos info as context. So there's no holding back unlisted info short of not letting the user use it for their upcoming videos at all
And then the attack is to trick this recommendation system into putting a link out
I actually the attack is very likely already soft defeated by an interstitial telling you that you are leaving the site though, it would be weird if they didn't do that in general from this surface
In 2026 things have changed, there's literally whatever tens of thousands of "security" reports that are almost all bogus as a raging crap river.
I think theres very little chance this particular report made it to any engineer who works on product at all, because if they did they would be completely overwhelmed by reports, the filter which has to handle the many thousands of reports based on a playbook almost definitely filtered it out before it made it that far.
There is literally any noise from the engine, whine or otherwise. Whether a noise is bad or not can be subjective but silence is objective.
So at least for that one it kind of draws into question your overall conclusions here. You might be hearing an ICE and thinking it is electric, or some specific badly tuned vehicle or something.
I am very certain I am talking about electrical and hybrid vehicles. The first one that had me aghast was a Nissan Leaf. Today, too many. Obviously I cannot confuse them with ICE ("brooom").
The point about the "whining possibly-engine" comes from a chat with a friend, where I said that they had decided to really use the most annoying overlapped noises to make the cars audible: he replied, those are not the additional noises, but the "noises from the engine" (probably from the whole system). I don't know.
> silence is objective
The electrical and hybrid vehicles I witnessed are very far from silent (save for the bicycles - I can't assess them, too little experience). As expressed, to us those noises - running noises and operational noises - are annoying to a whole new level.
Nissan Leaf motor is silent, there's really just objectively not a noise from the motor itself which could offend you.
There's still some possibilities here: maybe you came across someone with a broken car and believed that to be representative.
Most other explanations here just involve some form of confusion on your part to be honest: that it was the backup-alert noise that it makes _because_ the car is otherwise too silent, that it wasn't actually a Leaf but an ICE engine that you saw, or something else.
I insist. It cannot be about broken cars, because there would be a large number of them.
The Nissan Leaf cars I experienced are not silent at all - it does not matter if it is the motor or another part of the system, or if it is the additional noise that was mandated legally because they were deemed too silent. Similarly, its Peugeot "twin" is "whaaa" whining, and so are the hybrid Jeep Renegade, and many others (as I was writing another reply nearby a Lexus) that had me turn in the street and address the drivers with impatience.
Is it possible instead that you have no noise sensitivity for that noise? Or maybe - that makes no sense but - if I pointed you to that noise you would be surprised that some find that a foreground in perception? Because it is really bewildering that you call those cars silent - they are the opposite. A large number of electric or hybrid cars produce a whining "whaaa", a sort of synth chord, loud with a filter-pass in an abominably annoying band. I think I even heard one with a fake ICE noise (an imitation), but still a coloured timbre (not a natural noise but a synth with a perceptible note) in that same band.
And the explanations you mention really make no sense: the beeps of the backup-alert noise - which we all know were mandated because the vehicles were supposed to be too quiet - are intermittent, whereas the whine is continuous.
(The vehicles were supposed to be too quiet, so they mandated extra noises. Some of them are guessed to be nerve wracking - which is also normal in societies that have lost their natural sense.)
But look: it is absolutely impossible that I can confuse an electric car noise with that of an ICE - and it is out of question that you can allege that.
Maybe ask other people whether they hear noise from electric or low-speed hybrid cars. Really, ask other people.
Edit: at this point I thought I could sample one - but I am sure they could be found on YouTube etc., there should be no need. ... I checked: it's full of them samples.
reply