Intent to Ship: HrefTranslate HTMLAnchor attribute

[Dave Tapuska]

Contact emails

dtap...@chromium.org

Explainer

https://github.com/dtapuska/html-translate

Spec

There is just a PR request out now for addition to the HTML spec.

https://github.com/whatwg/html/pull/3870

I met with the TAG team twice to help clarify this proposal:

https://github.com/w3ctag/design-reviews/issues/301

Feedback has been received from TAG so far and been adopted into the initial design. Some feedback is still pending about further clarifying the explainer with privacy implications of using a client-based translation service. I pushed further updates to the explainer today that I hope will address their concerns but they will discuss it next week on Dec 3rd. With M80 branch approaching we'd like to enable this for that release.

Summary

Add an HTML attribute that adds the ability for a page author to hint to the UA's translation engine that a href should be translated if followed. It is a hint only and the decision to translate rests on the user agent.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/hmASm1yhi5s

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/4DZIDt9o1ME/L4878LGOBwAJ

Link to Origin Trial feedback summary

Trial went well. No negative feedback or additional crashes were encountered while delivering better content to the user.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Risks

Interoperability and Compatibility

One of the things we spent some time on with TAG was about the interoperability of the feature. Specifically some browsers (Firefox) do not ship with client side translation. Javascript feature detection is easy and an example is provided in the explainer.

Edge: No public signals. In private discussions have been supportive of feature.

Firefox: Firefox does not ship with client side translation.

Safari: No signals

Web / Framework developers: In the intent to experiment Google search team worked with external parties to support this and it was received well.

[a...@google.com]

Hi Dave,

I appreciate that this feature has gone through various rounds of review in the threads / PRs linked below, with the TAG, etc., but I wanted to mention a security aspect that didn't seem to get very clearly covered in the explainer or in previous discussions. Specifically:

1. Being able to force a client-side translation of a cross-origin page is security-sensitive:

- If the browser replaces strings in the DOM with a translation to another language, it can have side-effects that are observable cross-origin. For example, if there is an iframe somewhere on the page, that iframe may use IntersectionObserver to know if it's being displayed on the screen; depending on the language of the translation, a different portion of the frame may be shown, leaking information about the surrounding text.

- Similarly, translating the contents of the page can leak data via other side channels such as memory or CPU use (which could be observable by timing load events), the presence of scrollbars, etc.

- If online translation services are part of the proposal (i.e. the browser could send part of the text in the DOM to a server), this is particularly risky because an attacker could cause data from a sensitive application to be sent to the translation service (and potentially infer some information about it on the way, such as the size of the data).

2. Because of (1) it seems insufficient to specify this as a hint and say that the UA "will need to decide whether to invoke the client translation service or not". If the translation is triggerable from the web I think the spec would need to clearly outline the conditions under which the browser would respect hrefTranslate and trigger the translation, and what protections the browser must apply in this case. It may be instructive to look at the restrictions in https://github.com/WICG/ScrollToTextFragment#security -- though note that the threat model is a little different here.

3. I am not sure what the right model for user permission prompts is for this feature. It seems onerous to ask on every navigation, but I'm also skeptical about storing user consent (the explainer says: "If the User Agent trusts that site (perhaps by the user previously agreeing to the prompts), it may invoke a translation service automatically on the results"). The reason for this is that I may trust evil.com to translate evil2.com but not victim.org; similarly, I may want to allow victim.org pages to be translated from victim2.org but not evil.com. It's hard to extend trust to anything more than a single [source -> target] navigation, and I have some doubt if even in that case user consent would indicate an understanding of what the permission entails.

I apologize for adding to the pushback on this feature, but it seems like it would be important to figure out a set of conditions under which this feature is safe to use and make that a part of the explainer/spec.

Cheers,

-Artur

[Dave Tapuska]

I discussed Artur's concerns offline and I believe I've addressed them with an update to the explainer. 

Specific points:

1. Yes it is security sensitive. But I've taken your feedback here and explained our model a little more because the understanding we had for client side translation wasn't explicitly called out. First client side translation only works on the top level page and not individual iframes. The hrefTranslate attribute is for full page navigations only. There also is an additional restriction to only allowing it for navigations that either are the same target frame or have a "rel" attribute on the anchor set. 

2. I believe I've added additional text to the security section as you've asked here.

3. I've added some additional text to highlight that user agents shouldn't do automatic translations lightly because of the security concerns. Automatic translations (if they do it) should be limited to only trusted URIs. 

Since this I2S was sent TAG has also closed review of issue with comments that the explainer is now much clearer to them but that they still disagree with some direction here. I fundamentally believe that we've taken a principled approach between the security tradeoffs and the benefit to users in emerging markets. As called out in the explainer we are helping the web reach users that it doesn't serve well today. 

dave.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0debb050-8eee-45b3-b4a1-1bb0e1a0ba4d%40chromium.org.

[Yoav Weiss]

On Thu, Dec 5, 2019 at 5:24 PM Dave Tapuska <dtap...@chromium.org> wrote:

I discussed Artur's concerns offline and I believe I've addressed them with an update to the explainer. 

Can you please make sure the privacy and security sections find themselves in the PR, rather than just be in the explainer.

The explainer is great, but would be good to have inline notes in the spec to make sure future implementers are aware of those concerns.

  

Specific points:

1. Yes it is security sensitive. But I've taken your feedback here and explained our model a little more because the understanding we had for client side translation wasn't explicitly called out. First client side translation only works on the top level page and not individual iframes. The hrefTranslate attribute is for full page navigations only. There also is an additional restriction to only allowing it for navigations that either are the same target frame or have a "rel" attribute on the anchor set. 

2. I believe I've added additional text to the security section as you've asked here.

3. I've added some additional text to highlight that user agents shouldn't do automatic translations lightly because of the security concerns. Automatic translations (if they do it) should be limited to only trusted URIs. 

Since this I2S was sent TAG has also closed review of issue with comments that the explainer is now much clearer to them but that they still disagree with some direction here. I fundamentally believe that we've taken a principled approach between the security tradeoffs and the benefit to users in emerging markets. As called out in the explainer we are helping the web reach users that it doesn't serve well today. 

dave.

On Mon, Dec 2, 2019 at 4:15 PM aaj via blink-dev <blin...@chromium.org> wrote:

Hi Dave,

I appreciate that this feature has gone through various rounds of review in the threads / PRs linked below, with the TAG, etc., but I wanted to mention a security aspect that didn't seem to get very clearly covered in the explainer or in previous discussions. Specifically:

1. Being able to force a client-side translation of a cross-origin page is security-sensitive:

- If the browser replaces strings in the DOM with a translation to another language, it can have side-effects that are observable cross-origin. For example, if there is an iframe somewhere on the page, that iframe may use IntersectionObserver to know if it's being displayed on the screen; depending on the language of the translation, a different portion of the frame may be shown, leaking information about the surrounding text.

- Similarly, translating the contents of the page can leak data via other side channels such as memory or CPU use (which could be observable by timing load events), the presence of scrollbars, etc.

- If online translation services are part of the proposal (i.e. the browser could send part of the text in the DOM to a server), this is particularly risky because an attacker could cause data from a sensitive application to be sent to the translation service (and potentially infer some information about it on the way, such as the size of the data).

2. Because of (1) it seems insufficient to specify this as a hint and say that the UA "will need to decide whether to invoke the client translation service or not". If the translation is triggerable from the web I think the spec would need to clearly outline the conditions under which the browser would respect hrefTranslate and trigger the translation, and what protections the browser must apply in this case. It may be instructive to look at the restrictions in https://github.com/WICG/ScrollToTextFragment#security -- though note that the threat model is a little different here.

Was this addressed?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZWAGHfG1QNyNSuYigMD8mrokbqVEm7X6edFTmVjH9s5tg%40mail.gmail.com.

[Dave Tapuska]

>Can you please make sure the privacy and security sections find themselves in the PR, rather than just be in the explainer.

I've pushed updates to the PR that contain the text from the sections you indicated.

>Was this addressed?

Yes I believe I have added the text in the Security section Artur was looking for.

dave.

[Dave Tapuska]

I have one thing to amend in the original text:

Safari: Safari does not ship with client side translation

[sligh...@chromium.org]

LGTM 1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0debb050-8eee-45b3-b4a1-1bb0e1a0ba4d%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

LGTM2

This is a bit of an unusual hybrid between a platform API and what has otherwise been a developer-visible but non-platform browser behavior (client-side translation). I believe that this design is a strict improvement for users and developers over what's being done in practice (rewriting URLs to a server-side translation service), but also that it'll be safe to iterate and make breaking changes if necessary as we learn more about how this gets deployed in practice. Also I've seen (Eg. from trips to India) what a huge barrier to web use language issues can be and fear we really have not been anywhere near as aggressive as we should have been at trying to tackle these problems with urgency, so believe it's worth accepting some risk here.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0debb050-8eee-45b3-b4a1-1bb0e1a0ba4d%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZWAGHfG1QNyNSuYigMD8mrokbqVEm7X6edFTmVjH9s5tg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/63d668c8-8e0d-4ea0-bba7-0d941d8b3f00%40chromium.org.

[Yoav Weiss]

LGTM3