Earlier quoted context omitted.
I bet the rationale would be "anything over 12 characters will be too hard to remember and people will just write down the password."
Until the late 2010s, the AD account password at my financial institution employer was capped at 12 characters because, for a subset of workers, AD creds were sync'ed to a mainframe application that could only support that many characters.
GrapheneOS – Break Free from Google and Apple
801–810 of 967 posts
Re: GrapheneOS – Break Free from Google and Apple
#802Earlier quoted context omitted.
That's like saying Tulip blocked the installation of Vista because they didn't install enough RAM to run it The OS makers don't have to go out of their way to support a device they don't want to (that's the beauty of open source passion projects), but it's also not like any manufacturer (that allows bootloader unlocking or ships an unlocked bootloader) is blocking GrapheneOS or anyone else from doing it, which the qu…
> That's like saying Tulip blocked I agree, but you are the one who talked about "blocking". I did not :-).
Again, not saying GrapheneOS is doing something wrong. Nobody's under an obligation. Just that, if someone wants to argue that one party is making a problem out of the situation, I don't find it fair to assign that label to every manufacturer on the planet besides google
Re: GrapheneOS – Break Free from Google and Apple
#803Earlier quoted context omitted.
> This is a contradiction. There is nothing "minimal" about a requirement that excludes every device but one. I don't get your logic. Requirements are a choice. It's very easy to create requirements that exclude every device but one. Example: "It has to be the Samsung Galaxy S23". Done. Now you can disagree with those requirements, but that's completely different from saying that the requirements are wrong.
I disagree that such requirements are minimal. Nothing prevents running GrapheneOS on a device with lower requirements. It's a questionable choice by the developers restricting the choice for users.
Re: GrapheneOS – Break Free from Google and Apple
#804Earlier quoted context omitted.
No, they will either immediately or shortly thereafter require you to link a phone number, etc
The original comment was saying: > If you are not in good standing with Google, you cannot bank!! > I cannot stress how inane it is, to have Google or Apple as the gatekeeping to identify verification. How not having an active, in good standing account with one of these two, means you cannot bank. Having to register some phone number (does not need to be your main number, a sim card is quite cheap) to a "fake/unused"…
Re: GrapheneOS – Break Free from Google and Apple
#805Earlier quoted context omitted.
That seems wrong. If malware can fake what the authenticator shows me, the authenticator is broken! It doesn't matter what device relays the code I typed over or otherwise transmits the approval through untrusted networks to the server > The sad reality is that phones (and some tablets) are the only relatively secure computing environments that we have My bank('s authenticator hardware) begs to differ
That seems wrong. If malware can fake what the authenticator shows me, the authenticator is broken! That's not what I am saying. The authenticator is irrelavant to this attack. If your machine is compromised by malware, the malware could take over the browser session, regardless of how you log in. Phones are better protected against persistent malware because every application is sandboxed (harder to escalate) and mu…
The server generates the challenge that's sent to the authenticator. The attacker can modify and replace it by being in your browser and show any text on your computer screen, but the authenticator will either show the truth, or the approval code it generates doesn't match the server's challenge
> That's not what I am saying. The authenticator is irrelavant to this attack.
If you need to change the security measures (take out the authenticator) in order to be able to mount an attack, maybe that means the security measure is working? xD
Trying to understand your point here. If you're merely saying that phones have better process isolation then I can only agree, but I wasn't saying that it doesn't. You can use online banking on your phone OS if you like, or use Android on your laptop. The comment you replied to upthread said that I'd like to have ownership of and freedom within my own hardware, in order to have privacy. When banks require that my phone is DRM'd with some keys from Google, Samsung, or Apple, then suddenly that has a lot of consequences for what I can and cannot do with, or inspect about, the device. Using an external authenticator, which they can attest to their heart's content, is the solution that I'm using and aligns with all parties' goals. Banks don't need to require that everyone's phone is locked down in order to use the banking software, just like it isn't in the browser, while still meeting their security goals
Re: GrapheneOS – Break Free from Google and Apple
#806If you are using social media, you might get a shadowban, just because you needed to unlock your bootloader to install this OS. the OS is great, but too risky in certain situations.
i use social media and have never gotten a shadowban. to the contrary grapheneos actually is very effective against apps like reddit shadowbanning you - if you get banned outright on reddit, for example, you can create a new profile in private space and reddit will not be able to detect that you're ban evading. if you get banned from the profile u use in the app in private space, again, if you just delete private spa…
There's a little bit information here [0].
[0]:https://discuss.grapheneos.org/d/18118-play-integrity-meets-...
Re: GrapheneOS – Break Free from Google and Apple
#807Earlier quoted context omitted.
The founder, afaik, not just a developer. Tor Browser seems to be a project that requires multiple full time developers. I don't think GrapheneOS have the resources right now to do this alongside their OS development, device support and app overhaul plans. Also please don't take this as any criticism of your suggestion, but there have been multiple 'privacy' browser projects based on Chromium for Android. It's a litt…
> 'privacy' browser projects based on Chromium for Android As far as I know none of these projects have tackled the JS fingerprinting problem. The most earnest attempts seem to be Brave and Firefox with the Arkenfox user.js, but they have their own problems. The basic issue is that JS gives websites far too much control over the user's device. The JS spec should have never allowed websites control over the clipboard…
Re: GrapheneOS – Break Free from Google and Apple
#808Earlier quoted context omitted.
I think we (whoever we is) should start normalizing the concept of passphrases; on sign-up screens they should show the benefits of a passphrase. I'm surprised that Googles PW generator does not use passphrases, and I don't know about ios because I haven't tried theirs yet. I started using passphrases after I saw this xkcd https://xkcd.com/936/ When I'm trying to log into something on a device that has a terrible key…
correct horse battery staple; knew it before I clicked the link.
Re: GrapheneOS – Break Free from Google and Apple
#809Earlier quoted context omitted.
Somewhat unrelated, is there any technical reason certain punctuation might be banned? I can understand maybe not allowing letters with diacritics or other NON-ASCII chars but why would a system reject an @ sign or bracket > for example?
Depending on the protocol they can be url encoded or even helpfully html encoded; the same password can be used over different protocols. It's the best to not use punctuation by default (length supplies more entropy than charset), I add -0 at the end to make dumb password policies happy.
Re: GrapheneOS – Break Free from Google and Apple
#810Earlier quoted context omitted.
Depending on the protocol they can be url encoded or even helpfully html encoded; the same password can be used over different protocols. It's the best to not use punctuation by default (length supplies more entropy than charset), I add -0 at the end to make dumb password policies happy.
Sorry I'm a bit lost here. Are you saying requiring a special character and a number are dumb password policies? Wouldn't charset AND length make for exponentially higher entropy? 52 (or 62 for digits) to the length power vs (62+20 special chars) to the length power? Or am I missing something?