It could also give useful priors for targeted attacks, "Their password is 5 characters, and their daughters name is also 5 characters, let's try variations of that".
Some system accessible to hackers who can see the length of the password /and/ having a single 5 char password has a security of a key under a doormat.
And what kind of support do you think a Linux phone will have? While also having trash tier security. I don’t see that as an issue (for Americans at least since most banks here don’t use NFC/wallets in their apps), just use the web browser to access your bank.
Also GrapheneOS has in my experience decent banking app support outside of a handful of apps (including, ironically, my main bank which disabled GrapheneOS support a week or two ago). There is a maintained list of working apps that you can see for yourself: https://privsec.dev/posts/android/banking-applications-compa...
Does/do your bank/s absolutely always require you to use an app? Is there a desktop/website that you can use? Do they have a brick and mortar location?
Which bank, specifically, requires an app for the purpose of 2FA? Further, what is the 2FA process for logging in to the app itself - wouldn't you need a second form of authentication that's not the app in that instance? If so, is that form of 2FA not allowed when logging in via desktop/laptop?
I inquire because I use multiple different banks, CC providers and financial services, but have never once been required to use an app, even with "mobile" banks like Simple or One.
Sure, just an example ING (part of ING Group, 34th bank in the world according to https://en.wikipedia.org/wiki/List_of_largest_banks only highlighting this to show it's not a tiny random "weird" corner shop) requires to use either their mobile application or ItsMe (details https://fr.wikipedia.org/wiki/Itsme if you want but basically also 2FA as a mobile app) in order to login to their consumer/professional website. You can from the mobile app scan a QR-code which in turn will ask for authentification, e.g. biometrics.
Yes indeed registering the mobile application itself requires first another form of authentication, typically an SMS confirming the number plus a physical card with a physical card reader. You then input the resulting token in the app which validates it and then you don't need the card reader anymore while you rely on the mobile app. AFAICT the physical card reader options is not offered on some mobile payment options. I do not know if they are phasing it out of if it is because another method exists, namely if you have NOT registered their mobile application as a 2FA method, can you still use the physical card and card reader. I do not know that.
To be clear they do NOT require an app per se. They do though if you want to use online services, including payments, bank transfer, reading specific kind of documents, adding specific recipients for recurring transfer, transfer above thresholds, etc.
Hope it helps. If I missed something happy to try to clarify. Also FWIW and AFAICT it's getting more and more common for online services from bank in the EU.
I think you are both kind of wrong :). There are different Play Integrity levels. GrapheneOS passes the basic level, which is enough for many apps, including a bunch of European banking apps. GrapheneOS does not pass the strong level, which does remote attestation, but Google does not want to add the GrapheneOS signing key fingerprints.
My European banking and credit card apps work fine on GrapheneOS because they don't require the strong integrity level.
Google is using Play Integrity at the strong level to shut down competition. It's kinda ironic, since GrapheneOS is much more secure than the many phones out there with abysmal device security and slow updates that Google does accept with strong integrity.
Yeah you're right, serves me right for writing that while busy doing other things this morning.
The intent of the comment stands though.
I meant to point out that GrapheneOS has perfectly good support for verifying device integrity via Hardware Attestation, just not the method which requires Google to acknowledge the OS signing keys.
Then keep Google crapphone for banking purposes in your drawer, like auth scratch code cards in the past.
I don't get that idea of carrying device with bank access in your pocket constantly.
Moreover, at least in EU, there is more and more banks which publish their apps in non Google app stores too.
All Swedish banking apps work without issue and many apps that use play integrity works well regardless. It's just some apps that use play integrity that in a certain way that doesn't work.
Related to this, I highly recommend anyone to install github.com/ActivityWatch/activitywatch, it's an amazing tool to keep track of your computer use completely locally. I think there are lots of possibilities with data analysis/AI aimed to improved one self's life
This Christmas I bought my mom a new computer because her old one (W10) was falling apart. It took some time but I managed to convince her to give ubuntu a try instead of moving to W11. After a week of complaints and stubbornness, she got really surprised about the lack of annoying prompts asking for updates, dark patterns to switch to edge, promotions etc. Now she has fully adapted and for her basic needs (browsing, reading pdfs, editing spreadsheets) she's basically set for life
It's shocking to read the headlines about the latest direction windows is taking and how user unfriendly is becoming
To me it's very clear that the icons have that "stable diffusion trying to make pixel art" style. I think this needs an extra layer of code that gets the generated image and turns it into actual pixel art
Incredibly fast, on my 5090 with CUDA 13 (& the latest diffusers, xformers, transformers, etc...), 9 samplig steps and the "Tongyi-MAI/Z-Image-Turbo" model I get:
It stays around 26Gb at 512x512. I still haven't profiled the execution or looked much into the details of the architecture but I would assume it trades off memory for speed by creating caches for each inference step
Super interesting project, at first I thought it would be a naive implementation of YOLO but I wasn't aware about retro-reflections. The papers he linked in the GH discuss very interesting ideas
reply