Seconded on Tuta. I’m currently pretty locked into the Proton ecosystem, but I have a Tuta account as well, and it’s pretty usable if all you really care about is having an email that works. (haven’t used their calendar yet, so I can’t speak to it)
Definitely less feature-rich than Proton though. Worse spam filter, more basic UI, no auto-categorization of email by topic, etc.
To be clear for anyone who might not want to read the whole article but also doesn’t want to rely solely on the headline:
This isn’t some new surveillance system that was revealed, or even really unprecedented tactics. This was just a larger number of HSI agents assigned to tracking activists, infiltrating meetings and chats, etc than the number previously assigned to investigate suspected foreign influence on the “New Left” and anti-Vietnam War movement. (which had 42 officers at its peak, vs the Minnesota 15 case having 119)
Maybe try Ente then?
Haven’t used it before myself, but I’ve heard good things, and it does have a memories feature, and it seems at least based on the examples on their website that it might generate something more than just “today x years ago”.
Unsure to what degree it works though, and unfortunately Ente is also a paid service (though it is privacy focused, and I believe it has a FOSS app too)
Seems like “Smart Memories” are on the roadmap for Immich though, so you might just have to wait a bit and can then switch once they’re there:
There aren’t really any other mature options out there for self hosted, or even just private Google Photos alternatives in my experience, so you’re kinda just stuck with Immich for the most feature-complete replacement, and Ente for a more “just works” private but not self-hosted one. Everything else is basically just a glorified file browser, but maybe with some smart searching or better media codec support.
Both Tuta and Proton have iOS apps of their own.
I don’t believe either can be used inside the native iPhone Mail app, since they use encryption schemes, which aren’t standard in any commonly used spec for mail apps, so no regularly available mail app can act as a frontend for Proton/Tuta, because no regularly available mail app “speaks” their encryption. (though on PC, Proton does have a Bridge application that can essentially perform the job of a translator in that case, but again, only for PC clients)
One thing to note on this is that after a week, Google told me that my account might be compromised, severed the link between Gmail and my Proton account, and forced me to log back in to my Google account on my computer.
I reconnected to Proton and it did it again a couple weeks later. Not sure if it’s fixed. (or working as intended)
Gmail Forwarding is the old feature that just forwards mail, and that seems to work fine without ever kicking you off, it’s only Gmail Connection (which allows sending emails from your Proton mail and having them send from your Gmail address) that’s done it for me so far.
Proton if you want a clean UI, more fancy features, aliasing, etc.
Tuta if you want just a simple email, don’t care if the UI is a little chunky, and a slightly cheaper price.
100% Immich. Really good UI, and the kinds of quality of life features you don’t normally find in smaller open source apps (auto face tagging, map based on coordinates of photos, built-in non-destructive editor, memories, etc)
The memories feature is mostly just “here’s photos/videos you took on this date”, but it doesn’t compile any sort of custom album based on a theme or place or anything like that. Not hard to do so yourself by just going to the map view and zooming into any location though.
As for image searching it does have that, and I’ve found it to be shockingly reliable even when I run it on just a Raspberry Pi. (though it can take a while to give you the result of your search if you’re on lower-end hardware like that)
I would say if all you care about is having a nice looking, fully-featured, easy to use client, Proton is good, but if you really just need… an inbox with an email attached, then Tuta will be a little cheaper and just as private, just with less bells and whistles.
If you care about removing yourself from other services like calendars, cloud storage, password managers, etc, Proton is way better since it has the full suite.
For example, Proton supports auto-categorizing mail (e.g. newsletters, promotions, updates, transactions, etc), unlimited email aliases, a more modern UI, good integrations with Proton Drive and Proton Calendar if you decide to use those as well instead of Google Drive and Google Calendar, etc.
Tuta is more just an inbox that you can bother to sort as needed, comes with some aliases if you feel like it but probably not enough for every single online service you have, has a basic calendar, but doesn’t have any kind of integrated Drive access (is still in closed beta rn), and has a more… basic UI.
it is a real person, but GPTZero gives it a 100/100, and given she’s a proud “prompt engineer” I’m inclined to believe she doesn’t do all the writing without… “assistance”.
They’re trying to make this a case over marketing and intent rather than materials.
The actual types of filament they’re concerned with are carbon fiber nylon (sold by many brands) and “PLA Pro” which is just a bit better regular PLA.
These are sold by tons of brands all across the internet.
On cars it can of course identify the make and model but it’ll also catalog things like bumper stickers and custom rims for that car.
I think the bill covers that. It additionally states that it’s anything that “identifies, locates, and tracks a vehicle through the license plate or other persistent visual identifier of the vehicle”
While it’s kind of a ban, to be extremely clear, this is not a direct ban!
This would prohibit federal agencies from using ALPRs or accessing data from them, and it would block federal funding for ALPR systems, but locally-funded systems would still be allowed:
https://www.gadgetreview.com/bernie-sanders-aoc-and-jeff-merkley-just-introduced-the-ban-flock-act
I would be concerned about language collapse (i.e. models incrementally forget vocabulary + fail to adapt to new terms leading to language becoming incrementally worse) before I would worry about knowledge collapse
Why so?
The exact same mechanism is on display here. Ask an LLM for information, and it’s more likely to condense an answer, not display additional relevant information, and slowly but surely produce less and less outputs including that given information.
Sources then begin to be generated by the AI model that adds less and less of that information over time, LLMs cite those new sources that don’t include that information, etc, etc, and now that information is just not present in a majority of sources, and is never stated in any LLM responses.
If anything, this is more likely than models forgetting certain vocabulary, because while the underlying tokens for a lot of that vocabulary still exist in the model, the subsequent combinations for a given piece of information are substantially less likely, and the models’ finite size can only store a subset of that actual information in statistical averages. (i.e. you can store the alphabet and a dictionary of every word in the English language, and many simple phrases, in a tiny fraction of what the sum of Wikipedia is, and Wikipedia itself will contain a subset of all information on the internet, and so on, but you can still theoretically write any English content you’ll find on Wikipedia or the internet using that alphabet and dictionary)
What’s wrong with wanting a UI you’re used to?
Everyone wants other people to switch to Linux until they do literally anything a purist wouldn’t do with their own personal setup 😅
all android devices have been using file based disk encryption since several Android versions now.
All Android devices are supposed to support it, but not all do. (or at least, not all do effectively without compromising the cryptographic root of trust by not implementing proper hardware security chips)
I’ll grant it to you on the scopes, PIN changes, etc, but realistically I just don’t think anyone can justify GrapheneOS being something that should be supported on Fairphone given how absolutely desolate the phone looks with regard to any attempt at all to hardware security.
It really depends on what security level you want out of a phone
It does, but that’s exactly my point. GrapheneOS will provide you essentially no more security than any other alternative Android operating system, should it have to operate on a Fairphone with all those features not supported by a Fairphone stripped away.
Unless Fairphone adds more hardware security features that are standard on most other phones, and highly supported on Pixels, installing a heavily crippled GrapheneOS on a Fairphone would get you essentially none of the benefits of GrapheneOS in the first place.
Entirely lacking disk encryption for typical users due to not having a secure element is a pretty major flaw.
It’s also missing hardware accelerated virtualization which is necessary for much of GrapheneOS’s sandboxing, has weak security for other keys in the OS keystore, is missing hardware memory tagging which makes it much easier for apps to use overflow attacks, doesn’t have proper verified boot support once a custom alternative OS is flashed, and leaves exposed debugging APIs even when the phone is locked.
This breaks:
At that point, GrapheneOS can’t physically provide you essentially any security anymore.
It wasn’t just the update cycle either, it’s that they don’t have the physical hardware chips to support Graphene’s minimum requirements for security, which would severely weaken any benefits you actually get from GrapheneOS.
Especially given it has a similar effect to how spam emails are often deliberately bad so they just don’t waste their time with people that waste some of their time before wising up. If you only get the most easily duped people in the first place, that’s a lot less time wasted.
With LLMs, you’re explicitly targeting people that are less likely to strongly ideologically object to things (like LLMs, or genocide funding) on moral grounds, you’re getting the people that are willing to just get a quick answer without having to look into it deeply, and you’re getting the people who’s sole goal it is to flood the web with any SEO-optimized slop they can with the least effort possible.
LLMs self select for people not willing to put in cognitive effort, that are easily influenced and less careful about fact-checking things.
This isn’t the case, though I can see how the article could lead you to believe that.
It’s directly based on password rather than key input. The entire vulnerability is that typing a password longer than 256 characters automatically defaults to
crypt()outputting the*character instead of a normal password hash, which is coincidentally the same default character used as the “hash” (not actually a value you could get from a normal hash, intended to be impossible to get from any normal password for that reason) for the built-indaemonaccount.When the Ars Technica article says “Second, the target system account must be configured to be passwordless”, what they mean is the default
daemonaccount, which has a hash set to*by default, and thus wouldn’t normally be accessible via any hashed password… unless you happen to find out that the system chooses to not make a hash, and just send*if you type more than 256 characters.Look at https://sshhole.com/ if you want the details.