- 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.
I'd agree vertical margin collapse rules have some counterintuitive cases. And I've definitely seen (and used) something like:
h1, h2, h3, h4, h5, h6 { margin: 0 0 1em 0; }
which fits with the expectation that headers don't need to kick off with a vertical margin along with overflow containment rules to manage that behavior.
I don't know if I've seen using padding values to do margin's job lead to less pain.
Yeah Win32_Product is a disaster, even by WMI standards.
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.
The Netscape of the 90s wasn't interested in making features ‘safe’. They were about throwing out features as quickly as possible to see what would stick.
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
> So 20.04 will likely be my last ubuntu-flavored distro.
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.
The prevalent milk in Germany (originally promoted as “hält länger frisch” et al) is Extended Shelf Life (ESL). It's treated hotter than traditional (HTST) pasteurisation of the type dominant in the UK, but not as brutally treated as traditional UHT.
Personally I'm not a fan of ESL and would seek out the remaining HTST brands, but it's eminently preferable to UHT.
Flexible is a double-edged sword. `querySelector` is bringing in the added complexity of selector syntax, which is more stuff to think about that isn't relevant to what you're trying to do.
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.)
- 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.
reply