I’ve been adding global listeners for click and keydown that call handleFoo(event) if event.target has a data-foo attribute.
The Invoker API seems like a neater way of handling the same pattern but I’m biased towards global event listeners because they work automatically on newly injected markup and they scale O(functionality) as opposed to per element listeners that scale O(elements). I’ll be the first to admit that the latter is more of an aesthetic choice rather than being based on any kind of performance statistics.
Giving children handheld access to global cable TV — every single channel in existence no matter how… niche — must be one of the most reckless things a parent can do. My parents* used to screen my technology magazine subscriptions and cut out the pages on weapons!
In an alternate universe we would be leaning on OS providers to give us child friendly installations that hook into content scanners and white/black lists. Handing the scanning and blocking keys over to the government feels as reckless as letting kids roam free on the net.
Does Debian have a rule that forbids (or a taboo that proscribes) contributors passing off other people’s work as their own? I could believe that such a rule is implied rather than written down. The GR could be about writing it down, and it would surely cover the case of code that came directly from a model. Even if we don’t consider a
model to be another person it is certainly not the contributor’s own work.
(If anything, the copyright to model-generated code cannot possibly be said to belong to the human contributor. They… didn’t write it! I’m glad to see that aspect was discussed though I’m surprised it wasn’t the main thrust.)
> Does Debian have a rule that forbids (or a taboo that proscribes) contributors passing off other people’s work as their own? I could believe that such a rule is implied rather than written down.
It’s implied because it’s illegal (infringes on the original author’s rights). Of course, LLMs aren’t people.
That doctrine works great for defending your homeland, when you are taking off from your roadside base and coming back home to a road-based airfield already on the map.
My understanding of these VTOL aircraft is they need to travel a long way, quickly, and set down in far less predictable conditions.
I have often heard that vote rigging is detectable on HN because the site software penalizes voting from accounts at the same IP address.
Rumor had it that there is also some kind of social-network metric detecting when socially adjacent accounts (or alts) are engaged in astroturfing, the practice where a small cabal tries to pass themselves off as a broader grassroots campaign.
Flip that around though and the same metrics might allow new accounts to be meaningfully vouched for by existing ones.
Realistically, there’s a third option which it would be glib to not consider: you lose your job, get hired somewhere else, and screw up in some novel and highly avoidable way because deep down you aren’t as diligent or detail-oriented as you think you are.
I don’t really understand how we are supposed to believe in e2ee in closed proprietary apps. Even if some trusted auditor confirms they have plumbed in libsignal correctly, we have no way of knowing that their rendering code is free of content scanning hooks.
We know the technology exists. Apple had it all polished and ready to go for image scanning. I suppose the only thing in which we can place our faith is that it would be such an enormous scandal to be caught in the act that WhatsApp et al daren’t even try it.
(There is something to be said for e2ee: it protects you against an attack on Meta’s servers. Anyone who gets a shell will have nothing more than random data. Anyone who finds a hard drive in the data centre dumpster will have nothing more than a paperweight.)
The unfortunate fact about E2EE messaging is that it is hard to do. Even if you do have reproducible builds, the user is likely to make some critical mistake. What proportion of, say, Signal users actually compare any "safety numbers" for example? There is no reason to worry about software integrity if the system is already insecure due to poor usability.
Sure, we should all be doing PGP on Tails with verified key fingerprints. But how many people can actually do that?
Same, my default MO is assuming 'e2ee' is broken and unsafe by default. Anything that I truly don't want sent over the wire would be in person, in the dark, in a root cellar, underwater. Not that I've ever been in the position to relay juicy info like that. Hyperbole I know, but my trust begins at zero.
There are good reasons to not trust signal. The very first line of their privacy & terms page says "Signal is designed to never collect or store any sensitive information" but then they started collecting and permanently storing sensitive user data in the cloud and never updated that page. Much more recently they started collected and storing message content in the cloud for some users, but they still refuse to update that page. I'm pretty sure it's big fat dead canary warning users away from Signal. Any service that markets itself to whistleblowers and activists then also outright lies to them about the risks they take when using it can't be trusted for anything.
With e2ee please remember that it is important to define who are the ends.
Perhaps your e2ee is only securing your data in travel if their servers are considered the other end.
Also one thing people seem to misunderstand is that for most applications the conversation itself is not very interesting, the metadata (who to who, when, how many messages etc.) is 100x more valuable.
Hah, yes I switched over as soon as they started showing the scenes behind the scenes behind the scenes.
I worked on the set of an electric shaver commercial once. I’m wouldn’t say out loud that the production team were up themselves, but in addition to the regular crew there was a second director on set making a “making of” documentary about the production process. For a shaver commercial.
The Invoker API seems like a neater way of handling the same pattern but I’m biased towards global event listeners because they work automatically on newly injected markup and they scale O(functionality) as opposed to per element listeners that scale O(elements). I’ll be the first to admit that the latter is more of an aesthetic choice rather than being based on any kind of performance statistics.
reply