can this proposal facilitate integrity of the running script?

[michaelficarra]

We don't have a specific request for what to include (or not include) in the attestation. Instead, our goal is to be able to bootstrap trust in other browser APIs. For example, we would like it to be hard for an attested environment to be under control of automation without that being indicated by the navigator.webdriver property. If the attestation can guarantee to us that the browser built-ins are original and being faithfully evaluated, it would allow the set of actual attested values to be small and remain stable over time – two very desirable properties. Anything else that needs to be trusted could be added through regular browser APIs without continually extending the APIs added by this proposal.

We realise that it might be difficult to achieve this property. For example, the integrity decision would have to account for certain kinds of extensions that replace or modify platform built-ins. Additionally, to account for proxied or otherwise modified responses that change the script being run, the attestation would need to include evidence of absence of tampering with the running script, such as a hash of its contents. This info would not be included opaquely within the integrity decision because, unlike with typical integrity properties like Secure Boot, self-signed certs, or use of debugging APIs, the attester does not know how to evaluate the integrity of the web application itself.

So with all that in mind, it looks like what we would like to be included in the attestation is:

• attester identity
• origin
• request-specific content binding
• platform info, including:
  • operating system identity
  • user agent identity
• the integrity decision
• evidence of absence of tampering with the running script

A note about the absence of integrity info for the document or other subresources: once you have established integrity of the platform and your script, the script can be trusted to make integrity assertions about the document, at whatever point in the document lifecycle is appropriate.

/cc @bakkot

[RupertBenWiser]

I totally agree with the thinking that it would be valuable to think of this as "layers" of attestation. Eg: I now trust the device, move up in layers of trust. Sounds like that could potentially be the guiding principle as we all design this.

Sounds like we should continue the discussion regarding attesters having origin visibility in issue #2.

One concern with user agent identity as a proxy for trust would be that it could result in websites being slow to trust new user agents. How do you feel about this alternative? eg: Attesters rather report back that they trust the user agent as a signal. It would be great to have a pros/cons breakdown on this.

I think before we go into "evidence of absence of tampering with the running script", we should try to sketch up a definition of what we want attested for this initial version. Is it fair for me to say that you are considering this an attestation of the integrity of the script execution?

It sounds like there are a bunch of interesting items to discuss here so it might be worth us proceeding by splitting these topics into separate issues. WDYT?

[michaelficarra]

Sounds like we should continue the discussion regarding attesters having origin visibility in issue #2.

Sure, ignore the part about the origin for now, but I do feel it will be necessary to avoid spoofing attestations from an origin that is under the adversary's control.

Attesters rather report back that they trust the user agent as a signal. It would be great to have a pros/cons breakdown on this.

A strategy like this would only be equivalent for verification that happens immediately. If the attestation was stored for some period and later verified, the verifier of the future may know more about which software was trustable at the time the attestation was made.

Additionally, integrity of the environment is only meaningful if we know what the environment was represented to be. Different user agents are different environments. Even though they have some behaviour in common, there are areas in which they differ, and we cannot reason about the execution of the script without knowing what behaviour to expect.

Is it fair for me to say that you are considering this an attestation of the integrity of the script execution?

Yes, the script and the JavaScript environment in which it is executing, which depends on the integrity of the supporting "layers": the browser, the OS, and the hardware.

I think before we go into "evidence of absence of tampering with the running script", we should try to sketch up a definition of what we want attested for this initial version.

What would you like beyond what was in my original comment? What we would like is for the attestation to indicate that, at the time it was requested, the JavaScript environment was unmodified and the script had a particular hash.

It sounds like there are a bunch of interesting items to discuss here so it might be worth us proceeding by splitting these topics into separate issues. WDYT?

Can you be specific about what topics you mean? This all seems like one topic to me.

[RupertBenWiser]

What would you like beyond what was in my original comment?

Sorry my initial comment wasn't super clear. I meant I think it would be helpful to try to come to a consensus of how many layers up the stack we all want to attest to. I think the explainer is definitely positioned around the device integrity more.

Can you be specific about what topics you mean? This all seems like one topic to me.

I was reading the origin, user agent identity, and script tampering as all separate topics. On second read, it makes sense to keep this here with those as dependencies.

I think what could help with this proposal would be to have a list of use cases that need script integrity and we should also assess the risk of potentially introducing this later versus v1. I'm also hoping to know if those use cases could alternatively be tackled, by for instance having more safety around customization and knowing what application is being attested.

We need to be careful to not punish users with extensions. It may also be a hard problem to solve (eg: can I (as an extension) wait for attestation to occur, and then insert my own Javascript into the web page?).

[Jookia]

Slightly related #37 which talks about accessibility APIs.