fyi, we (V8 code caching implementors) tried to convince extensions team to implement this a while ago. As I recall, this was not pursued, mainly on security concerns, in that it might allow to persist an (otherwise transient) attack vector.

The idea was if the cache writing process - that is, whichever process compiles the code cache and writes it to disk - is already compromised, then it could write a malicious code cache entry to persist and 'export' this compromise into pretty much any rendering process started ever after. I've never quite followed that train of thought, in that extensions would probably be compiled in either the browser process or a separate process for that purpose, and if an attacker had already compromised those, then they'd already have the means to 'export' themselves in another fashion.

Either way.. the concern is certainly serious, and my one sentence treatment above likely doesn't do it justice. So whoever takes this on will have to work through the security implications w/ extensions + security folks.

+rdevlin.cronin, do you have any context for this design decision?

I'm not very familiar with v8 code caching - which code exactly are you suggesting we cache?  Our generation code, the extension's code...?

The generation code is very tricky.  As vogelheim@ mentioned, there *are* a bunch of security concerns, since extension apis are initialized lazily, so malicious code can already run and do all kinds of fun stuff to intercept or modify our initialization process (there have been a ton of security bugs in here already).  Additionally, different extension contexts and web pages have different access to APIs.

Can you give me a little more detail on how exactly the v8 caching route would work?

Also note that we're looking into converting extension bindings into blink-style bindings ( issue 616765 ), which should greatly reduce the amount of time parsing/compiling the js generation code.

V8 code caching: The idea is to cache the machine code generated for (the extensions') JavaScript sources, so it can be read & executed directly, in lieu of re-parsing and re-compiling the JS sources again. This is massively faster, provided the cache is actually hit.

The resulting machine code is independent of the context (at least, the context as V8 understands it). Caching shouldn't per se change the security properties, since that code would be read/executed at exactly the same time as it would be without cache.

Of course, since I don't understand the extensions system much, it's hard for me to say whether my analysis really translates into that space.


Background on V8 code caching:
- tracking bug:  crbug.com/399580 
- design doc: https://docs.google.com/a/chromium.org/document/d/1HY4jVB3mCoYWADaZgmRxFmC2vm8qFKUzdC4NZN5oVZA/view

Ah, okay.  For the extension's code itself, the risk is smaller, I think (and is orthogonal to our bindings work).  That sounds interesting, and could definitely help in the case of extensions that execute on every page.

+creis and nasko from a security perspective for their thoughts.

Bumping priority given the general sense that this is indeed a valuable opportunity to improve performance (hopefully we can resolve the security concerns).

Reading the comment #1 looks like the biggest concern was to have an arbitrary renderer (which happened to be the first one to run the extension code for the page) might send back compromised compiled code to the browser disk cache, and then the same code could be used in other renderer processes for again totally different sites/origin, due to extension nature?  As suggested by vogelheim@ it feels compiling it in a separate utility process and maybe also expiring periodically / somewhat aggressively might mitigate the threat?  (vogelheim@-- do you remember who were in the look when the security concern was discussed?)

Curious to hear the previous security considerations as well. I agree with Kenji that this would be very valuable for those with many extensions installed.

Hey,

the security concern is that if a web page manages to attack (through a bug in chrome) an content script, and that content script gets compiled and written back to disk, the web page now effectively has access to everything the extension had access to.

This can be somewhat mitigated by storing the compiled code per origin and deduplicating entries to save space...

but overall, this is a lot of work (there is currently no way to write out data to extensions, they are read only), and from my experience, code caching also comes with a certain ongoing maintenance overhead.

I think overall the idea of speeding up content scripts is good, however, I don't see us having the resources right now to support it, given possible other work that would also benefit users on mobile or without extensions.

Thanks Jochen for the extra insights.

I definitely agree that this is lower priority than mobile or across the board improvements.

Does the V8 team have a backlog?

yes, go/v8-backlog - I've added an entry for this to the list

Ping! This bug is assigned and has an owner, but hasn't been updated in over 180 days. Is this still something we want to do?