Contact: @Sominemo
Other links: @dilongs
Post #36
169
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.
- ❤ 2
- 👍 1
- 😁 1
Channel Public Channel
GR Green Broadcasting
@castgreen
- Subscribers
- 51
- Photos
- 22
- Videos
- 1
- Links
- 29
Showing posts older than #37 · Back to latest
Older Posts 18 shown
Post #35
190
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.
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
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
- ❤ 4
Post #34
137
Green Broadcasting 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.
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.
Post #33
139
Winaero 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…
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.
- 🤯 1
Post #32
137
Forwarded from Winaero
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.
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.
Post #31
138
Green Broadcasting 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…
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.
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.
- ❤ 5
- 🤯 2
Post #30
132
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.
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.
- ❤ 3
Post #29
98
Green Broadcasting 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…
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.
Post #28
105
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.
Also if developers want to continue supporting iOS versions before 26, they have to implement custom glass or introduce a fallback for older systems.
Post #27
167
Some ccTLDs can be re-sold before expiration date
I learned that some ccTLDs can sell your domain before its actual expiration date:
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.
UPD. Another example of a thing to watch out for — .in (India) disallows having any domain privacy, you must have your IRL data public in WHOIS.
Namecheap TLDs' grace periods - Domains - Namecheap.com Learn more about TLDs' grace periods. Find your answers at Namecheap Knowledge Base. 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.
UPD. Another example of a thing to watch out for — .in (India) disallows having any domain privacy, you must have your IRL data public in WHOIS.
- ❤ 1
- 👍 1
Post #26
245
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/
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/
- 💊 1
Post #25
128
Green Broadcasting 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.
Post #24
137
GitHub completely killed the old feed by replacing the old endpoint with the new feed that I don't like 😞
- 😢 3
Post #23
185
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.
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.
- ❤ 3
Post #22
258
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.
"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.
- 👍 2
Post #19
247
Facebook Messenger added required end-to-end encryption. If you don't opt in, you won't be able to read your own messages across devices.
I love end-to-end encryption that purely relies on a numeric pin code, it will be so hard for Facebook to guess my 6-digit pincode with unlimited attempts if they ever want to read my correspondance.
Or is it to prevent hackers from accessing messages? Well we had a tool for that, it was called Passwords and Passkeys!
Explainer: This way of making end-to-end encryption is useless and it would have been better if they just didn't do it at all then.
I love end-to-end encryption that purely relies on a numeric pin code, it will be so hard for Facebook to guess my 6-digit pincode with unlimited attempts if they ever want to read my correspondance.
Or is it to prevent hackers from accessing messages? Well we had a tool for that, it was called Passwords and Passkeys!
Explainer: This way of making end-to-end encryption is useless and it would have been better if they just didn't do it at all then.
- 🐳 1
Post #18
245
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
- 🤩 6
- 🏆 1
Post #17
308
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)
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)
- 👍 1
- 😁 1