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/
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/
Almost Secure
Chrome Web Store is a mess
The post details Google’s lax enforcement of their policies in Chrome Web Store, resulting in a flood of spam submissions, add-ons “legitimately” stealing users’ data and outright malicious extensions not being addressed. At this point Chrome Web Store is…
🤩3
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
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
🧵 Thread • FixupX
LTX Studio (@LTXStudio)
Today we’re introducing our latest open source video model—and it’s a big one.
This release sets a new bar for speed, quality, and control. It’s faster than anything in its class, packed with new features, and ready to run on your own hardware.
Let’s break…
This release sets a new bar for speed, quality, and control. It’s faster than anything in its class, packed with new features, and ready to run on your own hardware.
Let’s break…
👍3
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
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
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
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
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
GitHub completely killed the old feed by replacing the old endpoint with the new feed that I don't like 😞
😢3
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.
The GitHub Blog
The dashboard-feed page gets a refreshed, faster experience - GitHub Changelog
We’ve updated the /dashboard-feed page on GitHub.com to align with improvements to the homepage “For you” feed, bringing a more consistent and performant experience across GitHub. What’s new Faster, more…
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/
Android Authority
Google's plan to restrict sideloading on Android has a potential escape hatch for users
Android will block users from sideloading apps made by unverified developers next year, but we may have found a workaround.
💊1
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.
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.
Namecheap
TLDs' grace periods - Domains - Namecheap.com
Learn more about TLDs' grace periods. Find your answers at Namecheap Knowledge Base.
❤1👍1
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.
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.
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
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
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.
Winaero
Google Turns off Key Privacy Sandbox Technologies
Google has announced the discontinuation of multiple Privacy Sandbox APIs previously developed to replace third-party cookies in Chrome and Android.
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
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.