> After all we wouldn't talk about Dropbox being sold resulting in ransacking of your personal data why is that in the conversation with 23andme?
Both 23andme and Dropbox's privacy policies only require them to notify users if the privacy policy changes (no restriction on scope of those changes), so maybe we should (if Dropbox were to be sold)?
I have a round analog clock with a particularly strange arrangement: it has a second hand (that ticks every second), and it has a minute hand that only moves every fifteen seconds.
(It's a radio-controlled clock: it has the second and minute hand on separate motors presumably because syncing to the actual time if there were only a motor for the second hand like a conventional analog clock would take too long (and probably make determining position more complicated). There is no independent motor for the hour hand, so it does have to roll the minute hand around to move that one.)
The original GBA models (including the SP) did actually feature a Sharp SM83 (the Z80-compatible CPU used in the GB and GBC) for GB/GBC backwards compatibility.
It was never accessible by GBA games (or at least intended to be accessed, so to my knowledge no official titles did), and so the Game Boy Micro and the DS and DS Lite, which both feature GBA but not GB/GBC backwards compatibility, could drop it without causing any problems for GBA games.
The Game Boy Micro still contained a useable SM83 and GBC PPU on the SoC, but the cartridge is inaccessible. In theory you might be able to run a tiny payload from WRAM (32KB?) but it's pretty useless otherwise.
The A17 Pro (originally in the iPhone 15 Pro; now also in the iPad Mini) and A18 Pro (currently only in the iPhone 16 Pro) are the only chips Apple has produced with a "Pro" suffix.
Apple used to use the X suffix for bigger versions of their phone processors that went into iPads (starting with the A5X); that went away when the M-series was introduced.
And the "Pro" suffix itself doesn't seem to denote anything in particular-- there was never a non-Pro A17, and the "A17 Pro" going into the iPad Mini is itself a cut-down version of the chip that went into the iPhone 15 Pro (it has one GPU core disabled).
Monopoly was patented-- in 1935. So that's long-expired.
And many of the non-Hasbro -opoly games (that use that as part of their name) actually are licensed. Hasbro's been known to go after unauthorized users of the name for trademark infringement.
WSL2 is "just" Linux running in a Hyper-V VM (with some special sauce on top of it to handle things like interacting with the filesystem or doing Wayland and X11 graphics, plus containerization stuff to allow multiple distributions to be installed and run under one VM and one kernel).
WSL1 was a completely different approach, adding a Linux compatibility layer to Windows itself. There, you never had a Linux kernel running at all-- Linux syscalls would call into WSL, which would talk directly to the NT kernel to do whatever that syscall needed to do.
WSL1 didn't last very long (still present, but not actively being developed)-- turns out that reimplementing one operating system on top of another is a Hard Problem (see also: Wine). WSL2 avoids this entirely, and also avoids most of the impedance mismatches that you get when trying to reimplement POSIX on top of NT. WSL2 solved a whole bunch of compatibility problems essentially overnight that WSL1 never even got around to.
Windows 10 only does 16-bit DOS and Windows apps on the 32-bit version of Windows 10, so it only has a VM layer for those 16-bit apps. (On x86, NTVDM uses the processor's virtual 8086 mode to do its thing; that doesn't exist in 64-bit mode on x86-64 and MS didn't build an emulator for x86-64 like they did for some other architectures back in the NT on Alpha/PowerPC era, so no DOS or 16-bit Windows apps on 64-bit Windows at all.)
Unlikely. Localhost can be a secure context because localhost traffic doesn't leave your local machine; .internal names have no guarantees about where they go (not inconceivable that some particularly "creative" admin might have .internal names that resolve to something on the public internet).
One can resolve "localhost" (even via an upstream resolver) to an arbitrary IP address. At least on my Linux system "localhost" only seems to be specially treated by systemd-resolved (with a cursory attempt I didn't succeed in getting it to use an upstream resolver for it).
So it's not a rock-hard guarantee that traffic to localhost never leaves your system. It would be unconventional and uncommon for it to, though, except for the likes of us who like to ssh-tunnel all kinds of things on our loopback interfaces :-)
The sweet spot of security vs convenience, in the case of browsers and awarding "secure origin status" for .internal, could perhaps be on a dynamic case by case basis at connect time:
- check if it's using a self-signed cert
- offer TOFU procedure if so
- if not, verify as usual
Maaaaybe check whether the connection is to an RFC1918 private range address as well. Maybe. It would break proxying and tunneling. But perhaps that'd be a good thing.
This would just be for browsers, for the single purpose of enabling things like serviceworkers and other "secure origin"-only features, on this new .internal domain.
> One can resolve "localhost" (even via an upstream resolver) to an arbitrary IP address. At least on my Linux system "localhost" only seems to be specially treated by systemd-resolved (with a cursory attempt I didn't succeed in getting it to use an upstream resolver for it).
The secure context spec [1] addresses this-- localhost should only be considered potentially trustworthy if the agent complies with specific name resolution rules to guarantee that it never resolves to anything except the host's loopback interface.
No, you can't. Besides the /etc/hosts point mentioned in the sibling, localhost is often hard-coded to use 127.0.0.1 without doing an actual DNS lookup.
You shouldn't do this if you value things working, though-- this is a pretty rare configuration (you have to go way out of your way to get it), so many developers won't test with it and it's not unheard of for applications to break on case-sensitive filesystems.
If you absolutely need case-sensitivity for a specific application or a specific project, it's worth seeing if you can do what you need to do within a case-sensitive disk image. It may not work for every use-case where you might need a case-sensitive FS, but if it does work for you, it avoids the need to reinstall to make the switch to a case-sensitive FS, and should keep most applications from misbehaving because the root FS is case-sensitive.
Most things work fine, but it will break (or at least did break at one point) Steam, Unreal Engine, Microsoft OneDrive, and Adobe Creative Cloud. I'm rather surprised about the first two, since they both support Linux with case-sensitive filesystems. I took the opposite approach as you, though: making my root filesystem case-sensitive and creating a case-insensitive disk image if I ever needed those broken programs.
I keep a case sensitive volume around to checkout code repositories into.
For everything else I prefer it insensitive, but my code is being deployed to a case sensitive fs.
Both 23andme and Dropbox's privacy policies only require them to notify users if the privacy policy changes (no restriction on scope of those changes), so maybe we should (if Dropbox were to be sold)?