UPD: old method was re-activated on stable release

In macOS 15 Sequoia Apple changed the way you permanently disable app notarization check.

To run a non-notarized app you now have to either:
- Every time go to Settings > Privacy & Security and confirm the app there.
- Disable Gatekeeper permanently using a management profile.

I suggest using Sentinel which helps you installing the profile. You can also grab the profile directly from the repo, but the app also allows to un-quarantine apps, which is useful.

The app: https://github.com/alienator88/Sentinel
Direct management profile link

For the old methods that used to work:
- spctl global disable to disable gatekeeper permanently was removed
- Option + click to bypass gatekeeper one time was removed

USB-IF, what's wrong with you, why can't you name a single thing in a humane way

https://www.techspot.com/news/105025-lunar-lake-allegedly-smokes-z1-extreme-handheld-gaming.html

You can't properly report Chrome Web Store extensions for malware anymore.

I went through the same route as the author of the post — there is just no way to explicitly report malware, only options are "Felt suspicious" and "Not trustworthy" with no details field.

https://palant.info/2025/01/13/chrome-web-store-is-a-mess/

It's not open source, it's open weights, ML people should stop misusing the term.

Providing weights for a model is like providing a binary. Just because I can run it on my computer, it doesn't make it open source.

https://fixupx.com/LTXStudio/status/1919751150888239374

Or was it really WhatsApp?

About a month ago a website called iGuides made an article about how Telegram is degrading.

Today Pavel Durov made a post[ru] in his Russian channel with screenshots of two Telegram channels with identical criticism of Telegram. He claims these posts are paid for by WhatsApp and that it's WhatsApp's campaign against Telegram.

iGuides authors noticed[ru] that the text and images from these posts are stolen from them. The title from the iGuides' article noticing the issue words it as if WhatsApp itself indeed has stolen their content for their promotion materials. I would disagree that this is likely. The rest of the article doesn't claim so, though, and just recites Durov.

One of the iGuides authors notes[ru] (seems to be their personal channel, I can't find the source from the screenshot) that the two channels on screenshots are just content farms that never produce anything original. I agree with this analysis.

Now I will have to be a bit rhetorical here, but do you really think WhatsApp's marketing people would buy negative PR posts on content farms using stolen material? Durov only provided two examples, and I can't extrapolate that this is a massive PR attack just from this.

It would be easier to explain it with content farms, in their typical fashion, simply stealing content from iGuides. By the way, both channels seem to be related, as they have the same account specified as "Manager".


Now why would Durov post this then?

a) He just wants to look better in the eyes of investors, especially considering an IPO is probably coming[ru];

b) Durov is getting more and more detached from the reality by the day, preferring to draw a conspiracy theory over accepting valid criticism;

c) This is genuinely a massive PR attack and Durov is bad at proving his position.
e.g. There's still a chance iGuides was contracted by Facebook to write the article too, that gets reused for other promotional materials, and they wouldn't admit this is the case and would rather say the article was plagiarized. But this would mean jumping through a lot of hoops for Facebook, and iGuides' behavior doesn't check out here, because if this was indeed marketing material they were contracted for, they would unlikely bring public attention to plagiarism here.
Or maybe the mentioned channels were paid for any negative PR and the channel admins were left with the task of writing the message on their own, and they just plagiarized it, like they typically do. I should note this option is very unlikely though, because advertisers very rarely leave writing the text to the publishing channel.

Also note that Meta was labeled as a terrorist company in Russia and it's extremely dangerous for any Russian to have any financial ties with them. I doubt iGuides or the mentioned channel admins would agree to this.

—
Additional notes: "Jobs' iPhone" channel post (11th of March, 5:44 UTC), "Apple News" channel post (11th of March, 7:06 UTC, Deleted 10th of May, 16:53 UTC)

if you send a iMessage voice message containing an ampersand it won't be delivered due to XHTML formatting error when transcription is added to the message

SnapDrop and a bunch of other P2P services acquired by a cryptocurrency scam company

"LimeWire GmbH", a company that sells NFTs and "AI" under the name of the deceased P2P file-sharing software, decided to aggressively acquire a lot of independent P2P file-sharing websites.

I am very used to recommending snapdrop [dot] net whenever anyone seeks a wireless P2P transfer between multiple devices. It was a browser app that would establish a direct connection between devices on the same network by the shortest path (the local network) to transfer files or text.

Today, when recommending the website yet another time, I found out it was put into a uBlock filter, and this is how I learned the website was sold.

From this GitHub issue, I also learned that a few other similar services were bought out, so the list of services to avoid (probably incomplete) is:
sharedrop [dot] net
sharedrop [dot] io
file [dot] io

Users also report that the code of the services was covertly changed to always use transfer through LimeWire's "cloud", with no P2P functionality.

The current best alternative to this service seems to be the pairdrop.net fork, that also has some UX improvements.

I don't understand Google's threat model for Android.

It assumes that it is more safe to either:
- Use stock outdated ROM
- Use custom rooted ROM with Magisk to hide tainted bootloader
- Use custom ROM with intentionally neutralized SafetyNet that always passes

Rather than using an updated custom ROM with self-signed locked bootloader that will actually trigger SafetyNet if malicious software will tamper with it.

Play Integrity API (SafetyNet's successor) has green status for fully verified, yellow for "you have a locked bootloader but you're on a custom ROM/self-signed", and orange-red for everything clearly bad. But the presence of the yellow state incentivizes developers to not trust anything below the green, and that's what happens in the real world.

Unless I'm missing something, I think it would be better if Google would get rid of the yellow status and considered self-signed to be green.

— cynical mode —

Or it's just a way to control the ecosystem and these decisions are in no way influenced by the security people but the management.

This is a repost of my old post that I need to reference regularly.

GitHub completely killed the old feed by replacing the old endpoint with the new feed that I don't like 😞

Well they say there are some differences to the new feed at the old endpoint but really they just made it worse.

Some details arrived about the Android Developer Verification.

It won't use Play Protect, but will be a new service, for some inexplicit reason. There are some speculations in the article as to why it could be done this way, no way to say for sure at the moment, though.

Confirmed that ADB will be left alone, you will still be able to sideload through it.

Still no details if the thing can be turned off completely. If it won't be possible, I'm afraid that's still a death sentence for things like F-Droid.

There is hope that since it will be distributed as a separate package, maybe it will be possible to turn it off completely by disabling the verification package in ADB.

https://www.androidauthority.com/how-android-sideloading-restrictions-may-work-3595355/

Some ccTLDs can be re-sold before expiration date

I learned that some ccTLDs can sell your domain before its actual expiration date:

The .CH, .ES, .FR, .LI, .PE, .SG, .COM.SG, .COM.AU, .ORG.AU, .NET.AU TLDs must be renewed 12 days prior to the actual expiration date. If not renewed, the domain will enter the redemption stage right away regardless of the number of days left until expiration.

This is why I'm always very hesitant to get ccTLD domains, they often have stupid rules and you can easily lose the domain.

I learned this from a situation where a fediverse's service .pe domain was resold to be converted to a spam blog.

Let this serve you as a PSA to double check all policies and existing user experiences very carefully before getting a ccTLD domain that you want to rely on and can't afford to lose.

Apple provides no official specification and/or reference implementation for Liquid Glass, which just calls for more design inconsistency on their own platform if developers use anything but SwiftUI/UIKit/AppKit.

Also if developers want to continue supporting iOS versions before 26, they have to implement custom glass or introduce a fallback for older systems.

I'd also like to amend before anyone says this, yeah, I agree that using native frameworks is actually superior and developers should prefer them, but I doubt that liquid glass consistency concerns would push many developers into adopting the native frameworks, so Apple should be interested in providing guidelines that at least help maintain design consistency.

In macOS 26 Apple enforced the squircle shape for app icons. If an icon doesn't match the new format, it gets "plated" with a gray background.

I noticed that a few apps that weren't updated for a while had their icons shown without extra plating. This surprised me, since all macOS icons before version 26 are transparent images with graphics and shadows baked in.

It seems macOS 26 automatically detects if old app icon image uses the official icon template and doesn't have any protrusions.