Live data from Hacker News

GrapheneOS – Break Free from Google and Apple

blog.tomaszdunia.pl

801–810 of 967 posts

Re: GrapheneOS – Break Free from Google and Apple

#801

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.

Sounds about right. One of Australia's big four banks had the online banking password requirement of exactly six characters for a long time - for similar reasons I assume.

Re: GrapheneOS – Break Free from Google and Apple

#802
post #676
post #599

Earlier 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 :-).

You called it a problem coming from the manufacturers. That implies they actively thwart it (woa, another new word! It's crazy how language works). But they don't actually have a problem with it; some of them are actively publishing the info needed for alternative OSes to work on their hardware and GrapheneOS needs only take it if they want to, but they don't. Who has a problem with whom here?

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

#803
post #680

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

(I agree with you in spirit, namely that GrapheneOS' standards are clearly beyond what most vendors are willing or able to do and a compromise or support of users who want to port the OS might be fitting for the current situation, but notice that the person you replied to never said "minimal", they said "minimum". I'm not a native english speaker but I believe your reading is a value judgement along the lines of "not much work" (in this context) whereas they probably intended it like a statement of fact regarding what the requirements are.)

Re: GrapheneOS – Break Free from Google and Apple

#804
post #386

Earlier 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"…

[deleted]

Re: GrapheneOS – Break Free from Google and Apple

#805
post #604

Earlier 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 authenticator preserves account integrity with the compromised host attack you describe. The device I have shows something like "you are authorising a transaction of 1337€ to RU07BANK012345678, y/n?". What an attacker can do is read along while I log in, but not modify data

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

#806
post #288

If 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…

you're correcting nothing, my business revolves around evading these kind of checks especially on mobile apps. TikTok, for example, it is very aggressive. If you have something different than stock ROM, your reach will be greatly diminished.

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

#807
post #727

Earlier 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…

Fundamentally, almost all "innovation" in browser and JS development for the last 20 years has been about giving new powers to website authors, not to the people actually using the browser. The idea of telling website authors "no, you can't do that" seems to be anathema to browser authors and standards groups. The result is that they make it easy for website authors to wrap their content in shinier and shinier wrapping paper and then tell users how great it is that they can now see all that shininess. Probably 50% of what a website can do today is stuff we would be better off not having available.

Re: GrapheneOS – Break Free from Google and Apple

#808

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

Whoops, I've been pwnd!

https://haveibeenpwned.com/Passwords

Re: GrapheneOS – Break Free from Google and Apple

#809

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

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?

Re: GrapheneOS – Break Free from Google and Apple

#810

Earlier 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?

I guess what they're saying is that, for example, a password of length 12 has about 71 bits of entropy if using an alphabet of 62 characters, and 76 bits with an alphabet of 82 characters. But if you only increase the length by 1 you already get 77 bits with 62 characters only. So length beats adding special chars in that sense.
Post reply on HN