sometimes the best medicine is preventative medicine. In other words, leading a healthy active lifestyle. It’s a very western perspective to think all medical stuff should be resolved with drugs or surgery. And i say this as someone born in the west.
No need to be so dismissive. Anyway i do agree those 3 examples you provided are good ones and they have made a big difference in healthcare.
Apple has always been like this. They are never the first one to cross the first few checkpoints. They watch what the winning-est competitors are all doing and then they try to copy that to win the race overall.
If they hadn’t saddled themselves with the privacy promises, or if OpenAI were willing to uphold those same promises, then I bet Siri would’ve been wholly replaced by ChatGPT by now.
Reminds me of iOS and iDevices and how even after months they keep stabilising and then they fail to stabilise and then they release the next version after a year with all those bugs intact and accumulated. In this case that OS is literally made for only those devices and vice-versa, in iron claw control of one control freak corporation that has a net worth more than GDPs many countries would nuke for.
Let’s contrast that with a pure community led effort, motivated by freedom, privacy, and safety, that neither controls the OS nor the devices. It’s not what I tried to saltily explain above.
All Android devices support running the Android Open Source Project via Treble and we could quickly add support for non-Pixel devices doing things in a reasonable way too. Those devices don't meet our hardware security requirements (https://grapheneos.org/faq#future-devices) which is why we don't support them. It wouldn't be that hard to add a Sony or Motorola device but they're missing the expected security features and proper updates. It wouldn't be possible to provide our standard security protections on them which is the real blocking issue, not difficulty. Android has made device support simple, but the rest of the Android device ecosystem is not at all competitive in security with Pixels and iPhones.
We automate a huge portion of the work via https://github.com/GrapheneOS/adevtool. We do a GrapheneOS build with it and it outputs state you can see in https://github.com/GrapheneOS/vendor_state which is then used to automatically figure out all of the missing overlays, SELinux policy, firmware files, etc. When we have our own devices in partnership with an OEM we won't need to use adevtool. We can borrow a lot from Pixels for those devices though.
Pixels are very similar to each other, which does make things simpler. The entire kernel source tree is identical for 6th, 7th, 8th and 9th generation Pixels. They all use the Linux 6.1 long term support branch on bare metal and the Linux 6.6 branch for on-device virtual machines. They'll likely advance to new Linux kernel branches together rather than ending up very split across different ones as they were in the past. That makes things easier for us.
Pixels also share most of the same drivers for the SoC and lots of other drivers. Those drivers support the different generations of hardware with the same codebase for the most part. There are still 6 different Wi-Fi/Bluetooth drivers across them but 5 of those are variations of a very similar Broadcom Wi-Fi/Bluetooth driver and only 1 is a separate Qualcomm Atheros driver (Pixel 7a).
We have various hardware-based hardening features such as our hardware-based disabling of the USB-C port with variations across different hardware generations (https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...) and similar features. Our exploit protection features also uncover lots of memory corruption bugs across devices in their drivers. We do have a lot of device-specific work fixing uncovered bugs. Hardware memory tagging in particular finds nearly every heap memory corruption bug occurring during regular use including out-of-bound reads so that finds a lot of bugs we need to handle. Many of the bugs we find with hardware memory tagging and other memory corruption exploit protections are in drivers or the portable Bluetooth software stack which is thankfully one of the components Android is currently gradually rewriting in Rust along with the media stack.
If we supported a device with much different drivers, there wouldn't be much work to deal with that directly but enabling our features like our hardware memory tagging support would require fixing a bunch of memory corruption bugs occurring during regular use across it. Supporting other Android devices with the Android Open Source Project is easy. Supporting them with GrapheneOS is significantly harder due to various hardening features needing integration at a low level along with others uncovering a lot of latent bugs which were occurring but not being noticed most of the time. The ones which get noticed often due to breaking things get fixed, but many latent memory corruption bugs remain there unless the OEM heavily tests with HWASan or MTE themselves, which is unlikely. Pixels are tested with HWASan and MTE by Google but yet we still have to fix a lot ourselves largely because testing them in a device farm is different than users actually using them with assorted Bluetooth accessories, etc.
Nice to know that all supported Pixel phones are not only on the same kernel version, but actually are build fro the same source tree now.
Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google?
Many of the security features you are using are already included in AOSP, why does Google not activate them by default? Do they have a different balancing of performance, stability and compatibility on the one side and security on the other?
I understand that Google has a different view on privacy for business reasons.
> Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google?
We've made significant contributions to the Linux kernel, AOSP and Pixels in the past. We continue doing it to the extent that it helps GrapheneOS users. We no longer spend our time doing work for them if it doesn't have a clear benefit to our users.
Android's security team previously got us security partner access and was in the process of getting us OEM partner access. Android's partner management team blocked us from getting OEM partner access and revoked our security partner access. Due to this, we've reduced our reports of vulnerabilities upstream and have fixed numerous vulnerabilities in GrapheneOS without reporting them. We still report all firmware and hardware vulnerabilities but we make a decision about reporting software vulnerabilities solely based on what's best for GrapheneOS users.
> Many of the security features you are using are already included in AOSP
That's not really the case. The vast majority of our privacy and security features were developed for GrapheneOS. Features being built on top of standard functionality doesn't mean that they're present in AOSP.
For example, GrapheneOS has our own integration of hardware memory tagging into our hardened_malloc project and we turned the overall feature into something which can be used in production without making the OS unusable. We had to fix issues with the standard hardware memory tagging integration in the OS and Vanadium (Chromium) along with fixing numerous bugs uncovered by it. We had to integrate it into our user-facing crash reporting system and had to create a system for opting into using it for user installed apps where users can enable it for either specific user installed apps or for all user installed apps with a per-app opt-out. Android has the foundation for hardware memory tagging support but it's not used as a production feature for hardening and we're not simply enabling it. We have a much better userspace implementation in hardened_malloc and while we currently use the standard kernel allocator integration, we want to improve that to be closer to what we do with it in hardened_malloc. We currently use the standard Linux kernel MTE integration for the kernel allocators and the standard Chromium PartitionAlloc MTE integration but both need to be improved to provide better security properties as hardened_malloc does. They're also missing the other forms of hardening used by hardened_malloc which go nicely with memory tagging. The stock OS developer option for memory tagging is not the same thing and only makes it available for usage without actually using it. It has to then be enabled via ADB but there's no way to use it everywhere we do or in the same way we do. AOSP having that doesn't mean it provides what we do with it at all.
> Do they have a different balancing of performance, stability and compatibility on the one side and security on the other?
Yes, but you're wrong about where our privacy and security features come from.
Those folks dont make any money unfortunately, but it is still a drag on Open AI. So sooner or later, Open AI will have to find a way to make money (and nope, all these people wont pay anything) and by that time, Open AI would probably run out of time.
Ask llama to recommend you a pair of sunglasses, then look to see if the top recommendation by the LLM matches a brand that has advertisement association with the creator of llama.
Soon we will start seeing chatbots preferring some brands and products over others, without them telling that they were fine tuned or training biased for that.
Unless brand placement is forbidden by purging it from training data, we'll never know if it is introduced bias or coincidence. You will be introduced to ads without even noticing they are there.
Its trivial to check if any brands mentioned in the response before returning it to user, and then ask LLM to adjust response to mention brand who paid for placement instead.
What I described happens in the raw offline model too. Those don't have post-inference heuristics such as those you described, implying the bias is baked in the training data or fine tuning steps.
Meta's models cant be used by companies about a certain threshold, so nope. Apple can wait it out to use a 'free model', but at that point it'll be like picking up an open source database like Postgres - you wont get any competitive advantage.
Google has so many channels for ad delivery. ChatGPT is only competing against Google Search, which is arguably the biggest. But dont forget, Google has YouTube, Google Maps, Google Play, Google TV and this is before you start to consider Google's Ad Network (the thing where publishers embed something to get ads from Google network).
So nope, ChatGPT is not in even in the same league as Google. You could argue Meta has similar reach (facebook.com, instagram) but that's just two.
To really answer the question, you have to understand what user problem is it solving.
Lets look at it from couple of different angles. First a solo developer. If you've ever developed against an API, you know how difficult it is to pass headers, cookies, change GET/POST/PUT requests. You might want a way to repeat a previous API request again and again. You might want to create a collection of requests that you can refer again. If you're using curl, you'll soon start having a myraid of shell scripts with variables and control flow. At some point you might want a UI, and soon you've invented Postman/Insomia and the likes.
Now imagine you're a team. In a team, there are cases where you might want to share "requests collections" with others in the team. What are the options for headers, what flag configuration works best for a certain scenario and the like.
So yes, while postman looks like curl, it adds so much value over curl and that's why it exists.
It will be similar to dismissing dropbox/google drive, because rsync exists (yes, I'm aware of the HN lore)
reply