thingification

Ah! So given the language (explicitly using the word powerbox), it does seem a very good bet that whoever introduced this at Apple was at least aware of the work, and perhaps directly inspired by it.

I don't know the answer to that historical question (shaky data point: though I know Brendan Eich is a bit of a capability convert, I believe that's relatively recent thing: last decade or so?). Regardless of the answer, I'd agree if you said that the world seems filled with people reinventing capability ideas not as effectively as they could, because they don't know that that's what they're doing and so are cut off from the ideas that have developed in the small cap community over the decades.

This isn't really about files, though. Capability UI patterns are about composing all kinds of authority in a usable way. I'm sure we'd all agree that accessing files isn't the best or ultimate description of the interesting things that people do with computers now. This is an area that's waiting to be rediscovered by the rest of the world.

> Apparently they've integrated the open file dialog with their access control, so any such dialog will automatically permit the app to access the target file/folder. The pop-ups only appear when an app wants to access specific folders in the background. This is brilliant and would stop e.g. malware which encrypts documents or nosy apps in their tracks!

This pattern is called "powerbox", an idea from object capability security. I'm sure there are plenty of other usability improvements in there if you study those ideas (more so the more important security is to your application). Applying it to the web is getting easier with Mark Miller's JS standardisation work and (also his) https://agoric.com/ and https://ocapjs.org/

Maybe this has been done already and has been ineffective for some reason, but I guess the alternative is an organisation - maybe a different quasi-public institution - whose charter explicitly includes and emphasizes looking after the interests of institutions other than profit-making corporations?

That is a thing that happens, and it has a real effect. Those organisational charters inevitably reflect some underlying ethical system, and I think the role of those ethics in influencing organisations and their members is still under-appreciated in some contexts (I'm certainly not saying that free market economics or libertarianism - for example - don't have any ethical system, by the way - more the contrary). For example, over here, picking maybe the most visible examples, the NHS, Channel 4, and the BBC - and many of the people who work for them are heavily influenced by the ethical ideas behind them.

Let's solve it by keeping cars and fuel forever cheaper, and solving congestion!

Tunnels, electric cars, nuclear power (or solar, if you're prepared to sacrifice people's as-yet unsatisfied needs and unsolved suffering to that).

I don't know much about quantum computation, but David Deutsch does say something along those lines. In particular, that the superiority of quantum computation for certain problems is explained by computation taking place in multiple universes.

He also rejects the idea that there's something ineffable about quantum mechanics, or that the reason quantum computation works can't be explained using ordinary logic and reasoning that is accessible in principle to everybody (I don't know for sure that's what is meant here by "somehow creates a “resource”": but I'm triggered a bit by those words because people often do essentially mean that).

Of course he would (correctly) say that one shouldn't treat him as being an infallible source of truth on the matter. But he does believe that the purpose of science is to explain the world, which puts him in a different class from apologists for quantum mysticism, strict empiricism and other believers in explanation-free knowledge.

I'm surprised nobody else mentioned Google Caja.

Right.

The authority is not fine-grained enough because grants of authority are not dynamic (meaning they happen up front when the app is installed, not while the user is using the app). If the grants were dynamic, the context is clear to the user, who can therefore 1. understand what the grant is for 2. make an informed decision 3. use UI patterns like "powerbox" in which there is no "security UI", just UI that would be needed anyway. When that is true, finer-grained can be easier for the user, not harder.

Of course there is more to it, e.g. kentonv's important point re substitutability. Some otherwise capable programmers don't seem to understand that point even in the domain of programming (as opposed to UI).

I was already on the lookout for a small ARM-based mini PC, just for doing financial transactions and record-keeping. Now that seems more pressing but I don't know of any such thing in existence.

I tried doing that on RPi 3, but the IO seemed not up to the job -- the CPU appeared to be just about tolerable, but using micro SD as a disk was too slow and prone to failure (I'd have tried an external USB disk but I believe the problems were in part because of poor I/O bandwidth). Other single board machines seemed to have better provision for disks that are up to the task I had in mind, but lack software support, so that I had little confidence in security updates, for example.

If somebody sold this I think they'd have my money tomorrow:

* An ARM mini-PC

* With a decent security update team behind it (probably the hard part?)

* That will let me run some basics: for me, a Unixy OS with Chrome/Chromium, emacs, ledger and python, without a big effort to install those and keep them up to date

* Ideally without too much anti-commodification BS (from my customer perspective) so that hardware can be swapped out if needed

Does anything like that exist?

The high expense is caused in part by the current high volume of vulnerabilities.

Vulnerabilities and updates are inevitable, but the current volume of them is not, by orders of magnitude.

The volume of serious exploits could be reduced dramatically if we started to more seriously apply the principle of least authority (and an important technique and way of thinking about that is capability security -- in fact an important technique to make 'brickless updates' easier to achieve too, I suspect).

I think how to kick-start the industry to actually do that is a difficult problem.

Why are they focused on other diseases? Diabetes is hardly a rare disease, nor one with a low impact on its sufferers. So if what you say is true, what is it that's broken about the market for diabetes treatment?

I often hear it said that problems such as this are caused by cures being less profitable compared to drugs, because drugs are purchased repeatedly, cures only once. But competition is supposed to solve that problem. Is inappropriate regulation the real problem?

I guess you're wanting both a more specific and more infectious (or virulent?) word, but: equivocation.

I get you're joking, but:

https://blogs.microsoft.com/next/2017/06/14/divide-conquer-m...

"Doina Precup, an associate professor of computer science at McGill University in Montreal said that’s a significant achievement among AI researchers, who have been using various videogames to test their systems but have found Ms. Pac-Man among the most difficult to crack.

But Precup said she was impressed not just with what the researchers achieved but with how they achieved it. To get the high score, the team divided the large problem of mastering Ms. Pac-Man into small pieces, which they then distributed among AI agents."

This is (at least partially) true, but it strikes me as whataboutery? Yes, open source vendors can fail to follow good open source/free software principles just as closed-course vendors can, and yes "medical equipment is now mostly open source" is not the end of all progress.

Is it possible this means it was a mistake to buy those systems, because they are not based on open source software?

One objection is that these systems may have been the only ones on offer that met requirements. I think one has to consider collective effects, though: were people prepared to 'irrationally' say "I'm still not buying it, because it's not open source", we would end up with open source MRI machines. Of course that's unlikely to happen at present simply because there is NOT a consensus that open source software is important or even a good thing in this context -- but this argument addresses THIS objection.

That kind of stance happens in some situations, and not currently in this one. I don't think that's an immutable state of affairs. Also, I don't think it's because of the high direct costs of saying "no": refusing to pay kidnappers also has a high direct cost and an analogous collective benefit (I'm not aiming for a hyperbolic moral comparison there, I just picked that because, as an extreme case, it makes the point clear).

Here is a good reason to think that people would help others less even when everybody is in agreement:

https://www.youtube.com/watch?v=mwzBJF5Q7Vw#t=3m29s

This is Dan Ariely describing "The public goods game" and the instability of 'cheating'. Cheating in scare quotes because the conclusion stands -- in fact is enhanced -- even when the 'defect' choice is regarded as a choice that members of society are free to take (in fact that is the case he discusses).

This idea, which lies behind a lot of American libertarianism, says that theft (as taxation is construed here) outranks most or all other moral values, but does not explain why.

Instead, it hopes dogmatically that other moral values will be met as a side effect of following this one.

Can you expand on "Much academic work is something of a moonshot these days, and your job is to also carve out some useful incremental advances."?

My own assessment is that there is too much low-risk low-reward work in medicine (and its intersection with biology), and I want to hear/read about how I'm wrong.

It's hard to think of a worse plan for spent nuclear fuel than burying it in an inaccessible location.

There is no such problem as maintaining nuclear waste for 100,000 years. In reality, events will overtake our plans long before then. For example:

* inevitable flaws in the design of the burial system may cause leakage that burial will likely make more expensive to correct than leaving the waste where it is

* we will want to burn up the spent nuclear fuel in breeder reactors (which actually removes the problem, and simultaneously creates wealth)

* we will find ways to clean up leaks and spills

* we will find ways to prevent and cure diseases caused by radioactivity

Why are we talking about 100,000 years, when all we know with any confidence is that things will be so different in 100 that it is impossible to predict most of the problems that will face us then?

In fact I have trouble imagining a future where people still exist, but this problem is not solved or obviated well before 100,000 years from now -- in fact before 100.

Optimism says that both hazardous chemicals and spent nuclear fuel are problems that have solutions. In the case of chemical waste, we will eventually have entirely closed chemical cycles just like life. That is not enough of course: we must also try to avoid them ending up in the wrong places in the wrong form, and when they inevitably sometimes do, find ways to clean that up or obviate their effects.

Does it have to be specifically on an identified paper or thesis? Does it have to be science in the strictest sense? If not, what qualifies? Maths? Physics with a philosophical side to it? Do talks about how to give scientific talks count (if they are good talks in themselves)? TED talks that are not superficial?

Answers to those would help define your conceptual category, but as it happens each of them corresponds to a particular talk I have in mind.

By the way, it's instructive to consider why that last example isn't a tiny capability system.

The answer is: it is a capability system -- or would be, except that something has been ADDED to that clean cap system, which is the ambient authority provided by the open() system call. If not for that (and similar), cp in that second example would be unable to access other files than those.

plash implemented a shell lacking that ambient authority (with limitations due to limited sandboxing at the time) by means of sandboxing at the command level. If I recall correctly you could use it with commands like the first one above, but the resulting semantics were more like the second command: cp could only read foo.txt, and only write bar.txt. In a capability OS (like Google Magenta?) that sandboxing would not be necessary (but OS-level caps are only part of the cap story).

> what about something like an IDE where you want to open many files?

I can't call myself a capability programmer, but I can take a stab at that:

First, and this sounds glib, but it isn't: one has to decide what the program needs, and arrange that users can grant it that, but not more (of course this is an ideal not a reached endpoint, but I don't want to apologize for an under-applied principle). This is the principle of least authority. Programs, and objects, can't operate without the authority they need. According to cap adherents, most of the work in designing and implementing more-secure systems should be in the detailed working out of what is needed and how objects and programs talk to each other, passing authority to and fro in the process.

To apply the powerbox UI pattern and similar patterns, it isn't necessary for there to be a literal dialog, and in fact a good place to start is: 'what is the UI now, if I were to remove all UI associated with "security"'? So for vim, why not :e? A goal could be to drop the parts where you have to run sudo and type in your password (or maybe there are parts of vim where vim prompts for your password so vim can do that for you, using the resulting ambient authority). Powerbox-like principles have been applied to the command line (e.g. plash; there are more recent systems). That is UI too.

UI patterns, access granularity (e.g. your example: directory cap or file cap?) and access control patterns have to match the problems you want to solve in all their product-/domain-specific detail, like any other part of software engineering. So, if say all you are concerned with is constraining read access on the file level, "opening many files" one at a time and then subsequently "switching between files", there is nothing more to do, and "granting directory access" is not necessary (though it wouldn't imply creeping ambient authority, just coarser-grained access). Only the powerbox needs access to the directory. If you're writing an IDE, there will of course be parts of the IDE that deal with directories. The task of applying object capabilities pervasively to systems like that involves going a long way past the powerbox, and expressing in language-level objects what each part of the system needs and how it obtains and passes on that access (with dramatically lower friction than we commonly have easy access to today). The task of getting the software industry to the the point where that is commonplace involves creative shortcuts that are both useful and feasible, like Google Caja and SES, sandstorm, plash, capdesk, etc (Caja and SES is unusual in advancing both these tasks). How to do that well starting with existing IDEs is a project for an inspired person, not an HN comment, but I sketched some ways below :-)

If it's necessary to provide only temporary access, use patterns like membrane.

While "omit the 'security UI" is a good place to start, Mark Miller (Google Caja, ECMAScript committee, etc.) has said that software security took a wrong turn some time around 1960 (I may be out by a decade or so). If you take that seriously, you should expect that capability security is behind in finding UI patterns that are well-optimized to a parallel world in which obj cap UI and the infrastructure that supports it has been hammered on by creative people for 60 years. ACL UI has been through that process of enormous effort and talent applied to this world in which almost everything is done using ACL security. So, if one wants to find the truth of whether obj caps can provide objectively better UI and security, I'd say the only way to answer those questions is to invent the answers, and see how they hold up. Of course it's made more of a challenge by the need to find the right small steps, and not rewrite all software! But there are plenty of projects that have shown that's possible technically. If you want a path where you don't have to invent new stuff just to stay afloat: of course don't use capabilities.

You may well appreciate this already, but there's an irony to hearing "windows store apps already work this way" (same for iPhone I believe: that's what I was referring to) when for the longest time, a few people knew how to solve the problem, even that was not implemented in real systems. We still don't apply the same lessons in most of software engineering. In fact, I don't know if most of the people who applied it to those mobile systems even knew that what they were doing is called capability security. For me the lesson to take from mobile phone use of powerbox-style UI is that capability-style security patterns work, and that if we applied it, knowing that's what we're up to, I bet that there is much more progress to be had in that direction.

How would you change vim to support just :e-as-powerbox, in a not-yet-cap-friendly world? That's a challenge! Maybe you'd take a heavy, sandboxing approach that tries to cut out the work to make vim use capabilities internally. So perhaps process-level sandbox gvim, pull out the ex line handling into a library, and dynamically link an unsandboxed process that provides an X window that replaces the ex line. Obviously there would be plenty of things to work out there! Similar things have been done before however: e.g. I recall plash also supported sandboxing firefox with a powerbox injected dynamically via LD_PRELOAD (with limited isolation: sandboxing has moved on since then) -- but I would expect vim to be hard. But on past history I am probably missing a trick.

Perhaps more ambitious (I'm not sure), but much more powerful and scalable, maybe you'd choose to start with spacemacs instead of vim, and design an object-capability subset of elisp that still leaves it feasible to port enough elisp to get the project off the ground. Workable obj cap subsets like this, that can interoperate with old code, have been done for other languages (notably JavaScript).

> What happens when I want to install an a different file browser that needs global read/write abilities?

How would you swap out file browsers? In general a good answer is dependency injection. More detail would be getting into detailed software engineering and very specific choices, not to mention the current software landscape (again, the LD_PRELOAD hack is an example). I don't think there is anything intrinsically harder about that with caps than non-cap techniques: in fact the opposite, because capability discipline requires good separation of concerns, and therefore at least encourages dependency injection.

Global read/write abilities? Not sure I follow what you are thinking: A plain-old powerbox typically has global read/write abilities (or only read, if that's what you want). The objects or programs that use the powerbox do not, because they have no means to do so except through the user granting that, using the powerbox. Of course a particular cap system might restrict that further if that was appropriate in the domain.

> How does that work with something like an IDE? You have to pass the compiler a bunch of files names and you'd have to pass the access permission with them, then compiler has to create a new executable with the ability to run and pass the access back to the IDE. And that's just for the simple case. For that matter, how does it work with command line tools that pipe file names between them?

It isn't necessary for compilers to use file names to get access to files, and in fact that's a clear violation of capability discipline: it involves ambient authority. In fact this very example with compilers and file paths happens to be historically the original example of a general situation that causes a whole category of bugs that can be prevented by use of capabilities: see the "confused deputy problem", and the wikipedia entry on ambient authority. For command lines, take a look at plash (or more recent related efforts if that's not on the web any more... if you can't find them, reply and I'll dig). Or just consider this simple example from plain old shell, sans capabilities (from David Wagner):

$ cp foo.txt bar.txt # cp must run with all of the user's authority

$ cat < foo.txt > bar.txt # cat needs no authority other than what's given to it

(this doesn't imply that compilers need be ignorant of file names, by the way)

> I agree here, that page is the perfect example, all I see is a page full of academic buzzwords and not a "How this works in practice". So we limit what resources an app has access to, that's easy enough to understand, but what happens when an app needs resource x?

If you're interested in more/different examples than the Stiegler talk, google ka ping yee capability ui patterns

> It sounds like it has to prompt users to get permissions:

Well, in some sense, yes, but really no: The idea of a PowerBox is that the very action of opening a file already demonstrates the user's intent to grant access. Normally one does not conceive of opening a file as a prompt for permission, because it is necessary to designate a file in the first place.

As long as the thing that is being granted access is isolated and nothing else grants it access, problem solved.

It's a very neat idea, and it works.

This goes along with the capability slogans "No ambient authority", and (stronger) "No designation without authority".

Here's an old talk with demonstrations by Marc Stiegler, who I believe came up with the concept:

https://www.youtube.com/watch?v=vrbmMPlCp3U

More recently I hear essentially the same idea has been used in mobile phone security (I don't have that kind of mobile phone). The capability ideas that surround it are not widely known or understood, though.

'Sandboxing' within single processes would still be necessary, at least (and I suspect at many other levels too, practically). I think it is necessary now, but that is not (yet?) appreciated.

If you haven't seen it already, I and many better educated people recommend http://www.erights.org/talks/thesis/ (a pleasant read, even if I don't judge it by comparison with other theses) - focuses on distributed computation and language-level capabilities

On display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”, is this mailing list:

https://groups.google.com/forum/#!forum/cap-talk

Ha

To be honest: Yes? I would say that is the conventional wisdom in the (small) capability community. I'm sure that oversimplifies carefully-nuanced opinions of course, but, yes.

An example is mentioned here ('angels', 'Power Boxes'):

https://www.cl.cam.ac.uk/research/security/capsicum/

The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course.

Capability security has low adoption in part because of the usual catch-22 (adoption breeds adoption), in part because it's a tricky challenge to retrofit, and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know.

Where can I read about medical science having been more focused on understanding in the past? I think the focus on small increments in (relatively) unimportant medical knowledge is perhaps the greatest tragedy of our time.

Also, who calculates dietary intake that way?

"Confusing statistical significance with practical significance" -- that's a great phrase!