421–430 of 467 posts
Is this supposed to be a joke? The best security of GrapheneOS is useless to people who don't own Don't-be-evil-hardware.
Earlier quoted context omitted.
> security disaster, lacking even basic features for securing your device against tampering and hacking Indeed the GrapheneOS community is known for attacking the GNU/Linux mobile with false claims, https://news.ycombinator.com/item?id=45562484 . Security is a meaningless word without defining a threat model. Try to defend your GrapheneOS against Google, especially these two problems: https://news.ycombinator.com/ite…
GrapheneOS doesnt really proactively attack GNU/Linux. What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted. It makes sense that you care to clarify or correct if you spot people are talking about your project and are (intentionally or unintentionally) spreading wrong information…
Can you be more specific here? I don't see anything like that in my links.
> dont opt for GNU/Linux either given the large code contributions made by Google
You're trolling again, with no reasonable arguments. You can find a reply here: https://news.ycombinator.com/item?id=46176660
> How is GrapheneOS having access to the embargoed patches and being able to ship them a security issue?
This is not the actual issue. The actual issue is that existing patches for a known vulnerability become unavailable, because Google decided so, making GOS potentially insecure. Patches without the source code shouldn't be trusted.
> It would only apply to certified OS that license Google Mobile Services.
Until Google alters the deal.
> Also, that isnt even a security issue. Its a freedom issue.
There is no security without freedom. If you're protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned. You can't protect yourself from Google without having freedom to run what you want on "your" device.
Earlier quoted context omitted.
Investors. Trying to become a new competitor in an established industry often takes a large amount of capital. If you tried to create a business to compete in another industry, you'd also need to find investors or other forms of financing if you are cash strapped.
Investors are not dumb. The current duopoly is entrenched and merely asking for money to create an alternative os won't give you investment. Microsoft and Nokia among others failed big time even though they had plenty of money and competing operating systems. Investors give you money if they think you will be successful and return a multiple of that investment within a reasonable timeframe. You need to solve the 3 pl…
> how you are going to be able to capture market share
gaming
Earlier quoted context omitted.
Google has implemented lots of privacy and security features in AOSP over time. The app sandbox and permission model has evolved a lot, in a good direction. The codebase is also modernized with the increasing adoption of memory safe code. At least Google seemes to have a thought out development strategy to enhance security and privacy, contrary to the projects you mentioned elsewhere in this Hacker News thread. Also,…
Every reasonable, independent organization confirms that Manifest V3 is the end of privacy for Chrom(ium) users, e.g., https://news.ycombinator.com/item?id=29502439 https://news.ycombinator.com/item?id=41871873 https://news.ycombinator.com/item?id=44543660 > It restricts and controls the access of extensions much more. You mean, it restricts users even more and gives to websites the freedom to track you? I won't enga…
Content blocking (ad and "tracker" blocking) are convenience features, they dont foundationally improve security. Defining what a tracker is is difficult and you cant list them exhaustively. Also smart businesses and organisations can just shift to sending all data to the main domain and handling it server side to send it onwards to other domains, including third-party domains. If you dont trust a site to not send data to third party domains directly, why do you trust it to not send it indirectly?
No, I meam it restricts extensions because it does. Vouching for MV2 is like vouching for an Android OS without a proper permission model. MV3 helps against tracking, its good for privacy and security. If you want the convience of content blocking, uBlock Lite still works good enoough for many people. Though, you still lose on security and meaningful privacy (again, define a tracker and list them all, impossible) because extensions in general hurt site isolation and increase your fingerpint.
Earlier quoted context omitted.
GrapheneOS doesnt really proactively attack GNU/Linux. What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted. It makes sense that you care to clarify or correct if you spot people are talking about your project and are (intentionally or unintentionally) spreading wrong information…
> completely wrong comparisons between GrapheneOS and GNU/Linux get posted Can you be more specific here? I don't see anything like that in my links. > dont opt for GNU/Linux either given the large code contributions made by Google You're trolling again, with no reasonable arguments. You can find a reply here: https://news.ycombinator.com/item?id=46176660 > How is GrapheneOS having access to the embargoed patches and…
You made a general statement about attacks from GOS on GNU/Linux. I replied that this happens in the context of wrong comparisons being made.
> You're trolling again, with no reasonable arguments. You can find a reply here: https://news.ycombinator.com/item?id=46176660
Im not trolling. You say you dont trust Google at all. Thats your position. Then my argument is to not trust their code, regardless of which project its submitted to. How is that unreasonable. Your argument is the unreasonable one. You somehow think contributions by other companies to Linux would balance out or erase your trust issues with the Google code? Why would that make any difference.
> This is not the actual issue. The actual issue is that existing patches for a known vulnerability become unavailable, because Google decided so, making GOS potentially insecure. Patches without the source code shouldn't be trusted.
The issue gets patched. Whether the code is published doesnt change the code... People can also sti reverse engineer the code. Its not a black box. Its often just Java code. You can easily decompile Java, bytecode maps easily to the source code. Its an effort you have to do, yes, but so is reading and properly auditing the source code as well. You seem to think publishing the code somehow magically makes it more secure. While that isnt true. People would still need to properly audit it. It barely happens in practice. And it can also perfectly be done with compiled code.
> Until Google alters the deal
If Google were to put the restriction in AOSP, GOS can simply remove it from the code... And if its not in AOSP than it doesnt impact GOS.
> There is no security without freedom. If you're protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned. You can't protect yourself from Google without having freedom to run what you want on "your" device.
This metaphor doenst make any sense in relation to the planned sideloading restrictions. I suggest reading the blogposts from Google about what the process will look like.
Earlier quoted context omitted.
One caveat--you have to be certain that you get a Pixel with an unlocked bootloader. There are a lot of Pixels (mostly sold by Verizon) that are unlocked for use with any carrier, but whose bootloaders remain locked. If you have one of these ex-Verizon phones, there is no way as of now to unlock the bootloader.
This is true, and important. Thanks for the reminder. The list linked above (and the price tag deduced from it) is restricted to unlocked phones only for this reason.
Earlier quoted context omitted.
I worked with ARM boards, I know a bit about it. Booting into Linux is never hard, it's all about using uboot, sometimes with tiny patches on top. I think it's actually even easier with android phones, as you don't have access to the low level bootloader, you just use fastboot stuff. Having basic framebuffer in BIOS/UEFI is neat for toy OSes, but not very relevant for something practical. You gotta need proper driver…
Booting into a mainline Linux kernel on your average junk-level SBC with all the hardware working (without simply sticking to an Android-like downstream/proprietary BSP) is quite hard, and that's what you need in order to make a phone usable as a daily driver. That's really the root issue; mobile phones are built as embedded devices, with no consideration for running a generic OS kernel. This isn't even an Android is…
If drivers are available and you just need to write DTS to configure the driver, that's not a big issue. I don't think anyone thinks that Raspberry Pi has terrible Linux support, despite lack of UEFI, ACPI and all that stuff. Plenty of Linux distros support it well.
Earlier quoted context omitted.
This and also cryptography technology was not nearly as sophisticated and easily accessible as it is today, and where it existed it was pretty slow on the hardware of the time.
How much of it is cryptography? The only notable cryptographic locks are just the TPM-backed Widevine and the infamous Play Integrity, both rarely required due to how many older devices that would lock out. There's no crypto, as far as I know, in all the binary blobs in the kernel, yet we still can't re-implement enough of them to even have a true Linux phone without reusing the manufacturer's kernel.
Earlier quoted context omitted.
Well honestly that's part of the flip phone lifestyle, if someone doesn't want to call me, that's fine, they can send me an email. We don't have to bring Google or Apple into this relationship, it's a choice people make because the prefer texting and being available to everyone they ever met 24/7
> We don't have to bring Google or Apple into this relationship, it's a choice people make because the prefer texting and being available to everyone they ever met 24/7 You're changing the discussion now. The original point is this: Given that people want to be able to text with their friends in what is perceived as a normal way , how can they do it without a smartphone? If you change the rules ("Given that people ar…
Earlier quoted context omitted.
Hacker News Guidelines [1]: > Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data. > Please don't comment about the voting on comments. It never does any good, and it makes boring reading. [1] https://news.ycombinator.com/newsguidelines.ht…
I won't be silent to the obvious honeypotting and mob tactics to silence people around here.
Your repeated unsubstantiated claims about GrapheneOS just don't ring true with my experience as a user across multiple devices for years. It is an excellent AOSP fork, and has numerous security and privacy enhancements. Every time I've asked you to explain your position, you fall back on, "do your own research." I've done plenty and it's why I switched to GrapheneOS and remain on it.
LineageOS is great for its purpose: supporting a long tail of legacy devices. But as a result it is less secure than stock AOSP. Switching a recent Pixel from GrapheneOS to LineageOS is a baffling proposal for all but the tiniest of edge cases.