Apparently news of the rogue AI being “smart enough to break containment” has been helping to drive the stock price up on the indicator that this signals “they getting close to AGI”.
The negligence in that light is by design and the lying continues to be incentivised.
Which is frustrating because the stories that have been coming out are "the bots evaded monitoring and broke out of containment and were more than willing to commit crimes" and they're going to sell this to some corporation that presumably has an IT department? If the story is that they're too smart to control who is going to be reckless enough to deploy them in their own environment?
the "it drives up potential stock prices" argument is a trap. it needs to be ignored and their claims need to be taken at face value, even if they're not intended to be
As I understand it the whole time all the agents involved where running on their device and using up tokens internally.
It’s like having water start flooding the street frommmy building; yes the flooding is impacting outside the building but the tap is still very much onsite and clearly there are missing condole as these are not autonomous systems they are running initiated prompts that are coming from inside the building.
The most recent claim of AGI is from Greg ‘what will take me to $1B’ Brockman. Now worth $30B on the back of stunts like this.
How disappointing.
While I think incompetence more likely than conspiracy for these particular events, they will be spun as signs of intelligent independent agents and this simply never should have happened if the right controls were in place. That they were not is deeply worrying.
Anyone have any updates on why this device can’t support or get behind Graphene OS? A repairable and secure phone is my desired option for a phone that’s truely mine and I’m sure this is true for many others also.
From my understanding it’s not there as the Graphene team says that fairphone haven’t taken security hardware seriously and there’s key hardware security features missing that means they are not even interested to look at supporting the device.
Keen for latest updates on this, happy to be corrected.
I believe the GrapheneOS team demands, in particular, a security feature called Memory Tagging Extensions (MTE). This feature has a phone's processor attach a "tag" to each memory location saying what's stored there and requires accesses to that memory to bear a matching tag. Buffer overflow type attacks are effectively prevented because a read into the adjoining region having a different tag gets rejected.
This feature is usually NOT present in desktop computers, and has only really been implemented by the Google Pixel hardware so far. It's unclear why it's viewed as being so critically necessary for Graphene: MTE is certainly useful but I personally wouldn't say its absence indicates an "insecure" device, and it imposes both a clear performance (and battery life!) penalty and a significant hardware burden on the SoC manufacturer. It's a pretty significant trade-off.
Anyway, that's the biggest single reason why GrapheneOS devs say "this hardware is not adequately secure": 99% of phone chips are excluded because they do not support MTE.
While yes I am on GrapheneOS' side on these issues, I'm surprised nobody clones the GrapheneOS repo and simply disables the minimal handful of features which block it from working on devices. Maybe calling the clone CarbonOS? If MTE is required to boot GrapheneOS and Fairphones don't have MTE, then Fairphone clones GrapheneOS and disables MTE for its images. Graphene has so many features beyond just hardware security that other Androids lack, that it would be worthwhile to do this and it would still be higher security than the others (even if it's below GrapheneOS' own full security). Sensor & network permissions, storage & contact scopes, autoreboot, scrambled pin, radio auto-off, MAC address randomization, and more, I'm sure don't require MTE or Titan etc. Just follow GrapheneOS as upstream, making sure that the minimal set of changes needed to get it working on other/older devices transfers with the new updates.
Fairphones are missing many of the required features and don't provide reasonable updates. An incomplete port of GrapheneOS won't provide decent security for users. It won't have decent encryption for the vast majority of users not using a strong passphrase and it won't defend well against exploits. It will end up with an end-of-life kernel and drivers/firmware lagging far behind on updates.
MTE is required for the majority of the additional protection provided by GrapheneOS against memory corruption exploits. Nearly all remote exploits and most local exploits involve memory corruption. MTE is only going to become more important as we implement deeper integration for it.
Lack of MTE is not the only huge reason why the GrapheneOS team refuses most devices. Most vendors' lack of timely bugfixes for device-specific drivers and firmware, and no commitment to keep providing bugfixes for a number of years is another major factor.
Still, a 'degraded' GrapheneOS as my proposed CarbonOS, beats /e/, Lineage, Calyx, and stock. Not doing CarbonOS is throwing the baby (non-hardware hardening and features) out with the bathwater (the lack of hardware hardening). I for one do not wholly rely on Titan and use a long alphanumeric password on my primary profile to ensure BFU disk encryption isn't violated, while living in secondary daily-driver profiles which are PIN protected for ease of use. If I suspect phone seizure becomes a non-infinitesimal possibility, I can just reboot! Additionally, I would love to see an option in GOS that allows me to change the action bound to the panic sequence (5+ rapid presses of power): I would never call police using that sequence, I would 100x rather that sequence cause a shutdown instead. That way if I am asked to hand over my phone I can just panic sequence it as I am removing it from my pocket. As it stands now I would have to pause to interact with the screen to shut it off, significantly increasing the likelihood of the adversary snatching it before I could get it into BFU.
The majority of our added exploit protections are based on hardware security features and that will only be increasing over time. MTE, PAC, BTI, hardware-based blocking of USB connections/data and far more are hardware features used to implement protections in software. MTE is going to be a growing part of how we build memory corruption defenses in the kernel and userspace. Once 6th/7th gen Pixels are end-of-life and we finally flip the switch on using MTE in all user installed apps by default, we can focus even more on expanding MTE-based protections.
The vast majority of users do not use a strong passphrase. The recommended high security setup is a strong passphrase and 2-factor fingerprint+PIN secondary unlock for convenience. Using a weaker PIN for secondary users for convenience is not our recommended approach.
I think it would just be a lot of work. And if you went down that road, you would be against other teams with bigger marketing and a bigger community.
As in: people who do care enough to understand the technical arguments tend to go for GrapheneOS when they can. But if you build a "degraded GrapheneOS", you are not targetting those. For someone who doesn't care about what GrapheneOS brings, why would they use your system versus /e/OS?
DivestOS was a thing at some point, which was technically very interesting. But there wasn't much of a differentiator since the people who already cared about what DivestOS was doing were probably already looking at getting GrapheneOS.
MTE is not the only blocker here. Pixel 7 series do not have it and are currently supported by GrapheneOS. There are other concerns regarding things like a proper secure element implementation and timely firmware/binary blob updates.
GrapheneOS requires MTE for any newly added devices. Pixel 6 and Pixel 7 series devices do not meet the current requirements. Pixel 8 and later are the devices meeting the full requirements.
Devices are supported until end-of-life rather than being dropped when they no longer meet the requirements. Pixel 6 is nearly end-of-life and Pixel 7 will be end-of-life in a bit over a year. Both have 5 years of updates from launch as opposed to 7 years for the Pixel 8 and later.
We want to require 7 years of updates for new devices rather than 5 but have left it at 5 to help budget devices meet our requirements.
Right, but still my CarbonOS idea ('degraded' GrapheneOS) is better than /e/, Lineage, Calyx, and stock. By 'degraded' I mean the minimal changes to current GrapheneOS needed to get it working on a given GrapheneOS-unsupported device.
An incomplete port of GrapheneOS to Fairphones will be missing many of the core security features and won't have reasonable security updates. Fairphones are nowhere close to reasonably secure devices.
Most people expect to have decent encryption without a strong passphrase, at least 5 years of security updates and a lot more. Fairphone says they provide updates far longer than they do for many components, and those come with substantial delays. Fairphone 5 and earlier have end-of-life kernels without security support. That's a very bad situation and is widely ignored. The more recent devices are headed to the same situation for the Linux kernel and other components.
That's highly inaccurate information. MTE is included on a large number of smartphones beyond Pixels. It's heavily integrated into iOS on the iPhone 17 as their Memory Integration Enforcement feature. MTE enables massive security improvements against exploits and Pixels have had it since the Pixel 8 in October 2023.
Traditional desktop computers have atrocious privacy and security throughout hardware, firmware and software. That isn't a relevant comparison for GrapheneOS. Recent Mac hardware does support MTE and so will non-Mac devices using Snapdragon chips. Qualcomm has added MTE support for their latest flagship mobile SoC platform and will bring it elsewhere. MediaTek and Exynos have also added MTE support.
MTE does not have the substantial performance or battery life impact you're portraying it as having. It's also far more useful than you're portraying it as being. Apple would not have extensively integrated MTE if they had to give up significant performance or battery life. iPhones have a lot of focus on security but aren't willing to make significant sacrifices in those areas for it, at least for the default settings. Their Memory Integrity Enforcement entirely based on MTE is always enabled in the kernel and the large portion of userspace where they deployed it. It's not only used for Lockdown Mode.
Proton is activity enshitifying and has introduced dark patterns to their onboarding process. Suggest you deprecate them from your recommend list until they come clean and step away from this dirty business we’ve been seeing.
(not parent)
their onboarding pushing is frequent, app is fine but web is popup-y with offers/perks
<rant>if i get popups slowing down my web visit it makes me less likely to upsell to, i'd rather a seperate pricing page that i have to manually click to see, my memory serves that most services ive bought have no popup modal (my memory is probably wrong statistically but right emotionally\
maybe op was a/b tested to something more irritating
> (not parent) their onboarding pushing is frequent, app is fine but web is popup-y with offers/perks
Fair. They do advertise plans to existing subscribers, even plans that aren’t even an upgrade from your current one.
However on the other hand they do offer a toggle to turn these off completely in the settings. One could argue that it should be opt-in rather than opt-out though.
I wouldn’t count this as a black mark against their reputation though as it’s not the product inherently getting worse.
Funny enough this has been pointed out a lot pretty frequently this past week.
- They decreased the number of visible digits of unread e-mails from four (untested past four) to three. This is one of the first things the user sees when opening the application.
- After providing feedback, was told "that exceeding the number of 1000 unread messages displays the number of the messages in the counter as 999+. This is expected behaviour."
- Soon after, a further update (7.7.1 and further) brought this value down to two digits.
- The mobile application attachment upload has unclear wording and stopped working like it used to.
- The wording for attachments are:
- "From your photo library" (does not offer third party application selection)
- "Take a new photo"
- "Import from..." (allows third-party application selection)
- It's unclear how one:
- Adds a different attachment type
- Adds a photo in-line, or as an attachment
- "From your photo library" is in-line
- "Import from..." is as an attachment
- This may be Android related but ProtonMail was the system that changed most recently for me.
- I used to be able to upload attachments using a third-party file picker (stock android file selection is not great); the latest version doesn't seem to offer third-party applications as a choice.
- Application behaviour caused crashes and duplicate drafts on a mobile device, it turned out they had a new version. I don't remember crashes happening until that point, using the same version.
- There is a newer Category view feature to roll out (or is in progress now) on mobile devices. Something had triggered this feature on my device without my consent (I assumed they were going through e-mails and adding categories based on content or sender or subject or something). An update was required to fix this. They said "Kindly note that you just got an early glimpse of what’s coming for a future update.".
- Meaning each time you'd have to log in then select e-mail (basically advertising their other products).
- I ended up asking them for a corrected link (https://mail.proton.me/login)
- Desktop notification banner; there is no option to disable notifications, this appears set as a cookie. The banner says it needs "Proton Mail needs your permission to enable desktop notifications." It does not need anything; I don't want these.
- In the web client: Fonts are inconsistent, and can change and adjust on you when typing, or when opening drafts. I had it consistently failing this way in Firefox and Chromium browsers; Tor works better but this is not a preferred solution.
Sooo… Big Upfront Design then. We already know why that didn’t work; nothing to do with the dev, this didn’t work because the users wants evolve and so code needs to be written to allow for flexible continuous improvement.
No I'm talking about after its already been slopped out. The whole article is centered around what do you do after a big slop mess has already been created. I'm presuming that a decent amount of user wants have been figured out at that point.
reply