And the whole edifice of “you need to reboot to update anything” is a knock-on effect of the file locking/sharing model, leading to the misery of “we forced a reboot and lost your work again, sucks to be you”.

Used to be every VPS refresh cycle you'd get more server for less money. This is miserable

The To: header _is_ part of the signed material so will list the original recipient not the victim — but the attacker sets the recipient name/address to something misleading like “Order Received” to obscure this, and sets the store name to some long text that will be misleading when templated into the PayPal invoice request mail text.

PayPal have long had a problem with failing to make untrusted supplied text clear in their communications, but this is an unusually convincing attack.

I don't know why they always use (compromised?) onmicrosoft subdomains in particular. In the samples I've seen they're getting an SPF softfail so it doesn't seem MS's relays are passing SPF for paypal (sendgrid's might...)

- is allowed to set cookies scoped to *.github.com, interfering with cookie mechanisms on the parent domain and its other subdomains, potentially resulting in session fixation attacks

- will receive cookies scoped to *.github.com. In IE, cookies set from a site with address "github.com" will by default be scoped to *.github.com, resulting in session-stealing attacks. (Which is why it's traditionally a good idea to prefer keeping 'www.' as the canonical address from which apps run, if there might be any other subdomains at any point.)

So if you've any chance of giving an attacker scripting access into that origin, best it not be a subdomain of anything you care about.

But a thin layer over MSI is actually what you want; the commercial tools that preceded WiX and tried to abstract away what Windows Installer was actually doing were much worse. Because Windows Installer is such a mess of counterintuitive design and bugs that you are going to need to debug it.

WiX is to be saluted for greatly reducing the level of misery involved in making installers for Windows. But the level of misery is still very high indeed.

Absolutely horrible product. And not even cheap before having to turf it out in favour of a proper SSD.

It's typically easier to work out a layout if you use padding in preference so you don't have to worry about them, but first you have to reset the margins the browser gives you.

The proper way to enumerate the Windows Installer database should be MsiEnumProductsEx. Except. If someone has monkeyed with a product key name in the registry such that it's longer than normal(...), MsiEnumProductsEx spits ERROR_MORE_DATA for that product and all subsequent dwIndex values (so if you're waiting for ERROR_NO_MORE_ITEMS you'll have a fun hang).

(...which sounds like it shouldn't happen, but it turns out there are a bunch of users following forum post advice to hide a product by renaming it with a _Disabled suffix. oh dear)

So in reality you'll probably have to access the undocumented registry backend for the Windows Installer database, in HKLM\Software\Classes\Installer\Products, converting the weird backwards-struct form of the UUID in each key name to the real ProductCode.

Of course not all software uses MSI packages or can be found in the Windows Installer database. You can indeed go to the Add/Remove Programs database in HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstaller, except that the data there is super low quality. You'll have bogus products missing name and/or version, nonsense entries for things no longer present, inconsistently named products between versions, and products with different names on different locales. Which makes it quite difficult to do anything with this data.

There isn't really a single source of truth for "what products are installed" under Windows and all options for reporting what's installed are pretty bad.

I use the method with `canvas.clipPath(path, stroke=False, fill=True)` on a path I've parsed manually from SVG then `canvas.linearGradient`.

The simplest possible syntax is to make named elements available globally, and if that clashes with future additions to the DOM API then well that's a problem for some future idiots to worry about.

as a strategy it worked pretty well, unfortunately

I'm hanging on with 22.04 using the mozillateam PPA to get a proper deb firefox and it's working fine for now. If they stop exposing that option I'll be off too.

I'm not religiously against snap but the experience of trying to use it has been pretty awful so far. First the process of switching firefox to a snap during release-upgrade hung and broke the upgrade. Then after clearing up the mess and uninstall/reinstalling, attempting to run Firefox silently did nothing.

Personally I'm not a fan of ESL and would seek out the remaining HTST brands, but it's eminently preferable to UHT.

For example now you have to worry about whether there are any characters in the ID that need escaping in a selector (eg `.`), something that may not be easy to verify when formatting an ID out of variables.

So I'd suggest preferring getElementById for its directness, rather than for micro-optimisation reasons.

(In principle the same should be true for getElementsByClassName, but the live NodeLists returned by that method are a trap for the unwary, so neither option is ideal.)

So WSL doesn't help me, really.

Instead, they kept the high nose and used the space as a trunk. After all, injuring fewer pedestrians sells no cars. Indeed, the market prefers an enormous, deliberately threatening-looking chariot that makes you feel big and virile.

Ford are behind this game in that they haven't given their truck an explicitly hostile name like “People Mulcher”.

So, sure, maybe there's a good reason to want XML-compatible syntax. But Netscape 4 users? Let's hope not!

Sure. LiveConnect was commonly used as glue to invoke and interact with applets from JS.

I wouldn't necessarily say that it enabled a virtually unlimited blah blah enterprise parp, but it had its uses. A common hack was to put some shared storage in an applet so multiple documents could use it to persist and communicate cross-document data, back before browsers could do that natively.

There was some really tedious bug in IE with the Sun VM that occasionally allowed JS events to fire concurrently whilst LiveConnect was waiting for a response from a method called on an applet, which we never quite figured out. This was one of many things that made JS+applet development unreliable and unpleasant.