I've given up on coding personal projects because it feels like I could be doing them faster with AI and I just don't care to bother. Completely killed coding as a hobbyist for me. Still have a senior dev job... for now.
YouTube is really the thing that got me - the thing is it's not bad content, I don't watch slop, I watch quality stuff from interested, passionate individual creators and I could listen to them talk about their interests all day.
It doesn't wreck my day or make me feel anxious or anything, no doom scrolling involved, but it sure can turn into a huge time sink very fast.
Have you considered being less puritanical about these requirements? Surely there would still be strong benefits for many users on other devices which would only be able to run if these were relaxed.
Our requirements are for industry standard privacy/security patches and protections. We haven't set a high bar but rather have very reasonable requirements. There's nothing puritanical about requiring what we do for a privacy and security project.
Most people don't have a device permitting using another OS at all or without crippling functionality including security. They need to buy a device to use another OS as a production quality daily driver. The vast majority of GrapheneOS users bought devices to use GrapheneOS rather than using GrapheneOS because it was available for a device they bought without considering it.
We don't want people to buy devices which will stop getting privacy/security patches for the firmware, kernel, drivers and HALs after 2-3 years and are missing important security protections. If we support a device then people are going to buy it to use GrapheneOS. Few of the people who end up using it are going to be people who already had it.
We don't want to have a watered down form of GrapheneOS without the core protections including what we build with hardware memory tagging. Older devices which we discourage buying not providing all the current requirements is much different from adding new devices without those. Our recommended devices (Pixel 8 and later) provide all of the current requirements and we strongly discourage buying older devices without enough support time remaining or the current protections.
We have a serious OEM partnership because we stand by our requirements and haven't watered down GrapheneOS. An OEM working with us to improve their devices to meet our requirements and helping port GrapheneOS to those with full functionality is only possible because we don't poorly support anything able to run another OS.
GrapheneOS is open source and others are free to make incomplete ports to other devices under a different name. Many individuals and companies have done this and it hasn't gained any significant interested. It doesn't provide what GrapheneOS does and the expectations of our audience are much higher. Our audience doesn't want a device with 2-3 years of delayed security patches for the firmware, kernel, drivers and HALs follow by end-of-life.
Other projects (like LineageOS or /e/OS) have lower requirements. My experience is that it makes it very hard to know what kind of security you get. I have used /e/OS for a couple years before realising that it was signed with the Google test keys (so not signed) and the bootloader was not locked. And they were not forwarding the manufacturer updates, so Stock Android had the manufacturer updates and on my /e/OS they were 4 years old (!).
If you have GrapheneOS, you have the best mobile security you can get, period.
I think it's more about convenience and bypassing filters - developers are already logged in to github, already have access to create repos and publish code, firewalls will allow it. Even fancy HIDS systems will think the git push is rather normal.
If they have a clue, the attacker still will not download that without using a botnet tunnel or Tor at a minimum.
Note though that these credentials aren't even encrypted using some lightweight ECC to prevent others from capturing them, they're posted in cleartext. Embarassment might be part of the point.
This gets even more involved when you consider things like loading libraries, there's also the impact of calls like OpenProcess/WriteProcessMemory/CreateRemoteThread (Windows-land versions, though I'm sure similar exists elsewhere).
The "good" Windows firewalls like Outpost and Zone Alarm used to have features to catch this, they'd detect when a process tried to invoke or open a running process which had internet access. They'd also do things like detect when a process tried to write a startup item. This went by names like "Leak Control" but it was basically providing near-complete HIDS features with local control.
Very quickly you'll find this doesn't work. Your DC will just null your IP. You'll switch to a new one and the attackers will too, the DC will null that one. You won't win at this game unless you're a very sizeable organization or are just willing to wait the attackers out, they will get bored eventually.
I’m not sure what’s so special in Oregon’s ballot boxes. But, tampering that is detected (don’t need much special to detect a burning box I guess!) is not a complete failure for a system. If any elections were close enough for a box to matter, they could have rerun them.
This seems absolutely silly, it's not hard to take a photo of a photo and there's both analog (building a lightbox) and digital (modifying the sensor input) means which would make this entirely trivial to spoof.
