It seems like Fuchsia components have less that they can assume about their environment and require the caller to be more explicit about what the component can do ("capabilities"). So for instance a docker container might just decide--without the user's say-so--that it wants to write a debug log file to /foo/bar/baz and then it would be up to the user to go find that file if they care. By contrast a Fuchsia component would not by default have the capability to write anywhere, so the user would have to pass in a handle that says "write your logs to this place" if they wanted logs to exist at all.
Linux folk are familiar with working with file descriptors--one just writes to stdout and leaves it to the caller to decide where that actually goes--so that was the example used but it seems like this sort of thing is done with other resources too.
It looks like a design that limits the ways programs can be surprising because they're not capable of doing anything that they weren't explicitly asked to do. Like, (I'm extrapolating here) they couldn't phone home all sneaky like because the only way for them to be able to do that is for the caller to hand them a phone.
It's got strong "dependency injection" vibes. I like it.
It's a lot like sandstorm; the web hosting platform that Kenon Varda created. It failed as a corporation, but is still open source. It's a shame: it was before it's time and still holds up incredibly well.
Sure, but it is allowed, at least as far as I understand, to phone home if it otherwise needs network access. In practice it’s really hard to prevent unauthorized semantic network access once you allow any network access.
The main benefit is that kernel space is drastically smaller which means that the opportunity for a kernel-level exploit is minimal vs something like the Linux kernel that a single device exploit compromises your entire machine.
The joy of having a properly implemented capability system is that, well, you can create arbitrary capabilities.
You don't need to give a process/component the “unrestricted network access capability” -- you could give it a capability to eg “have https access to this (sub)domain only” where the process wouldn't be able to change stuff like SSL certificates.
EDIT: and to be clear, fuchsia implements capabilities very well. Like, apart from low-level stuff, all capabilities are created by normal processes/components. So all sorts of fine-grained accesses can be created without touching the kernel. Note that in fuchsia a process that creates/provides a capability has no control on where/to who that capability will be available -- that's up to the system configuration to decide.
Ok, give me access to a subdomain I control and I’m phoning home and there’s no way you can restrict mysubdomain.foo.com/phonehome vs mysubdomain.foo.com/normal - and even if you tried to do path restrictions, I can arbitrarily side-channel phoning home with normal access (which by the way you can’t unless you’re sniffing the encrypted HTTP session somehow).
Also imagine you are trying to run a browser. It’s implicitly going to be able to perform arbitrary network access and there’s no way you can restrict it from phoning home asides from trying to play whackamole blocking access to specific subdomains you think are it’s phone home servers.
That’s why I said “semantic” capabilities aren’t a thing and I’m not aware of anyone who’s managed to propose a workable system.
I imagine one could create a capability such that the app gets a way to shove bits in and a way to get bits out, but no knowledge of the IP address or anything like that. A phone (or set of phones) that are already connected and have no keypad.
Ok great. Now I put the phone home stuff within payload. It’s a game of whackamole you’re bound to lose. Like I said - if I control both endpoints, it’s going to be very hard for you to simultaneously give me a pipe connecting them while controlling the set of messages I’m allowed to send.
In my experience lots of folks simply won't work with capability systems no matter how good the implementation is or whatever level of security and configuration granularity is provided.
For many people it's just extra friction in search of a use case.
It makes testing a lot easier honestly. Also keep in mind that mobile apps and web apps are fairly capability oriented these days, so I wouldn't say no one will work with it...
I'm just hearing about capability systems today, so your experience is undoubtedly richer than mine, but I'd estimate that we're just scratching the surface re: ways to harm somebody by making their tech behave in surprising ways.
Maybe once those harms are all grown up, we'll find that fancier handcuffs for our software is worth a bit more than "just extra friction."
I am curious what your experience is with capability based security? They are still incredibly niche(unfortunately) so I’ve never had a chance to work with one at a job.
Most components don't need to talk to the network though and therefore do not. The ones that do can do powerful things but creating narrower capabilities to restrict what they can do is very much feasible.
I’m not against capabilities. I’m just highlighting it’s for the developers to implement protections against malicious intrusions against the OS, not for users to protect against developers doing malicious things.
While there is no direct UX exposing this to an end user, it hypothetically be used as the basis of such UI. The parent of a component gets to ultimately decide what capabilities it routes to a child component. It's not like landlock where the process decides to sandbox itself after it's already running. Similar to a user constructing a VM to run a hypothetically malicious program, the same could be done much more lightweight with a fuchsia component.
All I said is that in the general case you’re not going to be able to rely on capabilities to do things like prevent phoning home or otherwise doing things you semantically define as harmful. This isn’t a UX issue - this is a technical issue. Capabilities, outside from very rare circumstances, can’t enforce it no matter how you structure this. The only rare circumstances is if you can restrict access to servers that aren’t owned by the same people as wrote the component. As soon as you give access that allows access, they can implement it in ways that capabilities can’t prevent.
Your perspective is coming from a very rigid all-or-nothing mentality and I don’t think it’s wise to see things that way.
Sure, a web browser that needs to open arbitrary network connections can be built to phone home. But nearly none of the components it’s built out of can. The image decoding and rendering libraries can’t touch the network, the rendering engine can’t touch the network, and nor can the dozens of other subcomponents it needs to work.
Your installed editor extensions can’t phone home even if the editor itself can. Or perhaps even the editor itself wouldn’t be able to, if extensions are installed out of band.
Your graphics driver vendor can’t phone home, your terminal can’t phone home, and on and on and on.
A solution doesn’t have to be perfect for it to be an improvement, so stop acting like it does.
But your editor extensions can’t phone home only if your editor sandboxes them into a separate process. Hint: VSCode doesn’t do such sandboxing and neither do most editors that I can think of.
Anyway, you’ve just proven my point with “install extensions out of band” - you’ve ceded that it’s a losing position technically and are arguing for alternative UX solutions. I’m not pretending it has to be perfect. Like I said, capabilities are great for creating a secure OS and writing more secure software more generally. But the threat model it’s protecting against is not software that phones home but against the size of the exploit opened up from a compromise.
Think about it this way, Android apps and iOS apps are largely sandboxed through a primitive capabilities system already, not super fine-grained capabilities but still the same concept. Would you care to claim that privacy and malware isn’t a problem on these systems or that the permissions model has meaningfully curtailed anything but the most egregious of problems?
Firstly, VSCode runs on 3 major OSes that don’t have this capability and such software results the way it is partially because of targeting the lowest common denominator. Only a Fuscia first editor would do this.
Secondly, the editor also does it this way this because of reasons other than support within the OS because even with components it would need to design a capabilities model for extensions and a sandbox process to maintain the permissions - it’s much easier to just do the extensions in-process and not think about it.
The difference is that those solutions are mandatory access control. Fuchsia doesn't have a global namespace that everyone shares. Each component gets it's own view of the world based on what is passed to it. This is often easier to work with then MAC. It's similar to writing a program without relying on globals for state, but instead passing everything into every function that it needs.
Is it similar to NixOS? Recent convert, would be interested to read a comparison to fuchsia from someone in the know of both.
If it’s anywhere close Google might be sat on a huge opportunity to tread the same ground while solving the ergonomic issues that NixOS has. (I’ve never been more happy with a distro, but I’ll admit it took me months to crack)
NixOs is built on Linux kernel, Fushia is built on a new (micro-ish) kernel called zircon, they are not interchangable.
They are working on some components/layer to run things from Linux, but you would not expect all things built to work directly or as well as thing designed from the get-go for Fushia in mind.
Thanks - I figure its step away in terms of target platform.
I meant a little more in the way that software is packaged and run. My understanding is that theres a similar mechanism for storing and linking shared libraries that means multiple versions can go exist and be independently linked depending on the requirements of the calling package.
Many staff in different roles, 3+ shifts a day, 365 days a year is a lot of labour costs. Replacing even a fraction of labour is likely $100K a year of potential investment. More so in expensive labour countries.
Wouldn't a "month" risk being many days off the intended target date, since it's a non-fixed timespan? E.g. how many days is "1 month from today" (March 20)? You mention medicine, so I assume there's something obvious I'm missing (then again, perhaps the constantly shifting dates for health care appointments where I live say otherwise ;D).
Well, that’s not “the month” at all, though. At least not something I’d use outside of getting a rough idea for setting the next meeting, and absolutely wouldn’t use in code (but it’s probably fine for a todo - I’m complicating things, sorry ;-))
Edit: but perhaps that’s the custom used at many places and I’m just not aware.
A few people/companies I've worked with avoid using the last few days of the month for "monthly" things.
For example, "every month on the 15th", "every month on the 1st", etc. It makes it easier to figure out compared to "every 30 days" or "every month on the 30th, unless there are less than 30 days in the month"
That sounds reasonable. I'm writing a dumb, little journal/todo CLI tool for personal use ("meet with @farmer @Monday @13:30 regarding #carrots"), and the library I used for time has a duration for most things except month (i.e. you can't do 2024-03-20 + 1_MONTH), which makes sense.
Off topic because I am skeptical of the claims in the first place. As a general principle: the licensing exam is not the benchmark AI should be evaluated against to then go about calling itself a doctor.
I'm from a different country but these exams are the minimum standard to demonstrate a doctor is safe prior to interacting with patients. To be really explicit, the core competency being assessed is identifying potentially serious situations and answering the same way every time: "I WOULD CALL FOR HELP" +/- principles of basic care.
The benchmark for doctors actually making decisions about patient care are the assessments to become fully qualified consultants in a each specialty.
Again, to be really explicit don't confuse a test for "doctor won't immediately kill someone and commence reasonable first steps" with an actual "doctor with years of experience and subspecialty training who regularly makes decisions about patient care".
Non-US doctor here. Completely agree. Licensing exams mainly confirm that the aspiring doctor won't harm/kill patients by mistake. Specialist-level exams assess standard of care.
I found the origin of ECT quite interesting: depressed people with epilepsy had dramatic improvement in their symptoms following a seizure. They also discovered that the type and location of the seizures had varying levels of effect.
There is some evidence that "aerobic exercise" itself produces an equivalent baseline energy deficit without the performance downside.
This guy[0] studies total average energy expenditure over time and demonstrates that an athlete undertaking intense regular exercise uses marginally more energy over time than someone sitting on a couch all day. The hypothesis being that the athlete is conserving energy by down-regulating baseline metabolic and inflammatory processes when at rest.
Disappointing news for "exercise causes dramatic weight loss" but encouraging news for "exercise is anti-cancer" (a correlation demonstrated many times I believe).
I have seen this study before, but I can't see how this gentleman's work disproves the huge body of health and fitness research that comes before it. It's an interesting outcome for sure, but the idea that it suggests exercise is a bad weight loss tool doesn't seem to reflect reality. The long term outcome of exercise is a changed body composition, which itself can contribute to changing metabolic rates.
I think it points to an interesting insight, something we have yet to uncover perhaps, but I don't think it disproves that exercise spends energy. Maybe all it's really proving is that we are very efficient at the chosen type of exercise in the study.
I worry this comment is overly dismissive of criticisms and overly optimistic about potential positives. On medicine topics I think it is important to try remain objective.
1. On DXM being an NMDA antagonist:
At high concentration DXM is an NMDA antagonist and AXS-05 does dramatically increases DXM concentration [0] (slide 6). It is not clear to me why we should "ignore anyone" who makes this comparison?
2. On AXS-05 having a wide array of receptor targets:
Almost all psychoactive drugs have some affinity for many receptors (just wikipedia any anti-psychotic e.g. [1]). Are any of the targets mentioned clinically significant at therapeutic concentrations?
> It is not clear to me why we should "ignore anyone" who makes this comparison?
I said that we should ignore people trying to compare this drug to recreational use.
It's likely that NMDA is in play and I'm not suggesting otherwise. I wanted to highlight that DXM has significant affinities for other targets like the serotonin transporter that could also explain the efficacy, so it's a mistake to focus on one receptor as the single answer.
The article said Dolby prefers to charge on the playback side. Does anyone know if Apple pays Dolby anything? iPhones produce a lot of content so it makes sense for Dolby to provide Apple with free licensing if it popularises the formats.
Eventually it may be a contributor to a commercialization, but now it makes it a target for research for others. This isn't patenting anything, it's scientists saying 'this is an important bit when it comes to the effects of fasting so let's focus on this.'
What would be scummy would be some pharmaceutical company discovering this, not releasing the information, and trying to develop (or worse, failing to develop) a drug on their own after internal research that was never released to the world.
reply