emn13

This probably depends on the size of the area to be searched, and just how hot that region is. After all, if it's fairly small, there won't be any cache misses, and the data structure does use less memory than a typical hash table, which is itself an advantage.

Ah, that makes sense in the context of the article - thanks!

As a novice in this area, it's not clear to me after reading this what exactly the 2-ahead branch predictor is.

The system clearly already behaves that way (i.e. ignores failure) - after all, the fix was to simply delete the offending file. If that's an option, then loader can do that too. It can and perhaps even is smarter, such as "fallback onto previous version".

Furthermore, the reaction to a malformed state need not be "ignore". It could disable restricted user login; or turn off the screen.

If the worry is that this is viable to abuse by malware, well, if the malware can already rewrite the on-disk files for the AV, I wonder whether it's really a good idea to trust the system itself to be able to deal with that. It'd probably be safer to just report that up the security foodchain, and potentially let some external system take measures such as disable or restrict network access. Better yet, such measures don't even require the same capabilities to intervene in the system, merely to observe - which makes the AV system less likely to serve as a malware vector itself or to cause bugs like this.

The argument they're making (which I think is actually a fairly good one) is that this is to users benefit; the economic incentives for advertisers to circumvent anti-tracking tech are quite large. They claim that entirely preventing tracking is brittle; it's likely to be continual game of whack-a-mole that de facto will allow users to be tracked. Instead, giving advertisers a little more of what they actually want (better targeting) without the intermediate step of doing that by tracking users directly removes the incentive to pierce privacy.

Personally, I'm not a fan of advertising for reasons beyond privacy; it's also simply attention-sapping mental noise. Yet I'm not sure that's relevant here; removing some harm might be better than nothing even if I'm not happy with the end result.

The informed-consent angle seems fairly superficial. Yes, that matters - but the essential case is only if the tech is _not_ privacy preserving. Additionally, the ability to experiment is essential; to the extent this doesn't harm users and truly is small-scale I we should embrace experiments even if we don't personally at first glance embrace this specific one. It may seem polite to ask users for consent even here (and clearly that would have been the better PR choice), but I'm also not a fan of largely irrelevant consent forms, especially when asked prematurely - that's pretty close to spam. Sure, on Hacker News that may seem like an important question, but that's hardly a normal or representative slice of the population, and I'm just not sure I share the outrage here.

What exactly is the shadiness you're referring to here? Is it a lack of trust concerning their intentions? Is it a lack of trust that this is privacy preserving? Is it that you don't believe this experiment is small scale (enough or at all)? Or is that you don't trust they'll actually evaluate the experiment fairly, instead opting to push things through?

Another thing coloring my perspective here is that the open web sure seems to be heading in the wrong direction. Chromium is pretty dominant and none of the chromium derived browers appear to have resources (or willingness to spend them) to significantly depart from Chrome while still providing prompt security updates. Webkit is languishing and poorly updated in practice by users. De facto google seems to be pushing users towards at least pervasive tracking and leverage by google; Apple seems to support mostly those web features that don't risk competing with their app store. This isn't great; I'd love to see some competition.

Perhaps Firefox could somehow provide opt-in but noisy questions for users that want that, without harassing the likely large majority that doesn't see the point. It's a shame to chase away users over something like this, that's for sure.

Ideally, the labor market is competitive. If a company tries to offload it's legal costs to its employees, they'll find work elsewhere, at least in aggregate. Ideally (again), shareholders do not have that option.

When a company goes under or significantly downsizes there will of course be impacts on employees. But equally, their competitors' employees may thrive.

I want to stress again that the alternative is basically lawlessness. If a company cannot be held to account merely because doing so might hurt employees, then it's in shareholder's interest to ensure the company disregards those laws whenever they get in the way of profits - which they can do by selecting boards and CEOs that are willing to take "risks" (and it seems quite unlikely that's ever likely to change). Those agents of a company might not even be in the same jurisdiction as the law, so trying to exclusively hold them to account seems like a pipe dream.

In any case, if laws try to very narrowly focus liability, you're also asking for games of musical chairs, and because it's so easy to create and destroy corporations, that's a game that will often lead to evaporation of any penalties.

Shareholders absolutely need to be held to account for the choices their companies make. Even limited liability is a protection with some problematic consequences; we definitely shouldn't make it even easier than it already is to shift burdens onto others or society at large than it already is.

If your aim is to keep profit expectation of violations at no more than zero, then it's also necessary to hold company _owners_ liable for more than their shares are worth. Otherwise, corporations will just play shells games (which they already do for all kinds of liability) to reduce the fines to peanuts via limited liability/bankruptcy. The chance of that reform seems very slim, so perhaps we could at least tax shell companies some percentage of both revenue and value, and not just profits - to represent the real costs of shifting liability. Not that that's likely either, but we can dream.

If the fines are meaningful, they'll primarily hurt shareholders. It's possible a corporation will try to mitigate some of the costs by downsizing, but that's no different from any other corporation with a non-working business plan.

Sparing shareholders for the costs of the choices their leadership made is a recipe for continued disinterest. Why bother appointing boards and CEO's that will avoid this stuff if they're always able to shift the costs to somebody else?

Just because a company has employees does not mean it appropriate to shield it from consequences of its actions.

Chomsky, even in recent years, speaks in very clearly and well-thought out, structured arguments.

The way he phrases it, NATO was essentially at fault and the Russian response followed from that. I don't buy that he misspoke or we misheard; the line of reasoning was very clearly stated. We can quibble about what "taking sides" means, but the message he meant to convey was that the current outcome was the US's responsibility.

Chomsky's line of reasoning was clear, but it's always been very weak on this matter (he's said this quite often). It largely ignores the Kremlin's agency; it hardly matters what the US did here since the Kremlin had choices too and those mattered much more. Even more problematically, it ignored both Ukrainian and the wider post-Soviet region's agency as well. NATO expansion was never forced on anyone; to the contrary, it was eagerly sought after, and why? Because the Kremlin wasn't to be trusted, which turned out to be an accurate prediction.

It didn't have to be so; the Kremlin's institutional mistreatment of its neighborhood _caused_ that mistrust and sustain it to this day. The Kremlin could have acted in good faith, and would have continued to receive the warm welcome from western governments that the initial post-Soviet governments did. It could have mended the Soviet-derived mistrust in eastern Europe, and likely easily so given it's richness in natural resources, and the logistical centrality that attracted trade between former USSR nations via Russia, and it's initially warm reception by western powers.

The hint of far-future NATO membership was a "threat" to Putin the way mere talk of bolt-cutters are a threat to a kidnapper. That threat might well have been real, to be clear, but framing it the way Chomsky did isn't helpful; it obscures Putin's (or the Kremlin's inner circle's) choice to be an oppressive, almost colonial power ruling over it's neighbors.

The problem never was talk of bolt-cutters, the problem is that people _wanted_ those for a reason.

Exactly. I think it's worth considering that people are using "threatened" in two slightly but meaningfully different ways in these discussions. It seems superficially reasonable to defend yourself militarily when "threatened"; but that's only true if that threat is military. However, it seems pretty implausible that either Putin's regime was threatened, or that they thought they were militarily threatened. However, as you point out, it's a lot more plausible they feared cultural contamination.

Putin's regime wanted heavy-handed control over its neighbors; and the Maidan revolution demonstrated not only that this control wasn't as strong as it appeared, but also that it might be possible to break free from that oppression for others too, including perhaps Russian's. That example was the threat from which Putin was "defending" himself.

As much as Chomsky's well-reasoned talks are worth respect, he never really addressed that well. Putin's defense vs. the NATO threat was about as reasonable as a colonial power's "defense" vs. their subject's freedom; and it's also being executed about as reasonably, too. But to hear Chomsky describe it this is basically irrelevant; anything opposed to American overreach is reasonable - even when it's clearly not, and it's not even clear there's any overreach in the matter at hand.

As a very rough approximation, I suspect that html parsing (beyond the streaming of the data anyhow) isn't really all that fundamentally serial. After all, if you seek into an html document at some random point, you can generally interpret the html structure mostly locally, i.e. it's likely possible to subdivide the task of parsing an html document.

Given how leniently html deals with errors and that some of the parsing rules have some context sensitivity (the various modes) actually exploiting large-scale parallelism is probably a very difficult bit of engineering. Additionally, there may be corner cases that have much more context dependence than normal. Also, parsing is already probably not a huge part of a browsers runtime, and aggressive parallelism might be faster but more power hungry for a very small latency win. But I can't think of a specific fundamental limitation that prevents the normal parsing case from being quite parallelizable; I believe it's "just" an engineering problem.

Latency isn't everything; but that doesn't mean it's irrelevant either. I'm OK with a metric that accurately represents latency with the caveat that feel or other factors may be more important. If key and/or switch design impacts latency in practice; shouldn't we measure that?

I guess that is an open question - perhaps virtually all the variance in latency due to physical design is tied up with fundamental tradeoffs between feel, feedback, sound, and preference. If so - then sure: measuring the pre-activation latency is pointless. On the other hand, if there are design choices that meaningfully affect latency without meaningfully impacting other priorities, or even where gains in latency are perhaps more important than (hypothetically) small losses elsewhere - then measuring that would helpful.

I get the impression that we're still in the phase that this isn't actually a trivially solved problem; i.e. where at least having the data and only _then_ perhaps choosing how much we care (and how to interpret whatever patterns arise) is worth it.

Ideally of course we'd have both post-activation-only and physical-activation-included metrics, and we could compare.

My initial gut reaction to this was - yeah, of course. But after reading https://danluu.com/keyboard-latency/ - I'm not so sure. Why exactly should physical travel time not matter? If a keyboard has a particularly late switch, that _does_ affect the effective latency, does it not?

I can sort of see the argument for post actuation latency in some specific cases, but as a general rule, I'm struggling to come up with a reason to exclude delays due to physical design.

Sometimes the perfect is the enemy of the good. As the XZ saga shows, even clearly exceptionally well organized attackers don't have an easy time injecting hacks like this; and things that increase the attackers costs or risks, or reduce their reward can be useful even if they don't solve the problem entirely. Reproducible builds are useful; they don't need to be silver bullet.

It's easier to hide nastiness in a binary than it is in source. And indeed this XZ hack too relied on multiple obfuscated binary blobs. The hash helps because it makes it a little harder to hide things like this. It's not a silver bullet, but it would have in this specific instance made it harder to hide that malicious m4/build-to-host.m4 in the tarball - after all, had the attacker done that despite publishing a hash they would have needed to use the hash including the modified build script, but then anybody building from the git repo would have had a different hash, and that's a risk for detection.

Reproducible builds and hashes thereof aid in transparency and detecting when that transparency breaks down. Of course, it doesn't mean hackers can't hide malicious code in plain sight, but at least it makes it slightly harder to hide between the cracks as happened here.

One thing a culture of reproducible builds (and thus stable hashes) however does provide is a lack of excuse as to why the build isn't reproducible. Almost nobody will build from source - but when there's bugs to be squashed and weird behavior, some people, sometimes, will. If hashes are the norm, then it's a little harder for attackers to pull of this kind of thing not because you trust their hash rather than their blob, but rather because they need to publish both at once - thus broadening the discovery window for shenanigans.

To put it another way: if you don't have reproducible builds and you're trying to replicate an upstream artifact then it's very hard to tell what the cause is. It might just be some ephemeral state, a race, or some machine aspect that caused a few fairly meaningless differences. But as soon as you have a reproducible build, then failure to reproduce instantly marks upstream as being suspect.

It's also useful when you're trying to do things like tweak a build - you can ensure you're importing upstream correctly by checking the hash with what you're making, and then even if your downstream version isn't a binary dependent on upstream (e.g. optimized differently, or with some extra plugins somewhere), you can be sure that changes between what you're building and upstream are intentional and not spurious.

It's clearly not a silver bullet, sure. But it's not entirely useless either, and it probably could help as part of a larger ecosystem shift; especially if conventional tooling created and published these by default such that bad actors trying to hide build processes actually stick out more glaringly.

While it's interesting to philosophize about alternatives like this and it's seemingly obviously true that there's no trivial solution to maintainership that solves all problems perfectly, I'm a little wary about presenting these flawed approaches as somehow equivalent; I highly doubt they're even remotely equally bad - nor that they have equally big upsides.

Is it really complex? I think the real reason it gets this reputation isn't because of any complexity or lack of logic, but rather more simply because it's so opaque. Browser devtools are much worse for CSS than JS; there's no way to ask for an explanation of _why_ a certain value was computed. You can't step through a computation and figure out that well, DUH, there's a cyclical dependency here so of course that won't work, or, DUH, it's using the wrong containing block etc etc etc. Even stuff like selectors are pretty opaque; like you can't easily visualize why a certain selector matches or worse _doesn't_ match, and even trivial concepts like specificity aren't really surfaced in a very helpful way.

It's very much a black box people just fiddle with until it works. But if we had better tooling to explain why selector A matched and B doesn't (relevant in particular for stuff like `.outer .inner` - which `.outer`, exactly?); and why A has more specificity than B; and why and how a certain value was computed (e.g. so that a margin-top of some block is related to a highlightable _width_ of some specific containing block, for instance) - then I bet most people would figure out CSS pretty easily.

Another helpful thing would be if browsers had compiler-style warnings for CSS. We have (bad) CSS linters, but that's partially because it's hard to tell what kind of CSS is problematic "in general" for lots of the tricky stuff that only becomes apparent for a specific DOM. E.g., it seems like a browser should have no problem highlighting which percentage sizes are being semi-ignored due to cyclical dependency issues, but... they don't. Instead they simply pick some fallback which while technically deterministic isn't educationally helpful. There are usually pretty simple reasons why things "don't work" - but good luck finding those, because browsers won't tell you.

CSS is pretty simple, but not simple enough to be immediately intuitive in all cases without some inspection help - and we don't really have good CSS inspectors AFAIK.

It's not true. It's also a dangerous rule of thumb. Percentage widths and heights refer to _containing_ blocks, not contents. However, if you size a box as some percentage of a block, and that block in turn has a size that depends on its contents, you can get a cyclical depedency. In that case, there _are_ rules on how that's resolved, but typically it's almost as if you hadn't written the percentage rule at all; i.e. this very rarely does what you want. And as it happens, if you're just in normal flow, then of course the height of any container depends on what's in it, so percentage heights with respect to such a container don't work.

The exact cyclical-dependency-breaking-algorithm is more complex: https://www.w3.org/TR/css-sizing-3/#cyclic-percentage-contri...

You should only use percentage sizes with respect to containers that have a definite, non-content-dependent size. As it so happens that's the _default_ for width, but not for height, but you could easily have the reverse situation if you're shrinking width to fit and sizing height explicitly.

So the problems people encounter are really simple and the need for the CSS exception here pretty intuitive. I'm pretty sure people get caught out by this largely because there's no good feedback loop here; it's not like the browser devtools warn you when you've made a cyclical dependency: it just doesn't quite do what you want and worst of all: sometimes that still sort of looks "ok" so you don't notice what's wrong right away. There may be some good reason why devtools can't warn you about this, but that's the real problem here, not CSS illogicality.

So the rule of thumb: don't rely on cyclical dependencies; i.e. don't define width or height with respect to a container that itself has a width or respectively height that depends on its content.

Furthermore, even as a website aiming to survive some momentary spike in performance - slowing everything down for everyone _can_ be part of a solution to serve more people but fewer things each. People might not normally be willing to wait for more than a second or two for a load; but when they expect or have a sign that things are slower than normal, they might have a little more patience (or just come back to that tab later).

I think people are a little too negative on queues. Sure, really naively implemented with entirely unbounded capacity they're an accident waiting to happen... but you don't have to do that.

Clearly, there's some truth to this perspective. On the other hand, which alternative actually makes this easier? If your schema is non-enforced, and/or your data (and its schema) are in loosely coupled distributed silos, and/or as in the articles case indexes are essentially little programs... Then broad scale schema evolution goes from being difficult to often being effectively entirely infeasible.

It's possible that in turn forces users to adapt and split their changes into smaller chunks, but that's pretty speculative and they might simply fail entirely in the attempt.

Which data stores are more easily evolved than a relational DB with a fairly restrictive schema?

I'm not sure I understand what you're saying. Perhaps you could point out where your perspective differs from mine? So, as I see it: Open AI _is_ a non-profit, though it has an LLC it wholly controls that doesn't have non-profit status. It never "became" for-profit (IANAL, but is that even possible? It seems like that should not be possible), the only thing that happened is that the LLC was allowed to collect some "profit" - but that in turn would go to its owners, primarily the non-profit. As far as I'm aware the board in question that went through this purge _was_ the non-profit's board (does the LLC have a board?)

From the non-profit's perspective, it sounds pretty reasonable to self-police and ensure there aren't any rogue parts of the organization that are going off and working at odds with the overall non-profit's formal aims. It's always been weird that the Open-AI LLC seemed to be so commercially focused even when that might conflict with it's sole controller's interests; notably the LLC very explicitly warned investors that the NGO's mission took precedence over profit.

While very frustrating, it's just not reasonable at all to call that fraud or corruption. To make that case, you'll need to also make the argument that the CEO's remuneration is unreasonable to the given market rate; and more specifically, that you might be able to hire somebody else and achieve similar results for meaningfully less cash, and the CEO and board know this, and they're overcompensating intentionally.

Now: I agree that the pay is absurd! I'm quite willing to believe she's not worth it, too. But she's hardly the first CEO to have ridiculous pay; nor am I convinced the board is overcompensating her for corrupt reasons - it may simply be a difference of perspective. And - perhaps I'm wrong, and this pay is a going market rate and a hypothetical cheaper replacement would do worse - I really don't believe that, but to call something corruption I'd need to be rather sure of that and of their knowledge of it.

While this is great brainstorming, that doesn't mean it's a viable business plan. Having a large highly qualified dev-team working on experimental stuff for now over a decade and no likelihood of completion anytime soon and without a business plan is pretty tricky, even for a non-profit.

In general, for research of that type (of scale) it doesn't strike me as generally very viable to rely on commercial support, and such a niche technicality is surely not going to collect enough donations to run on that alone. If we want to fund this because it's an interesting option for the future in the long term, governments are going to need to chip in - and it looks like that's at least partly at play here (or even primarily), i.e.: system working as designed.

Maybe excel can autoconvert the new names to the original ones? Worth a feature request, I'm sure.

My assumption is that the involved parties will attempt to use reasonably self-interested common sense unless required otherwise. The text does not appear to say there must be immediate publication, therefore I'm assuming that won't happen, but it's legalese; it's possible I've misinterpreted this.

The reason I think there's room for normal processes here is that they're talking about ENISA forwarding that notification to CSIRT (without the 24-hour deadline? possibly later?), and they talk of "unless for justified cybersecurity risk-related grounds", and even if CSIRT and ENISA have _notifications_ eventually (potentially well past that 24 hours), it doesn't say that requires immediate publication, merely that the notification is for _purposes_ of "coordinated vulnerability disclosure".

It doesn't say that disclosure must be immediate, nor in fact does it even say it must _ever_ actually occur; simply that that's the aim. If anything, that constrains the organization; so it wouldn't be valid grounds to withhold forwarding to CSIRT if some intelligence agency for instance happened to find that convenient (not that I'm under any illusions that that is therefore inconceivable or that there aren't potentially 100 other loopholes).

Sounds to me like both ENISA and CSIRT have the option to sit on things, as it is, and also as if the manufacturer can ask them to do so.

Also, that word "justified" can mean pretty much anything. It might turn out to mean "we haven't finished our impact assessment yet", and therefore by default _all_ vulnerability notifications initially are not forwarded because of course they won't be assessed in that kind of time-frame, or if forwarded at least not published.

Basically: this all sounds so vague that it doesn't appear (but IANAL) that the proposed rule requires YOLO style vulnerability notifications, so I'm going to presume they'll treat this with the necessary caution.

The timetable is eminently realistic. It may be quite the change however; but whether that's a bad thing? The specific criticism in the letter appears to be a little unreasonable, frankly.

Presumably any actively supported software is taking _some_ steps within that first day of becoming aware that there exists an actively exploited exploit. Merely reporting it's existence confidentially does not appear to be an infeasible step, at least for professional organizations (what about small-scale OSS?). The requirement does not apply to all vulnerabilities; it applies to vulnerabilities the manufacturer knows of _and_ that are actively exploited _and_ the corporation knows this.

They letter authors express the worry that governments will abuse these vulnerabilities; but while the worry is reasonable, the correct avenue for that is public discourse and accountability; not granting corporations access to vulnerabilities that governments may not see via one specific route, surely? Additionally, if abuse of vulnerabilities by governments is a problem, then let's address _that_ not merely one specific means of communication about them. And if the worry is abuse; then surely this holds for all actors, explicitly non-governmental ones too. Nor is it obvious abuse will rise merely due to reporting. And lack of reporting may indeed encourage abuse by non-governmental organization because there is less chance of it being detected. There already exists a somewhat legal but unethical market for exploits; adding government bureaucracy here is almost certainly better than just letting money talk. The argument seems almost bad in faith; it's concerned about abuse by intelligence services that presumably have some democratic oversight; yet not concerned about abuse outside of that. Had the authors argued in favor of obligatory secrecy regarding _all_ actors, and proposed a mechanism to safeguard that, their claimed aim would have been more plausible - but they did no.

The exposure risk the letter posts makes no sense. The legislation doesn't require publication; it requires confidential reporting. The only way this argument makes sense (but the letter doesn't make it explicit) is if they think corporations will be unable to communicate securely with such a reporting endpoint, or that the endpoint itself will be accessible by bad actors (presumably via a security problem?). Again, the letter does not make this argument; it's leaving us guessing.

The letter conflates mitigation by the software publisher with mitigation by the software consumer, and the way it does that sure looks intentional; essentially claiming there's no benefit from letting the software's user mitigate a vulnerability because the producer already is. That's clearly nonsense. The letter also uses emotive language such as "each disclosure triggers a wave of government notifications"; I'm skeptical the authors are capable of being unbiased if that's how they're presenting this argument to change policy.

Fundamentally, the letter appears to value private corporate control over secrets above government access. That's simply a political stance - but I'd have an easier time taking that seriously if they just came out and said it.

Additionally, the letter doesn't address one of the points of partial transparency like this: it discourages harmful CYA secrecy. Reporting on vulnerabilities is a financial risk; there's always the incentive to find excuses (whether explicitly, or organically due to how organizations work) to mitigate that at the expense of mitigating the harms of the vulnerability itself. People and corporations act differently when they know others might take note of their choices. And that's often a good thing. Even _if_ there are real harms due to confidential reporting, it's not clear those outweigh the benefits.

To be clear: I do NOT support the CRA (don't know enough, but it sounds potentially onerous, for sure); I merely don't believe this letter makes a very convincing case against article 11. There may well be better arguments, and almost by definition improvement is possible.

Sure, and most miracle drugs don't pan out. Yet there is some reason to at least hope this is a little better than arsenic - it didn't kill the mice nor dogs, and there are various plausible sounding claims about toxicity made (to a non-expert, I just googled the various methods and showed the paper to cancer-researching friend that didn't immediately cry foul).

I mean, the track record of such drugs still suggests it'll likely not live up to the hype of the title here, but that's the point of further research, which does appear to be happening. It's quite likely there's some unforeseen limitation, but hey, we can always hope.

For corporate liability to really mean something we almost certainly need to reconsider the very foundational concept of what a corporation is. Because at it's heart, in granting the legal concept of a corporation we assume that it's a good idea to give a large group of people the ability to act with limited liability, for reasons of economic efficiency.

What you see in industries such as mining where corporate liability is technically far less forgiving is that this concept of limited liability implies that a network of corporations can play musical chairs with hard-to-predict risks - essentially abusing bankruptcy and the general difficulty in enforcing liability via the courts even in the best of times to achieve not merely limited liability, but intentionally reduced liability. Since much of this is just a bunch of man-made rules, of course we're all going to game them to find the particularly profitable loopholes; this is inevitable. If it's not pollution, it's lobbying. If it's not lobbying, it's privatizing infrastructure at exploitative cost. If it's not physical infrastructure, it's owning social infrastructure, i.e. platforms. If it's not platforms, it's an incomprehensible spaghetti designed to evade or avoid taxes.

Regarding corporations as equivalent to natural persons for many legal questions was a huge mistake, and needs to be reversed. I'm not particularly hopeful we'll get there without a literally bloody revolution, or by losing a war, or some similarly horrifying discontinuity of modern life.

Allowing people to cooperate under some legal entity is a great idea; allowing capitalist incentives to optimize those a reasonable idea with some risks (but hopefully manageable ones). But doing all of that at essentially no cost, little oversight, lots of loopholes, very little transparency, very limited liability, legally not just unrestricted but even protected "speech" and with arbitrary nesting has to be one of the most idiotic things we've come up with in centuries.

The point of that quote is of course not that the evidence must have some mythical flavor or whatever - that would be absurd, but rather that if your prior is a strongly held belief that something is not possible and thus the claim to the contrary is extraordinary, then the evidence sufficient to overturn that prior belief must naturally also be extraordinarily convincing.

It's just standard Bayesian reasoning (apologies if I'm misusing the terminology).

Given how much prior research has been done on superconductors, how attractive a target they are for research, and the demonstrated history of fraud in the field - it's not unnatural to retain skepticism concerning this story.

Doesn't mean the story is fraudulent or falsely believed to be fraudulent; it simply means that more evidence is needed to settle this convincingly. I'm sure will get that soon enough - either way.