On 04.01.2018 07:25, Fabrice Desre wrote:
Does that mean that web pages see the api as exposed, but it doesn't > work? I guess the mock can "fail gracefully" and expect web sites to
process errors properly but in practice...
I'd like to get rid of the API at all. Don't wanna have any unused code.
Less code = less attack surface.
In longer terms we could think about some generic extension API for
putting such stuff into an external process. Maybe some config items
describing which new objects are available (in which contexts) and
some path/address to the server.
Maybe even just a generic communication channel (eg. jsonrpc via
some socket) for talking to some local server. An extension now consists
of the following:
* a communication endpoint to talk to
* permission rules (where also user settings are derived from)
* a piece of js injected into the browser/site context providing the
glue between the IPC and the official webapi.
This way we could keep most of the optional (and possibly later coming)
webapi's out of the main engine and delegate them to external programs,
that can be individually deployed by the operator (standard FF might
just bundle and start them automatically). There might even be setups
that run them as different users or on different hosts.
That's true, but there are also reasons for giving more control on which
device apis are built as part of Servo:
- The embedder may want a > minimal web renderer without increased api >
surface.> - The embedder
> may want to limit on disk size and memory overhead.
Exactly.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
