> Countless time wasted because the anti-virus or some other part of Windows locked a file.
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”.
Yes, they're originated by PayPal, but collected by a different original recipient and from there sent on to the victim. The envelope-recipient is not part of the material signed by DKIM, so the signature remains valid.
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.
Yeah it's a thin layer over MSI tables, so if you don't already know how Windows Installer works then it's not at all clear how to do many seemingly-basic installer tasks. And few people really know how Windows Installer works because that is itself obscure, poorly designed and documented.
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.
Ugh, a friend bought some similar device due to a misleading description of what the HD was. He'd tried to change the partitioning without knowing it was there; turns out if you had anything but a single Windows partition (with custom drivers injected in the right undocumented way at install-time) you ended up with a sans-optane uncached 5400rpm HDD, which even at that time was completely unfeasible as a system disc.
Absolutely horrible product. And not even cheap before having to turf it out in favour of a proper SSD.
It's to avoid vertical margin collapsing. The rules for margin collapsing are complex, counter-intuitive, and often considered misconceived. (https://wiki.csswg.org/ideas/mistakes)
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.
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”.