iOS does this by default too, but it tells you about it and gives you the option to not strip the location from EXIF: the bottom of the photo picker has the text "Location not included", and the context menu opened by the "..." button on the left has a "Location" toggle. Just tested this myself on iOS 26.4.1.
Does the location messaging also feel more prominent to you from the Photos share sheet compared to the native image file picker? For example, that you would see when uploading to the ImgUr site.
Mainly top versus bottom placement, I think, but also font size.
I just tested this and the default setting is to include location, but once turned off it stays off (unlike the iPhone share sheet where you need to turn it off each time).
WinJS was a bit different, where your app was genuinely just a bundle of JavaScript and a UWP host process dealt with the rendering. (No Electron-esque to deliver with your app) Made for some tiny, succinct apps.
This is why I said Electron-esque. I meant you didn't need a wrapper or renderer of some kind. You literally didn't bundle anything executable, your app was a ZIP of JS files & images that Windows spawned a host process for.
It's funny that Horizon Worlds will shut down before its actual launch here. Meta Quest headsets are sold here but the Horizon Worlds part of the OS was entirely blocked off. (The mobile app shows it, but I could never get the headset to navigate anywhere, just stuck in the homeworld lobby)
Windows SDKs, WDKs (driver dev), Visual Studio releases, and .NET SDKs all coexist peacefully on a machine. If a project build breaks due to newer SDKs, it's because it was configured with "use newest version". (Which is usually fine but sometimes requires pinning if you're using more "niche" things like WDK)
> You don't have to install executables downloaded from an unknown GitHub account named marler8997. You can download that script and read it just like any other shell script.
You do because the downloaded ZIP contains an EXE, not a readable script, that then downloads the compiler. Even if you skip that thinking "I already have VS set up", the actual build line calls `cl` from a subdirectory.
I'm not going to reconstruct someone's build script. And that's just the basic example of a one file hello world, a real project would call `cl` several times, then `link`, etc.
Just supplying a SLN + VCXPROJ is good enough. The blog post's entire problem is also solved by the .vsconfig[1] file that outlines requirements. Or you can opt for CMake. Both of these alternatives use a build system I can trust over randomgithubproject.exe, along with a text-readable build/project file I can parse myself to verify I can trust it.
I've never succeeded on getting a refund with Google. There were a few apps that tricked me into buying a subscription (namely Musescore and Yazio), I immediately asked Google for a refund because I didn't actually get what I thought I was getting, and they denied me both times.
Now I just don't buy anything on the Play store that I can't afford to just be outright scammed on.
The Musescore app is just a minefield of subscription farming, it was somehow miserable even with an existing subscription the number of times it tried to get me to also get their weird AI learning platform. Now I've left it entirely.
> I'm sure "purchase does not work at all" is an exception
Nope, a Play store "support specialist" just told me: "I tried to create a refund request but its not allowing to create one since the date of the transaction is out of our refund policy as we can only process refunds for up to 120 days only after the transaction was charged."
Your credit card company will reverse it for you. A non-working product with unanswered emails will allow you to easily get your money back while also giving the middle finger to Google.
I've done it in the past (~2015). Honestly if Google locked me out of all of those other purchases it'd be great grounds to sue them. If everyone started doing this it would prevent them from doing this in the first place and may be additional fodder for (hopefully) continued anti-trust losses in court. If your life is tied to Google in that way then it's a risk no matter what you do and you should probably think about how to reduce that risk. I don't have anything other than purchases tied to my Google accounts anymore.
It could also just pretend to encrypt your drive with a null key and not do anything, either.
You need some implicit trust in a system to use it. And at worst, you can probably reverse engineer the (unencrypted) BitLocker metadata that preboot authentication reads.
BitLocker recovery keys are essentially the key to an at-rest, local copy of the real key. (I.e., they need access to the encrypted drive to get the real encryption key)
When you use a recovery key at preboot, it decrypts that on-disk backup copy of the encryption key with your numerical recovery key, and uses the decrypted form as the actual disk encryption key. Thus, you can delete & regenerate a recovery key, or even create several different recovery keys.
reply