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.

Also something I noticed when researching this, besides altering the frame shape and adding a border around it, macOS 26 will do edge detection on the app icons and will add effects like gradient and shine to them.

If you open the app package properties and copy the icon from there, you will get the icon with system effects baked into it, not the source icon stored in the package.

It is all over. Google has discontinued its Privacy Sandbox APIs intended to replace third-party cookies in Chrome and Android. The company initially planned to phase out third-party cookies by 2022 but delayed the move repeatedly due to industry resistance and low adoption of alternative technologies. In spring 2025, Google abandoned the cookie deprecation initiative altogether. Six months later, it also decided to halt promotion and integration of many associated privacy-focused APIs.

The discontinued technologies include IP Protection, Topics API, Attribution Reporting, Private Aggregation, Shared Storage, Protected Audience, Related Website Sets, requestStorageAccessFor, Related Website Partition, Select URL, Protected App Signals, SDK Runtime, and On-Device Personalization. Google will retain only those APIs already implemented in other browsers: FedCM for privacy-preserving identity management, CHIPS for partitioned cookie storage, and Private State Token for bot detection without cross-site identifiers.

Cookies remain alive.

This is great news! Privacy Sandbox was neither private, nor a sandbox, despite its name. All these APIs would just promote sharing extra data with advertisers.

I suspect they did this because they decided to not get rid of third party cookies in Chrome, so all the smoke and mirrors called 'Privacy Sandbox' are not needed anymore.

Turning off third party Cookies in Chrome is still much easier than the convoluted misleading menu Privacy Sandbox was. Though I'll still recommend my peers to not use anything that doesn't support uBlock Origin.

On Pavel Durov's Decentralized LLM Compute Network

Pavel Durov announced an open network that would give out TON cryptocurrency for GPU compute.

Let's set aside the use of cryptocurrency that is volatile as heck and additional overhead of distributed computing for already quite power hungry hallucinating text prediction machines. I want to scrutinize the security of the concept.

The more likely approach:
They can employ Trusted Execution Environment present in NVIDIA GPUs. You encrypt your data with an Nvidia key, and only a genuine Nvidia graphics card can decrypt it. It won't give you, the card owner, the decrypted data, but will encrypt the result with the user's key.

Edit: This is a gross simplification of the process. Actually, you deploy an image onto a remote machine that runs on CPUs TEE, and from it, using NVIDIA's SDK you can also verify that the GPU is real. Prompt encryption/decryption can be implemented inside the image. All communications between your image in the CPU TEE and GPU TEE are encrypted. This way you can also get proof that the GPU runs the model it claims to be for free. Of course, you don't store the key in the image, you do DH key exchange as it runs (maybe, you use user's public key hash as nonce for the TEE Attestation Report to avoid MITM attacks, since there is no CA here but the vendors).

The only problem is that if a single one of these cards gets hacked, it will unleash absolute hell across the entire network 🙂 (in other words: it is not good if even a single node node in a zero-trust network can read your messages)

There is a fool proof solution to this problem that I was very sceptical about until this day, when I decided to finally look into it. It's called Homomorphic Encryption.

It allows you to do neural network inference on encrypted data without actually being able to read the data. Yeah, it might sound insane, but after reading into it and understanding key concepts, I think it's probably fine. But it's also probably not what's gonna be done in this project for reasons described below (TL;DR — Impractical on large scale).

This section requires you to have basic understanding about how neural networks work.

So this announcement made me look into how neural networks work with homomorphic encryption, as it's the only reasonable way to implement such a feature without leaking all user communications to random people on the internet or hoping on a vendor.

In short:
1. There's a way to encrypt two numbers, do addition or multiplication on them, and then get the correct result back on decryption. Do your own research, if curious.
2. Generative transformers with attention algorithms (esp. important — activation functions) can be approximated by using polynomials, which is just adding and multiplying numbers.
Combine these two and you can run an LLM on encrypted data, and get encrypted output back, that only the creator of the data can read!

Yes, instead of 0..1 range you get huge numbers, you can't tell if the neuron is a 1 or a 0, but because we approximate all the neuron logic with the allowed operations, the math guarantees the result to be correct on decryption (to a certain precision)

This method is well-suited for relatively small models, or models that can be given a long time to think in the background. Stuffing DeepSeek into FHE will either result in a very bad and slow model, or a very expensive but still slow model that requires a ton of resources and simply cannot be optimized with modern MoE tricks; it has to be a dense model, where every neuron is evaluated. It also means you can't have dynamic output length using the end of output token, you'd have to generate a fixed number of tokens for every request.

It's almost certainly not the way they are gonna go with, though, they'll probably just use TEE, will be sending your conversations with the LLMs to random people on the internet, and you'll just have to pray that the random node isn't an NSO Group honeypot with a jailbroken CPU/GPU.

There's a chance we'll get distributed LLMs in the future, but not today

Designers need to realize that in UX the only thing worse than no customizability, is the unpredictable automated customizability you can't opt out from.

Lol nice, something I've spent a bit of time on to piece together is now available to read in a single place as a long spec!

https://github.com/openpcc/openpcc/blob/main/whitepaper/openpcc.pdf

One more reason why Safari sucks for web developers:
It deletes all local site data if the site wasn't used for 7 days.

I guess it could have been relevant back when cross-origin talk was allowed in Safari at all. It is not anymore. But the behavior is still here.

If you've made a web To-Do app that uses localStorage/IndexedDB/..., your user creates a list in there, and 8 days later it's all gone — that's the reason.

And it is not part of standardized behavior, you have to know about this quirk and use one of the methods to ask the user to persist the data. Or create an auth system and store everything on server.

https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

Safari is the modern IE.

Android Quick Share now works with AirDrop on iPhone, starting on Pixel 10 by Abner Li

https://9to5google.com/2025/11/20/android-quick-share-airdrop-pixel-10/

MPEG LA (now is VIA LA, I guess) using all their cosmic powers to make sure their new codecs receive zero adoption.

https://arstechnica.com/gadgets/2025/11/hp-and-dell-disable-hevc-support-built-into-their-laptops-cpus/

Whoah, finally Google will allow you to change your Google Account @gmail.com email address without deleting Gmail.

https://9to5google.com/2025/12/24/google-change-gmail-addresses/

Since day one, Google Chrome used to just update. Silently. You open Chrome and return to your last tabs without realizing it was updated [unless you notice they redesigned something].

But since a few years ago Chrome team decided it's important to show users a toast "Chrome was updated". OK, why would I care?

Or even worse, instead of opening my last tab, it opens the What's New page. There is no option to turn it off.

Users open browser to do what's on their mind, not read your changelogs.