Posts by Michael Wojcik

Who claimed it was "the answer to every question"?

And fuzzing is language-independent, so that part of your claim makes no sense.

Re: Found some of the money

it'll be interesting to see how the US legal system will deal with this as it's über rich guy versus shareholders

The Delaware Court of Chancery is not impressed with rich guys. They deal with rich guys, and their armies of lawyers, all the time.

Re: Sorry, but

That is the one thing Orwell got wrong with the Telescreens in 1984. It is not government watching - it is the salesman working out what to sell you next...

Yes, as useful as Nineteen Eighty-Four¹ is as a symbol and touchstone, and while it really does work quite well as a novel, it turns out the oppressive surveillance state is in the minority and often short-lived (though North Korea is giving it a go).

The Foucauldian enjoy-your-submission capitalist state has been much more successful. Novels such as Brave New World and Fahrenheit 451² describe more dangerous dystopias, where the majority of the populace is only to happy to participate.

¹The novel's proper title. Orwell hated it when people wrote it with digits.

²Bradbury mentioned in interviews that he considered F 451's depiction of future entertainment – particularly the Walls – a more important feature than the book-burning.

Re: Apathy is the problem

Anon simply pointed out the calling the owner a creep

OP never did that. He wrote that having the camera positioned such that it has a close view of the neighbor's house is "insidiously creepy".

Converting an adjective describing an action into a noun labeling a person is a common rhetorical move, elevating the interlocutor's claim of bad action into a stronger strawman claim of systemic wickedness. No one can simply commit the occasional sin; either they're reprobate sinners, or they must be completely innocent.

The owner of the Ring doorbell may have done something creepy without necessarily being "a creep". The creepy act may well be unintentional. That doesn't make it unproblematic.

Re: "SQL coders"

Yeah, avoid those stored procedures. All the smart kids use string concatenation and interpolation to build SQL queries on the fly with tainted data.

Re: I see.

"It's written in Electron, so it requires 130 TB of RAM..."

Re: Nah

There's LaTeX (probably LaTeX2e) itself, and then there are potentially many thousands of packages. Plus of course some TeX implementation and back ends. But it's the packages which are taking up most of the space.

So, sure, you might have had a pretty small LaTeX toolchain back in the day, and you could even put a reasonably small one together now. But what usually happens is people go with defaults and get zillions of class and macro packages, fonts, and so forth.

Honestly, the last time I installed LaTeX (when I got a new personal laptop around the beginning of this year) I didn't put much effort into trimming down the default installation, because Disk Is Cheap and it wasn't worth my time to figure out what I didn't want.

Re: Heh heh...

True fans don't rant. We simply bask in our smug superiority.

Re: Enter candidate for dead simplest text editor

You do if you don't want to keep taking your hands off the home row. Either you use the mouse (or whatever pointing device you have), or you memorize "accelerators", which are just "cryptic key combinations" dumbed down for people who don't want to learn things.

I wouldn't recommend vim to people who aren't already using it, to be honest. It's got a tremendous amount of historical baggage and tremendous complexity. (Same for emacs, particularly since I don't even like emacs.) But this refrain of "ooh modern UIs are so easy and fast!" that we've heard since Steve Jobs began parading the Mac around is nonsense. It's a bogus generalization and it's not supported by research.

Re: Enter candidate for dead simplest text editor

Yeah, I use LaTeX for my personal (and, back in the day, academic) writing too. Generally I use LyX, though it's easy enough to load a LyX file – just LaTeX with some additional markup – into vim, say, if I want to do something that's not entirely convenient in LyX. And I used to do outlining with FreeMind and then use an XSLT stylesheet to convert the FreeMind XML format into LaTeX.

But what Liam's describing sounds like a use case where LaTeX is overkill. LaTeX produces nicely¹ typeset documents, these days mostly in PDF now that the troff family has faded from prominence. Using LaTeX for a short document with minimal styling (italics, bold, and hyperlinks) where layout and typesetting really aren't much of a concern, and you may need a wide range out output formats – that's overcomplicated and not a great fit.

Indeed, if your output is real POSH HTML, you aren't going to be doing much layout, and no typesetting, because the UA will handle the final formatting. And that's as it should be, for HTML. So the greatest advantage of TeX is irrelevant in that case.

¹Well, yes, there's some debate about the layouts produced by TeX and LaTeX. But better than Word does, certainly.

Re: Enter candidate for dead simplest text editor

Actually, there's no reason why gvim shouldn't be able to render Markdown into a separate buffer, and you could use splitting to show that simultaneously and have it update in real time. Someone could just write a plug-in for that, if there's actually demand.

But among vim users (of which I am one) there may not be much demand for such a thing. Or someone may already have done it.

Re: Enter candidate for dead simplest text editor

I don't mind when software actually takes advantage of new technology. But most of it simply regurgitates dubious design decisions of no real value.

Re: Enter candidate for dead simplest text editor

I understood what you want from the article. It's not what I want, so after reading the piece I'm not rushing out to download PanWriter; but I also know my use cases and preferences aren't universal. And I don't mind taking a few minutes to hear about what someone else wants.

That said, if I were looking for something like this, I don't know that I'd be able to stomach an Electron app. Having to suffer with Teams is bad enough. But, again, preferences.

Re: Mountains of coal ash

Chemical toxicity of plutonium appears to be overrated, particularly by people who like to quote Ralph Nader. Plutonium is chemically toxic but not very bioavailable, apparently.

The ATSDR toxicity profile for plutonium (PDF) shows almost all adverse effects stem from various cancers or other radiation-induced pathology such as radiation pneumonia. Studies of plutonium-exposed workers at Sellafield did show elevated risk for cerebrovascular disease and other cardiovascular conditions, but mostly at elevated risk levels much less than those found for various cancers in other studies. (And the cardiovascular-disease effects weren't reproduced in an animal study, FWTW.)

Obviously, cancer is not an outcome anyone wants either, and plutonium is removed from the body very slowly, so it has plenty of time to do cumulative damage or accumulate if you continue to be exposed. It can be inhaled or ingested (according to the report, it's not significantly absorbed through the skin, though of course dermal burns and other damage can occur from sufficient skin exposure). So, yeah, you don't want to be exposed to significant amounts of plutonium. But the "plutonium is super toxic you guys!" line that the anti-nuclear types have been pushing since Nader doesn't appear to be supported by actual evidence.

Of course, after the last increase to the standard deduction, for many people itemization doesn't result in a larger deduction.

I miss itemizing, actually. It was a bit of fun watching the numbers change after I added each item, and a good reason to go through and do any filing and organizing of financial records that I'd been procrastinating on. But I recognize that it's not actually a good taxation mechanism.

Re: During Mudge's employment, he uncovered extreme, egregious deficiencies

Its quite clear that what Musk wanted to buy wasn't exactly what Twitter was selling. Twitter is potentially a valuable resource but to be correctly valued the user base has to be accurately enumerated.

Oh, please. Musk got a bee in his bonnet and launched his bid essentially on a whim, then got buyer's remorse and is trying to back out. The "oh my god it's full of bots" excuse is just him trying to save face, just as the "they won't give us the information" is a transparent legal dodge (which likely won't succeed).

I doubt Musk had any well-formed idea of "what [he] wanted to buy". He's forever chasing squirrels.

Re: The timing raises questions

Exactly. Mudge's position at Twitter was essentially "identify our security issues and push projects to fix them". In a bit over a year he did a bunch of the former part; only insiders can say how much of the latter. Then Agrawal came in and said "shit, this is going to cost us some bonuses!" or "man, this guy will not say what I tell him to say!", and fired him.

There's little reason for executives to blow the whistle on issues in their own portfolios, while they're still in a position to try to get them fixed.

I don't see anything wrong with what Mudge is doing here.

Re: Musk has about 44 billion reasons

What about Musk's purchase agreement for Twitter do you think this applies to?

Alas, it is both plausible as claimed, and plausibly a bogus excuse. The spectrum of fraud in cryptocurrency, DeFi, and related industries is wide. (As those who read Molly White's blog know.)

Re: GIT- Aptly named

Try setting up a Subversion server yourself,

I have. More than one, in fact.

and if you manage that you can marvel at how hard it is to do just a simple merge.

Merges in Subversion are generally trivially easy – certainly since the introduction of merge tracking, and they weren't that difficult before that. Reintegration merges require a grand total of two commands if there are no conflicts, and resolving conflicts with Subversion is certainly no more difficult, and generally more straightforward, than with git. Cross-branch cherry-picked merges are rarely any more effort. I do dozens of Subversion merges of various sorts a month.

git merges, conversely, can be quite baffling for people who don't understand git's data model and arcane command set. Just look at the unending battles over whether and when rebasing is a good idea.

git does very well at what it was created for, namely truly distributed change control (of text files; it doesn't do well with non-text formats). When used with a single centralized repository, which is how probably the vast majority of its users use it, it's simply extra complexity and obscurity for little or no benefit.

Re: Signing?

Signing is irrelevant, because the UAs in this case – XML parsers – don't know to check for a signature; so if they received a malicious schema or DTD document without a signature, they'd proceed to parse it.

And there would be no point in making XML parsers require signed schemas. (DTDs aren't XML, and AFAIK there's no specification for signing DTD documents, so they're out of the question anyway.) Many organizations create schemas for all sorts of purposes, and requiring signatures would have been a prohibitively expensive step,¹ so schemas simply wouldn't have been used. People who wanted validation would have stuck with DTDs or an alternative XML schema mechanism (e.g. Schematron, which was a real thing).

Now, you can certainly argue that we'd be better off if XML Schema had required signing, and therefore had withered on the vine. But the XML Schema Working Group wouldn't see it that way, so there was never any incentive for them to consider requiring signatures.

Also, XML Schema predates XML Signature – XSD 1.0 in 2001, XML Signature Recommendation in 2002.

¹I've worked extensively on a production code-signing system, and read a great deal of the academic and industry research on code signing. This would effectively be an application of code signing. Code signing is a big problem for a lot of organizations, and even more so for developers. Requiring signatures for schemas would have hugely increased the cost of using schemas.

Re: Whats's the point?

The only reliable certificates for this are the Extended Validation (EV) or better certificates, typically represented in browsers by a full green bar in the certificate area.

2010 would like its myth back.

EV certificates were a CA scam. In practice the EV requirements have been shown to offer little additional security. Chrome stopped signaling the EV/OV/DV difference to users years ago, on the grounds that most users had no idea what it meant.

And considering the huge list of trusted CAs that most browsers ship, referring to any sort of server certificate as "reliable" is, well, laughable.

Re: Whats's the point?

LE and other zero-cost CAs have certainly been used for typosquatting and other confusion attacks, but if you can get an LE-issued certificate for w3.org I'd be impressed. And since we're talking about URLs embedded in existing and automatically-generated documents, for the vast majority of cases, typosquatting isn't a viable attack in this situation.

Certainly PKIX is a horrible mess (albeit a somewhat less horrible mess following the broad adoption of Certificate Transparency), and X.509 itself is a horrible mess. And certainly the mere presence of a certificate which a typical browser will accept proves very little, though it does usually mean adequate protection against passive eavesdroppers for that connection. (Frankly, this was true before LE and the HTTPS Everywhere movement, because browsers ship with such a huge list of trusted CAs, many of them dubious or potentially subject to coercion.)

That doesn't mean that enforcing HTTPS for w3.org would have no benefit, however. On the other hand, it does come with a cost. The same is certainly true of HTTPS Everywhere, which provides some protection against, for example, script-injection via DNS hijacking when on untrusted networks (the classic browsing-in-a-café attack); but as you say penalizes many small sites which have no information that requires privacy.

Re: Whats's the point?

Certainly fetching a schema or DTD by plaintext HTTP opens the client up to denial-of-service; just fail the request or serve a document that rejects valid inputs. Whether it's worth compromising HTTP (e.g. by DNS cache poisoning) to do that in the general case is dubious, but for specific targets it might well be worth some attacker's while.

Schemas are themselves XML documents, so if someone is using a validating parser that has external-entity support enabled, hijacking a request for a schema could be used to mount an XXE attack. That's just one example of a more-dangerous attack.

Broadly speaking, for a lot of applications a validating parser can be leveraged into an HTTPS-to-HTTP downgrade attack over multiple connections (to distinct entity servers). That's not as easy to chain as a downgrade over a single connection (or over a multiple-connection link to a single entity server), but it's still a vulnerability.

That said, I don't offhand recall any discussions of this being seen in the wild, at least not specifically against resources hosted at w3.org. But that doesn't prove anything either; I may have missed it, or it may not have been published, or attackers might not have been exploiting it before but could in the future.

Re: "production systems that depend on externally hosted W3C resources"

Because that's how the examples and tutorials did it, and indeed what they recommended, for schemas and DTDs and the like. And now we have vast corpora of documents and myriad interoperating business systems which use those references.

This article really boils down into "Not all UAs are browsers", a lesson that most developers haven't learned, and in many cases apparently can't understand.

Re: "production systems that depend on externally hosted W3C resources"

a mainframe mentality where all code was documented and accounted for

I work with a lot of mainframe-using sites, and this is a hilarious fantasy. I don't know how many times I've heard that they don't know which version of the source built the binaries they're running; or what parts of their vast archive of source code they actually use; or even that they're sure, after investigating, that they've lost the source code, and could we recommend a decompiler?

Some mainframe shops are tight ships. Many are not.

And a great many exchange data with third parties, and a lot of that is XML, and they're in this same boat – except they're probably using IBM parsers which I believe support redirects and HTTPS (though I haven't bothered to confirm that).

One problem is a vast corpus of extant XML documents with embedded schemaLocation attributes that specify http-scheme URLs, particularly when you don't control those documents – for example, because a partner sends them to you for automatic processing.

For that matter, you might have a schema document stored locally which itself references http://www.w3.org/2001/XMLSchema.xsd as its own schema. The W3C still provides http-scheme URLs as the official ones for various schemas and DTDs in many places.

Updating all of those to refer to local copies instead could be quite a lot of work. And for signed XML documents, it's a non-starter.

Now, you could use the proxy-interception technique that others have discussed to serve those documents from a local server, which would be faster and safer than fetching them from the W3C. That seems like the most plausible solution to me. But it's not trivial for many organizations which don't already have expertise in that area.

Re: E=World

Atari ST? That wasn't even the first Atari micro that had color and sound; the 400 and 800 came before it.

The Apple ][ (1977) was probably the first mainstream ("home") microcomputer with color and sound support, since the other two big 1977 micros – the Commodore PET 2001 and Tandy TRS-80 Model 1 didn't have them. The PET could do sound through an optional peripheral but its display was black & white only. The TRS-80 similarly had a monochrome monitor, and could only do sound by plugging appropriate equipment into the output jack on the cassette player.

The Commodore VIC-20 and Tandy Color Computer weren't released until 1980.

Of course, you paid for the Apple ]['s color and sound, particularly if you wanted high resolution (such as as it was).

Re: E=World

their implementation of ideas, hardware & software is the reason why USB is ubiquitous, laptops all look like MacBook Air-wannabes and all personal computers use GUIs, amongst other things

Reason enough to dislike Apple, in my opinion.

Miniaturising laptop components to make laptops easy to carry: 1991 onwards with the PowerBook 100 series

I'm not convinced by this one in particular. (Well, I'm dubious about ADB being particularly interesting, and IEEE 1394 is a whopping great security hole.) IBM had the PC Convertible five years earlier, and the LX40 a year earlier; and they were by no means leaders in the PC-compatible laptop game. "Miniaturizing laptop components" is very vague phrasing; it's not like manufacturers at the time were routinely making them larger.