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.
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.
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.
* 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.
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.