[cap-talk] Are Guards Ambient Authorities?

[Grant Husbands]

Teaser: Is the integer guard an ambient authority, in E and other
similar languages?

Long version:
A while ago, tav tried to encourage/demonstrate capability-secure
Python. Some early attacks against the provided example were
parameters that pretended to be strings but were more insidious, and
similar type trickery. With some interesting code, tav was able to
defend against these attacks, in a way that seems reminiscent of
guards.

However, it brought to mind that duck-typing capability languages most
likely need guards for almost any time a value would otherwise be
assumed to be of a particular type. These guards seem to be an ambient
authority, though, which seems to undermine some of the principles of
capability security.

Guards also apparently undermine the principles of duck-typing.
Talking about files, say, I can no longer give a file-like object to
an object that expects a file, if it uses a guard on the incoming
parameter. As a programmer who wants that influence, Do I need to
control the other object's compile-time environment in order to
control the otherwise-ambient authority it carries?

I always expected that a capability-based system would allow me to
give out file-like objects rather than files. Was I wrong? Is there a
difference between integer-like objects and (read-only, say) file-like
objects?

Regards,
Grant Husbands.