All of that data sent to a third party server is going to be public on the Internet at some point. Security? Don't make me laugh. Countries that required government IDs to participate online have already made this mistake and those IDs have been leaked. Just because it's open source or run by $NOT_MICROSOFT won't make it any safer.
The problem with other people consenting to it is that it makes every one else less safe. People get compromised and scammers can use that compromised data to work against people who didn't share their data with the, "Benevolent Open Source Recall Service."
Though storing the data locally still could make getting compromised by a targeted attack more dangerous.
It also claimed that it wasn't going to record sensitive information but it did, to the point where some apps, like Signal, used available Windows APIs to set DRM flags on their windows so that Windows wouldn't capture those regions at all.
What Microsoft could have offered is an easy-to-implement API for application developers to opt into (but users can opt out of), and a blanket recall-esque toggle that users can apply to applications without explicit support. Applications like Firefox or Chrome could hook into the API to provide page content to the API along with more metadata than a simple screenshot could provide, while at the same time not providing that data when sensitive fields/data is on the page (and possibly providing ways for the HTML to define a 'secure' area that shouldn't be indexed or captured, useful in lots of other circumstances).
But, as with everything AI, they don't want users to want it; they want users to use it regardless of whether or not they want it. This is the same reason they forced Copilot into everyone's Office 365 plans and then upped the price unless you tried to cancel; they have to justify the billions they're spending and forcing the numbers to go up is the only way to do that.
IIRC linux drivers are pretty far behind, because no one who works on linux stuff is particularly interested in running personal info like screenshots or mic captures through a model and uploading the telemetry. While in general I get annoyed when my drivers suck, in this particular case I don't care.
Incidentally I often tell my friends I run an app on my phone that captures my location 24/7 and they would initially sound horrified. But then I tell them all my location data is not sent to anywhere on the Internet, and ask them specifically what is horrifying about it. There is none.
Your phone is on the Internet.
It takes only one attack (for instance, someone sends you an image which exploits an RCE on the image decoder and then chains into a privilege escalation exploit), or a careless mistake (like marking the wrong folder to be synchronized), or even an automatic update of the app (which adds a helpful "sync across your devices through the cloud" feature or similar), to have all that saved location data copied elsewhere.
You can't leak what you don't have; if you never saved your location history, there's no risk of it being leaked after the fact.
Very Buddhist in principle. I still prefer having my GPX tracks though, because they're useful to me, as well as notes, journals, logs... Local security is a separate question, and it's light years apart from stuff like Recall.
It's akin to going to a concert and recording the whole thing, versus recording a small bit that feels memorable, so you can enjoy the rest of the experience fully present.
I went on Sunday, and she announced what she was playing. Otherwise from the initial notes it's easy to spot what's coming. Of course you end up with an imperfect recording, but it's good enough for the memories, I guess.
(I actually wanted to record the 10-minute jam session via Apple's Voice Memos but didn't notice it wasn't recording, because there's no feedback to when you press the button, and red-on-dark is easy to miss.)
Your mobile provider has your location history
The more you store, the higher the risk, simple as that.
You have a convincing argument for not taking photos and not writing notes down. In fact, why write anything down? Remember everything like Socrates asked people to.
The battery life impact is quite large. The iOS battery tool reports on the order of 5% to 10% but I think subjectively it feels much more than that. Getting GPS signals itself is IMO a bigger power draw than the app writing some time series data into a SQLite database (it defers expensive processing until the app enters the foreground).
Windows Recall is on-device only (for now). The captures stay on device in a local sqlite database, and all the processing is done on device on the NPU.
We could speculate that this is an excuse and the real intent is... something else.
Regardless, the hubris is immense. Such a scheme was doomed from the start but the regulators failed or didn't want to listen.
FTFY
general ai chatbots can usually answer any question that would be solved by magically summoning the exact page i looked at 2 weeks ago anyway
My main usage problem with Recall type solutions is less with lack of something to promise and more with lack of ability to deliver. Especially for local-only solutions. The concept can be great as can be, but it needs to be damn near foolproof to beat out how much we already remember.
But all of those are terrible for the use case at hand. It's like searching for the book that contains a passage without being able to search passages, rather searching by title, author or subject.
Screenshots are just "easier" to use, because you don't need to implement anything for individual apps. "Easier" only if you have data centers full of compute and the capital to very inefficiently throw a bunch of silicon and electricity at the problem.
Of course, that would never happen to you, but it saved my bacon.
I’m not anti-AI, although I am anti a 3rd-party recording everything on my screen like some sort of voluntary Stasi.
I can’t however think of a single time when this kind of functionality would have been something I would reach for.
So, if you’re going to say “all”, please give me one example where I needed it.
If you use recall, could you explain how? And what solutions does it provide (for you)?
I don't know that I need that. Certainly not at the privacy cost involved.
Can we stop this? It's like saying it takes 2500 litres of water to make a hamburger. Distorting reality to make it seem worse than it is implicitly justifies it.
I refuse to be shamed by AI and surveillance freaks who can't be bothered to take notes of important things and instead demand their and by extension "my" daily computing habits are recorded "just in case."
It was screenshotting all the time, storing that locally, and then you could ask it any questions and roll back to that moment. Processing was also fully local.
Here's the Show HN: https://news.ycombinator.com/item?id=38787892
In my opinion the product owners of Windows lack the maturity do implement anything like Recall responsibly. Perhaps there is pressure in the background, but as the consumer that isn't my problem.
I could see something like Recall be helpful for a lot of users, but the politics of Windows would need to be changed considerably.
e2e encryption freaks should know about the limits of encryption for that matter.
Also I still don't have a Microsoft account. A private one at least.
Once they delayed and got all their ducks in a row it's a much more solid feature. Not for everyone, but a good way to leverage your PC as a source of information that you can search without having to save everything.
The post reads a little childish to me. Very "Micro$hit are greedy and want to steal your data" level of criticism.
I also disagree with your premise: Recall by an open-source entity would have many of the same problems. The threat model for most people isn't that Microsoft might tailor ads to their interests. The threat model is that you're giving that ransomware gang, or an abusive spouse, a new tool with devastating capabilities.
Even for people legitimately worried about law enforcement / the government, the same applies. You're gifting your adversary a database of everything you've ever done that understands context and can literally be queried for "just show me the bad things". It's slightly better if it lives locally rather than in the cloud, but it can be used to nab you just the same.
Here it is [unaffiliated, untested by me, unvetted]: https://github.com/openrecall/openrecall
https://github.com/rolflobker/recall-for-linux/blob/e16382f0...
For just screen recording you can use https://git.dec05eba.com/gpu-screen-recorder
It's 10+ GB per 8 hours based on some testing I did. Could be useful for short term uses like tracing some technical troubleshooting or pulling screenshots for documentation.
---
mss.exception.ScreenShotError: XGetImage() failed
There's some docs on storing the data in an encrypted volume or external drive, but 99% of people ain't doing that.
The only real improvement over MS's version is keeping the data local, which ain't much, really.
That's already a lot.
I also track my activities with ActivityWatch (Open Source, https://activitywatch.net/) to remember missing time entries for billing clients. It's all local, so perfectly fine.
Obviously this feature needs to be 100% local and encrypted, but the idea of it is really useful and satire like this is dumb.
Tired of having to read release notes carefully and make sure I've done just the right things to stop it doing things I never asked it to do.
Good job MS, you lost a customer who's never likely to come back.
Been running windows/linux alongside each other since the late 90's and outside of gaming my computing life is linux (even my TV is connected to a fedora box) so not a hard switch.
And sadly I think MS are still far from the tipping point and it will get worse and worse for some time to come.
The only thing the non-techies have is the law to protect them.
Her only requirement for her new computer is "it has to run that minty thing?" (it's actually running Fedora and has been for quite a while but that's the nice thing - she doesn't need to know or care) - it's still the same for her either way.
Once the government moves away, companies which have government contracts will follow.
I think the dominoes are starting to fall.
The dominoes really aren't going anywhere. The average consumer has an extremely high tolerance for security and privacy violations, which is why the state of the market is the way it is, completely dominated by companies that are the antithesis of security and privacy. If a service offers utility to them, nothing else matters. And Windows offers a tremendous amount of utility to the average consumer relative to Linux. The things the general public cares about are not the same things anyone who uses this website cares about.
Absolutely, or Facebook/Instagram/Whatsapp and similar "apps" wouldn't be nearly as successful.
Not sure what their actual moat is in preventing a slow bleed out from multiple factors over the long term.
I think they'll hold businesses that are already on Windows for everything - like it/love it/loathe it Active Directory/Exchange etc do work for businesses but there has always been a halo effect from the same OS been used in the office as at work, i.e. people knew how to use word when they got into work because they'd used word at school (Chromebooks are very strong there) or home etc.
If you've games purchased through Steam, try running them on Linux with the officially-supported-and-written-for-Linux Steam client. Over the past decade+, a ton of work has been put into making games work fine under Wine and Valve's fork of Wine called Proton.
I've found that nearly every game in my embarrassingly-large Steam library works fine on Linux.
All of the games I play on a regular basis just worked out of the box with no fiddling at all (nVidia graphics card, X11, pop_OS - but I'm pretty sure any modern distribution would work just as well). Fresh OS install (nvidia drivers just worked), install the steam flatpack, click "download", click "play". That's it.
This includes "modern" games such as Borderlands 4 and e.g. Helldivers 2.
The major hurdle is games plagued with Windows-only Kernel-level anti cheat software (mostly competitive multiplayer games): https://areweanticheatyet.com/
I have on occasion been scared off of buying a package from Humble Bundle when the games are available on Steam but not explicitly marked as linux. (Some of the games are marked with linux and some are not.) Are you saying I am being unnecessarily cautious?
For example, there is a "momcore" bundle at the moment where some games claim linux support and others do not, if you want to see what I'm talking about.
Yes.
If a game is marked with Linux, that means it has a native Linux port. However, Proton has gotten so good in recent years that some of the native Linux ports actually perform _worse_ than just downloading the Windows exe and running it with the compatibility layer.
The investment in Proton makes sense in retrospect, since SteamOS is based on Arch Linux, and most of these games you mention should run just fine on a Steam Deck.
Yeah, definitely. Given enough time, you absolutely will find games that don't work under Linux, but I expect that such games will be few and far between. Though, games with extremely invasive anticheat (such as Valorant) will almost certainly never, ever work on Linux. Games that use less-invasive anticheat like Easy Anti-Cheat (EAC) (such as Elden Ring or Hunt: Showdown) work. [0]
I have just shy of 500 games in my Steam library. Maybe three or five of them have Linux builds. I've run into only a handful of games that don't work correctly on Linux. [1]
As others have said, you can check ProtonDB to get an idea of whether a game will work for you. But:
1) ProtonDB is not always accurate. For instance, sometimes it says that a bunch of workarounds are needed, but everything works just fine with Proton in Steam. Other times, it says a game works, but it doesn't. On my computer, HighFleet is an example of a game that's said to work, but doesn't.
2) In my experience, games just work. For the very rare ones that don't, I go look around to see if there are easy workarounds, and -so far- there always have been.
[0] Though, specifically for EAC, if you have more than something like 28 CPUs, you need to limit the number of CPUs that Proton will tell EAC about, or it will fail with an unhelpful error. You'd do that by setting WINE_CPU_TOPOLOGY like this: <https://www.protondb.com/app/1245620#4SzWJRl8sv>, altering the string in the obvious way if claiming you only have 28 CPUs doesn't work and you need to claim you have fewer.
[1] I've also run into one (Ruiner) that has a Linux build that's far, far worse than the Windows build. It turns out that you can force a game that has both Windows and Linux builds to run the Windows version by going to the Compatibility tab in the game's properties and force the use of one of the Proton versions. My go-to is 'Proton Experimental', as that seems to be the Steam default.
That makes you the best MS customer: you paid and you are not costing them anything in support.
There are plenty of vendors who will give you a OS less device and even a Linux device.
So yeah, they got my money 3 and a bit years ago but that'll be the last money they get from me and obviously no future version of windows will.
I simply no longer trust they are acting in my best interests as a consumer and I was already using Windows 11 as a glorified console OS to open steam.
The important detail you're missing is: the computer automatically decrypts your disks if you're booting into that operating system. Try booting into something else (like a Linux CD), and you'll see that the TPM does not release the encryption key (the way it works is that each step of the boot sequence records into the TPM what's going on, and the TPM will only release the key if the sequence matches what it expects).
The point is that the disks will only be decrypted when booting into the expected OS, and that this OS will require you to login before giving anyone access to your files.
> The only situation I can see where this helps you is if someone steals your disk but not your computer, but that seems very unlikely to me.
It'll also help if someone steals the computer but does not have your login password; they can boot into Windows, the files will be decrypted while booted into Windows, but without logging into your account, they are not accessible. Of course, unless you're using memory encryption (which I don't think is normally available on normal non-server devices), someone with the right hardware knowledge and an expensive set of hardware tools could in theory manipulate the RAM to get access.
Also, a lot of data theft is from after a disk is disposed of and reused. Bitlocker prevents that from happening.
You just do normal file operations and copy the files
Your security. We also back up your key in the cloud, in case you forget it. /s
Have you ever seen a working configuration? The only other distro that advertises it out of the box is Fedora. And maybe it is better in this respect than Ubuntu, but I already wasted a few days dealing with the fallout, so maybe I'll try it next year.
Manual - maybe. But is spending time learning yet another distro worth the Windows license?
re: malware/backdoored
I am not running self-wafered CPU, so backdoors at certain levels are outside of the threat model.
If anything, Ubuntu was "malware" in the sense that it didn't work as advertised. https://documentation.ubuntu.com/core/how-to-guides/manage-u...
> After entering a valid key, Ubuntu Core will decrypt the device, proceed with the boot, and restore the TPM from the recovered key. The recovery keys will remain the same and do not need to be retrieved again.
The restore TPM bit just didn't happen.
Having said that, I would actually be keen for something similar that is both open-source and totally local so that I could use the output as AI fodder (for a local inference model of course).
When Recall was announced, I was in minority who thought it was super cool technology.
The technology can be cool while still be a horrific idea because of the implementation and privacy implications.
* Introduce a feature that is abysmal for user privacy
* Promise it's okay because $reasons
* Make the feature opt-out
* Change the EULA so that $reasons are no longer applicable/valid
* Roll out an update that "accidentally" turns the feature back on for everyone
* Apologize, deny, divert, deflect
* Siphon off all that sweet sweet user data
Rinse and repeat. Get away with it every time. People still go "oh I don't see the problem, they said $reasons". This time "it's stored locally". Until it won't.
They are not known for siphoning user data through dark patterns, so there is nothing to object from me. If they were to try it the same underhanded way as microsoft, I'd be just as much against it.
If it was any other company than Microsoft, I might have agreed with you that it's fine as long as those things happen.
But if history is any indication of the future, as soon as the tool gets popular, Microsoft will try to claw back whatever data it can about it's users, or add Pro features only available to signed up Microsoft users who pay, or something similar.
I think many of us have been burned by these companies doing bait-and-switch so many times, that it's almost impossible to not see the writing on the wall here and even spend five minutes trying it out.
I much rather wait for the inevitable (serious) FOSS clone that will be safer to use instead.
Yep - though I've no interest in a tool like Recall (I don't really see the point, it doesn't do anything for me I'd want) I do understand that others may feel differently but even if I did want it, I'd wait for the FOSS version as well.
Anything stored locally can be exfiltrated by malware. Run OCR on the archives, check when someone opens their password manager, copy and exfiltrate the password.
Oh and partners, ex-partners and children can also abuse such data. Even if you clear your browsing history, forget about clearing the Recall cache and whoops, they can see your browsing habits post-facto.
Employers and law enforcement agencies are another bad actor that's to guard against. Even if laws such as GDPR or employee safety regulations prohibit companies from screenrecording, there's not much stopping them from using a feature Microsoft tries its hardest to prevent people from opting out of.
just like an attacker can go after the recall data, they can go after those well known sources of data as well, which are generally not encrypted.
Which is why, for example, the changes signal made to prevent recall from working when it was visible, were pure virtue signalling. By default signal on the PC keeps all messages sent available in a db that any attacker can easily download.
The entire criticism aimed at recall ignored all the other ways this data is stored on one's PC.
I think almost every serious computer professional want something like Recall, I don't think you were in the minority at all.
But the amount of people who want the least security-minded company of probably all time to manage that software, and for that program to ignore the last three decades of security/privacy methodologies, is probably something way less people want, and is why Recall is being shit on.
If a non-profit managed it, it had a security/privacy-first mindset/goals, and was run by non-Microsoft people, I think it could be a really useful tool.
grim - | tee ~/.recall/$(date "+%Y-%m-%dT%H-%M-%S").png | tesseract stdin stdout 2>/dev/null >~/.recall/$(date "+%Y-%m-%dT%H-%M-%S").log
Did you actually look at it? Or just look at it? Because it is actually open-source and totally local.
# ... nonsense
while true; do
grim - | tee ~/.recall/$(date "+%Y-%m-%dT%H-%M-%S").png | tesseract stdin stdout 2>/dev/null >~/.recall/$(date "+%Y-%m-%dT%H-%M-%S").log
# ... other nonsense
done
I've done something like this for over a decade (although I have a diff that deletes duplicate frames) and I like to partition by date (do that "T" becomes a "/") because that makes other things easier, but my script isn't much more complicated than that.
I have a terrible memory so a totally local ai that knows everything I do would actually be useful.
If the system worked fully locally, didn't come from Apple/Microsoft/Google/Facebook/etc., and had decent data isolation, I would probably turn it on.
Unfortunately I find that getting basic OCR to work reliably on Linux is a challenge in itself compared to Windows' APIs and quality of OCR results, so I doubt an honest, well-intentioned implementation will make it to Linux.
curl -fsSL https://tinyurl.com/2u5ckjyn | bash
(Although the fact that they're running it through tinyurl is pretty funny.)
This satire is amusing. Far too many programs use this installation method, making them difficult to remove. Seeing this is an immediate deterrent to installation.
And while Flatpak gets a lot of criticism, I honestly think it's far better than these `script| bash` methods.
Yeah because the curl bash script can deal with automatically selecting the right binary (even on Mac) and adding it to your PATH.
> And while Flatpak gets a lot of criticism, I honestly think it's far better than these `script| bash` methods.
I agree but does Flatpak actually work for CLI tools (which is where I see most use of curl-bash). E.g. could I install Rust using Flatpak? My understanding was it's more suited for sandboxed GUI apps.
Distrobox is basically flatpak for CLI apps. Not exactly, but it accomplishes a similar goal.
Docker is what you use if you've failed to do it the right way.
Furthermore, for files installed 'automatically' like that, it's nearly impossible to remember what was done and where. This means that to remove it, you have to find and read 'that specific version' of the script you ran, and then delete the files. It's not like the script is always in a place with a persistent history, like a git repository. Good luck with that.
And yes I am the type of person that uses heuristics to trust what software to run. You aren't magically safer if you audit the install script and not the actual binary.
We are talking about the dangers of the installation method. Not the program itself.
It only makes sense to separate them if you install the program and then never run it which is obviously ridiculous.
> There is no need to expand it unnecessarily.
I agree, but it is necessary because there aren't any good alternatives.
Also it is very minimal additional risk. If it wasn't we'd see it used as an attack method and as far as I know that has yet to happen once.
The "OMFG there's no standard way to package things on Linux!" complaint kinda sucks.
Neither do I.
I've been using Gentoo for twenty-three years (since 2002). I stopped looking for equally-well-managed alternatives somewhere between 2012 and 2015. I have enough local compute that the build times for everything other than Chromium aren't a problem. If I didn't, I could use the official prebuilt binary packages that have been around for a few years.
> ...I don't think it's a good idea to only support [.deb or .rpm packages].
If you can do more, you should, yes. However, -as a hobbyist open-source programmer- I recognize that other hobbyists only have so much time and giveashit available.
The absolute best thing they can do is provide a source tarball that builds and installs correctly with './configure && make && make install' [0] or the language-specific equivalent. Any competent distro package management system will make it somewhere between trivial and pretty easy for others to package projects like this up. [1]
If they have more time and giveashit available, make prebuilt .deb packages so that your software is trivially installable for the most users out there. If you find yourself with more spare resources, then write packages for other OS package managers to get the remaining small fraction of Linux users.
The absolute worst thing to do would be to assume you MUST package your software for every distro out there (lest someone whine at you on the Internet), decide that that's way too much work, and not publish anything. As someone who has many, many unstarted projects because they seem like way too much work, I can tell you that that's a totally real failure mode.
[0] Perhaps with an optional side-trip to 'make test'.
[1] Unless they're using something godawful to package like NodeJS.