The xz hack was still reproducible, because it was included in the distribution archive which did not match the upstream source -- even then, it was so obfuscated it likely would have gone unnoticed, but nevertheless it only lived in the uploaded tarball and not in the repo. Reproducibility is a good thing, but the next step is build provenance.
Still, lots of good non-security benefits to reproducible builds too.
The xz utils compromise is a very good example... of why reproducible packages doesn't actually solve anything security-wise!
The backdoor relied first on a difference between building a package in a packaging environment versus building the package on your own. And also, it relied on the very common practice of checking in unreviewable artifacts into the source tree (e.g., the configure script, malicious binary test artifacts).
Reproducible builds guarantee that two people can follow the same instructions and get the same, bit-identical outcome. It does nothing to guarantee that those instructions have not been compromised, and all of the great packaging security failures of my lifetime that I can think of have relied on those instructions being compromised (e.g., xz utils, Debian OpenSSL keygen issues).
An attack would be far easier without reproducible packages. One could upload a compromised binary to debian by becoming a debian developer, blackmail a debian developer to so, or compromise the computer of a debian developer or the distribution.
At the time of xz attack, the package was already reproducible.
I'll give an analogy to email and spam. A lot of effort has been spent making sure that if an email is from [email protected], it actually came from [email protected], giving us things like SPF, DKIM, and DMARC. And it turns out that the most eager adopters of the newest technology are... the spammers themselves! Because they don't need to lie about their email address; they can have that be completely honest, and instead resort to other tricks to mislead users as to who they are (e.g., the display name, which most email clients blindly trust and happily display).
Similarly for package managers, the biggest issues are typo-squatting or maintainer credentials compromise. And in neither case does the attacker have any incentive to take advantage of it in a way that breaks reproducibility--they can be completely honest about what they're doing. Now even if I were an attacker who had compromised a maintainer's machine, I'd still probably go for compromising the source rather than compromising the final artifact-generation process... simply because compromising the source makes the exploit live longer.
As xz shows, once you have a compromised maintainer, there's basically nothing you can do to fix it except by having someone else discover the compromise and locking out the maintainer.
Typo-squatting attacks are more of an issue for non-curated software collections, not so much for Debian. If you use npm or cargo or similar, then you have indeed far bigger worries. Compromising the source has the disadvantage for the attacker that it much easier to detect. Again, if you always install the newest things from an non-curated collection that may not matter much, but for something such as Debian, this increases the probability of detection a lot. One can argue that xz shows that it is possible to hide things in the source, but it also shows how much effort was needed to do this. (and the xz package was reproducible, so compromising the debian system and uploading a binary would have a high risk of detection. That this was not done can therefor not serve as evidence that binary attacks are not an issue. )
What I'm wondering is if this requires sending the full list of extensions straight to a server (as opposed to a more privacy-protecting approach like generating some type of hash clientside)?
Based on their privacy policy, it looks like Sift (major anti-fraud vendor) collects only "number of plugins" and "plugins hash". No one can accuse them of collecting the plugins for some dual-use purpose beyond fingerprinting, but LinkedIn has opened themselves up to this based on the specific implementation details described.
The SOP of this entire industry is "Include this javascript link in your tag manager of choice", and it will run whatever javascript it can to collect whatever they want to collect. You then integrate in the back end to investigate the signals they sell you. America has no GDPR or similar law, so your "privacy" never enters the picture. They do not even think about it.
This includes things like the motion of your mouse pointer, typing events including dwell times, fingerprints. If our providers are scanning the list of extensions you have installed, they aren't sharing that with us. That seems overkill IMO for what they are selling, but their business is spyware so...
On the backend, we generally get the results and some signals. We do not get the massive pack of data they have collected on you. That is the tracking company's prime asset. They sell you conclusions using that data, though most sell you vague signals and you get to make your own conclusions.
Frankly, most of these providers work extremely well.
Sometimes, one of our tracking vendors gets default blackholed by Firefox's anti-tracking policy. I don't know how they manage to "Fix" that but sometimes they do.
Again, to make that clear, I don't care what you think Firefox's incentives are, they objectively are doing things that reduce how tracked you are, and making it harder for these companies to operate and sell their services. Use Firefox.
In terms of "Is there a way to do this while preserving privacy?", it requires very strict regulation about who is allowed to collect what. Lots of data should be collected and forwarded to the payment network, who would have sole legal right to collect and use such data, and would be strictly regulated in how they can use such data, and the way payment networks handle fraud might change. That's the only way to maintain strong credit card fraud prevention in ecommerce, privacy, status quo of use for customers, and generally easy to use ecommerce. It would have the added benefit of essentially banning Google's tracking. It would ban "Fraud prevention as a service" though, except as sold by payment networks.
Mandating that tracking for anti-fraud be vertically integrated with the payment network seems unnecessary. Surely the law could instead mandate the acceptable uses of such data? The issue at present appears to be the lack of regulation, not scofflaws.
I'm not convinced tracking is the only or even a very good way to go about this though. Mandating chip use would largely solve the issue as it currently stands (at least AFAIK). The card provider doing 2FA on their end prior to payment approval seems like it works just as well in practice.
At this point my expectation is that I have to do 2FA when first adding a new card to a platform. I'm not clear why they should need to track me at that point.
I think the point is that some of the extra words OP is complaining about aren't needless. It's on the writer to know their audience, but it's also asking a lot to tune a message in a PR review to the one particular person who demands bluntness, especially if they don't know that person well. If the majority of people in the organization respond positively to a certain style (which may involve some amount of phatic speech), then the person who is "over-writing" here is probably making a good decision.
Once I build rapport with someone, I tend to be more blunt, but still balance that with the fact that other people may be reading the interaction, and I don't want to model a rude communication style.
An organization can choose to promote a very direct approach to feedback (Bridgewater is famous for this), but it requires top-down work to get everyone on the same page, not just expecting one developer to mind-read another.
Nobody is advocating for a rude communication style; the disagreement is over what constitutes rudeness.
Some people/cultures see being blunt or to the point as rude.
Others see beating around the bush, wasting time and hogging the listener's brain space with fill material that serves no purpose other than delaying the actual closure/completion of the thought (including insisting on various rituals, either verbal or, in some cases, physical, such as drinking a cup of tea (or coffee) and not broaching the actual subject until both parties have finished drinking), or perhaps (though I suspect this is less common as an actual motivation than generally supposed) taking pains to respect the imagined feeling of the listener, and possibly most importantly, to reaffirm the social hierarchy, as rude.
It seems like the goal of the default configuration is preventing script injection while being otherwise very permissive. Basically, "safer than innerHTML, even when used very lazily". But I would expect guidance to evolve saying that it almost never makes sense to use the default and instead to specify a configuration that makes contextual sense for a given field.
The default might be suitable for something like an internal blog where you want to allow people to sometimes go crazy with `<style>` tags etc, just not inject scripts, but I would expect it to almost always make sense to define a specific allowed tag and attribute list, as is usually done with the userland predecessors to this API.
> being the type of slurry that pre-AI was easily avoided by staying off of LinkedIn
This is why I'm rarely fully confident when judging whether or not something was written by AI. The "It's not this. It's that" pattern is not an emergent property of LLM writing, it's straight from the training data.
I don't agree. I have two theories about these overused patterns, because they're way over represented
One, they're rhetorical devices popular in oral speech, and are being picked up from transcripts and commercial sources eg, television ads or political talking head shows.
Two, they're popular with reviewers while models are going through post training. Either because they help paper over logical gaps, or provide a stylistic gloss which feels professional in small doses.
There is no way these patterns are in normal written English in the training corpus in the same proportion as they're being output.
> Two, they're popular with reviewers while models are going through post training. Either because they help paper over logical gaps, or provide a stylistic gloss which feels professional in small doses.
I think this is it. It sounds incredibly confident. It will make reviewers much more likely to accept it as "correct" or "intelligent", because they're primed to believe it, and makes them less likely to question it.
Its prevalence in contexts that aren't "LinkedIn here's what I learnt about B2B sales"-peddling are an emergent property of LLM writing. Like, 99% of articles wouldn't have a single usage of it pre-LLMs. This article has like 6 of them.
And even if you remove all of them, it's still clearly AI.
People have hated the LinkedIn-guru style since years before AI slop became mainstream. Which is why the only people who used it were.. those LinkedIn gurus. Yet now it's suddenly everywhere. No one wrote articles on topics like malware in this style.
What's so revolting about it is that it just sounds like main character syndrome turned up to 11.
> This wasn’t an isolated case. It was a campaign.
It's mystifying. A relative showed me a heavily AI-generated video claiming a Tesla wheelchair was coming (self-driving of course, with a sub-$800 price tag). I tried to Google it to quickly debunk and got an AI Overview confidently stating it was a real thing. The source it linked to: that same YouTube video!
The Tacoma is gussied up and not Spartan/repairable as the Hilux. I guess it’s more comparable to the current ranger than the hilux is, I wonder if ford makes a stripped down ranger for the developing world? Are there any Ranger Jeepneys? Maybe the T6? https://en.wikipedia.org/wiki/Ford_Ranger_(T6)
Oddly enough, it says this was developed in Australia but might be the ranger selling in the USA/Europe now (the same one we are talking about). But the P703 is the model (a T6 variant) sold internationally now. It doesn’t surprise me that the current ranger was designed abroad. What I really don’t get is that ford doesn’t make cars in Australia anymore but they still design them there?
All Rangers are T6-platform Rangers now. It was designed well before the factories closed in Australia, but global automakers have been steadily consolidating to global-platform cars since the 1990s. The locality of the design doesn't matter as much when it'll be used across the world. It makes the most sense to design them where there is good design talent, and build them where it is economical to build them.
> At no point have the hilux and Tacoma shared any parts. Not engines, transmissions, frames, breaks, axles, wiring or anything interior.
They are on different platforms and are significantly different vehicles but they absolutely have shared parts. There are no bespoke cars built anymore, it is no longer viable to build a mass produced car without using some parts off the shelf.
For example, both vehicles have used: 2TR-FE engine, RC60F manual transmission, AC60F automatic transmission, etc.
Thank you, that makes sense. But in that case it doesn't do much for the op's argument, which seems to be that Europe _prefers massive cars_. US still has much more of obscenely big cars, and Ford F having less % pickup market share shows that there's much bigger market for these cars, if anything
reply