Make COOP+COEP do not imply crossOriginIsolated. #6098

ArthurSonzogni · 2020-10-23T13:57:43Z

The specification currently requires COOP + COEP to give access to
crossOriginIsolated capabilities like SharedArrayBuffer.

Some platforms can't easily support multiple processes (like Android
Webview). Therefore, they can't really support crossOriginIsolated.
However the are no strong reasons for them not to enforce COEP (and
maybe COOP) when their associated headers are present.

It would be great enforcing COEP (and maybe COOP) on all platforms,
desptie the lack of crossOriginIsolated capabilities.

This patch makes the specification to allow (instead of requiring)
platform to set the crossOriginIsolated flag when both COOP and COEP are
used.

Setting crossOriginIsolated becomes platform dependent. In exchange, we
can enforce COEP (and COOP) in a non platform dependent way, without
conflicting with the specification about crossOriginIsolated.

/browsers.html ( diff )
/origin.html ( diff )
/structured-data.html ( diff )
/webappapis.html ( diff )
/window-object.html ( diff )
/workers.html ( diff )

yutakahirano · 2020-10-23T14:52:20Z

@annevk @domenic

I think it's good to make BCG's cross-origin isolated and agent cluster's cross-origin isolated platform independent, and cross-origin isolated capability platform dependent. That means even on Android WebView document.domain mutation is no-op when COOP: same-origin and COEP: require-corp is specified. What do you think?

ArthurSonzogni · 2020-10-23T15:19:28Z

I think it's good to make BCG's cross-origin isolated and agent cluster's cross-origin isolated platform independent, and cross-origin isolated capability platform independent. That means even on Android WebView document.domain mutation is no-op when COOP: same-origin and COEP: require-corp is specified. What do you think?

I agree it would be a shame not restricting document.domain.

I have been a bit confused by all the different cross-origin-isolated concept. So we have:

Browsing context group cross-origin isolated.
Agent cluster's cross-origin isolated
The windows's cross-origin isolated capability.

I guess I should just add a platform-specific exception to:
https://html.spec.whatwg.org/multipage/window-object.html#script-settings-for-window-objects:concept-settings-object-cross-origin-isolated-capability
instead.

yutakahirano · 2020-10-23T15:34:22Z

My recommendation would be...

Adding a note to https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-cross-origin-isolated-capability.
- Something like: Note: this value is platform dependent, because on some platforms it is difficult to ensure security guarantees we want to keep. There are platform independent invariants though.
  - If the surrounding agent cluster's cross-origin isolated is false, then this value is false.
  - If the corresponding feature policy doesn't allow to use the feature, then this value is false.
Modifying logic at https://html.spec.whatwg.org/multipage/window-object.html#script-settings-for-window-objects and adding a note.
Modifying logic at https://html.spec.whatwg.org/multipage/workers.html#worker-processing-model:concept-workerglobalscope-cross-origin-isolated-capability and adding a note.
Modifying the corresponding logic at the service worker logic and adding a note (Set correct embedder policy and cross-origin isolation mode w3c/ServiceWorker#1545).

domenic · 2020-10-23T17:30:19Z

I agree with @yutakahirano's suggestions. To give more detail on a particularly tricky part:

Modifying logic at https://html.spec.whatwg.org/multipage/window-object.html#script-settings-for-window-objects and adding a note.

My suggestion concretely here is that before step 4, you establish a boolean. Something like:

Let canBeCOI be true if the user agent is willing to give access to COI features to window, and false otherwise.

then you can modify the "cross-origin isolated capability" to be something like:

Return true if all of the following hold:

realm's agent cluster's cross-origin-isolated is true

canBeCOI is true

window's associated Document is allowed to use the "cross-origin-isolated" feature
Otherwise, return false

Without establishing the boolean ahead of time, if you just wrote something like "return false at the user agent's discretion" in the COIC algorithm, it would be possible per-spec for the value to change over time.

ArthurSonzogni · 2020-10-26T12:08:59Z

Thanks Yutaka and Domenic, this is really helpful!

yutakahirano · 2020-11-16T15:27:04Z

@ArthurSonzogni , what's the status of this bug?

ArthurSonzogni · 2020-11-16T15:55:31Z

@ArthurSonzogni , what's the status of this bug?

I just need to apply Domenic suggestions and yours. Nothing looks hard, I just need to produce some work ;-)

I was focused on my main project. Enabling COOP+COEP on every platforms is a side project that I wanted to see progress too, but this isn't my main priority and nobody really depends on this. Maybe you do somehow?

I've booked some time Wednesday for fixing this. I will update this thread.

yutakahirano · 2020-11-18T14:00:27Z

Thank you!

ArthurSonzogni · 2020-11-18T17:21:43Z

Modifying logic at https://html.spec.whatwg.org/multipage/window-object.html#script-settings-for-window-objects and adding a note. ~Yutaka

My suggestion concretely here is that before step 4, you establish a boolean. Something like:
(...)
Without establishing the boolean ahead of time, if you just wrote something like "return false at the user agent's discretion" in the COIC algorithm, it would be possible per-spec for the value to change over time. ~Domenic

The section linked above is called once for every "window" object being created. So this doesn't really represent a "global" per-agent variable. Maybe there is another section that is called only once, where I can put this variable instead?

(Or maybe I can just add a note explaining the agent have to make a decision and not change its mind over time.

domenic · 2020-11-18T17:45:00Z

I don't know if it's important for the canBeCOI boolean to be the same across the entire agent. Having it be per-window seems reasonable, since it's just applying an implementation-defined restriction on top of the existing agent cluster-wide cross-origin-isolated situation.

ArthurSonzogni · 2020-11-18T18:17:15Z

I made an update. It's a bit unfortunate that "canBeCOI" can't be made more global. I am defining from "Script settings for Window objects", but I also need to use it from the part about workers.

I would be happy to get some feedback from there. I still need to do the suggested change in the w3c/ServiceWorker repository.

domenic · 2020-11-18T18:55:42Z

If we wanted it to be more global, we could modify the agent cluster's cross-origin-isolated at the time that gets set (which is roughly at agent cluster creation time). However, I haven't thought through the full implications of that, and am unsure it's a great idea. I remember feeling that the current design you've uploaded is good, when we discussed this 26 days ago.

I'm currently attending BlinkOn so my time for nontrivial reviews like this one is a bit scarce. But as soon as I'm able (probably Friday?) I'll do a review of the latest changes you've made, and also think more deeply about whether it would be a good idea to make it change the agent cluster's cross-origin isolated. Thoughts from @yutakahirano or @annevk would be welcome in the meantime.

annevk

I think this approach is fine. If you wanted something more global you would have to change the browsing context group and agent cluster's cross-origin isolated concept to a tri-state I think, but I'm not sure what the observable differences would be. I would hope none.

source

annevk · 2020-11-19T10:13:23Z

Hmm, thinking about it more that tri-state would be a lot cleaner as it more closely matches what an implementation would want to do. It would not process-isolate the agent cluster after all. I think it's worth another look to see how hard that would be.

ArthurSonzogni · 2020-11-19T11:52:02Z

Hmm, thinking about it more that tri-state would be a lot cleaner as it more closely matches what an implementation would want to do. It would not process-isolate the agent cluster after all. I think it's worth another look to see how hard that would be.

That was my feeling since the beginning. I would be happy to do this.

So, I guess I would need to modify:
https://html.spec.whatwg.org/#bcg-cross-origin-isolated

Replace:

A browsing context group has a cross-origin isolated boolean. It is initially false.

by:

A browsing context group has a cross-origin-isolated tri-state. It can take the following values:
- process-isolation
- logical-isolation
- none

It is initially 'none'.

Then modify:
https://html.spec.whatwg.org/#browsing-context-group-switches-due-to-cross-origin-opener-policy:bcg-cross-origin-isolated

Replace:

If navigationCOOP is "same-origin-plus-COEP", then set newBrowsingContext's group's cross-origin isolated to true.

By:

If navigationCOOP is "same-origin-plus-COEP", then set newBrowsingContext's group's cross-origin isolated to
- 'process-isolation' if canBeCrossOriginIsolated
- 'logical-isolation' otherwise.

What do you think of this in general?

annevk · 2020-11-19T12:56:42Z

Yeah, I think that's right. And note that aside from the browsing context group's cross-origin isolated, you'll also need to do this for the similar boolean on agent cluster (which just copies the value from the browsing context group it's associated with).

Edit: I would try to avoid the word "process" to not bake particular computer architectures too much into the design, even though they are somewhat in the end.

ArthurSonzogni · 2020-11-26T14:18:43Z

@annevk : The patch with your suggestions from #6098 (comment) is ready.
If you have some time, could you please take a look?

annevk

I think this looks good overall. My concerns are mainly about something that was already there (SAB protection) and the exact wording to use in the various places that need changes, but the architecture seems sound to me.

annevk · 2020-12-01T10:05:49Z

source

@@ -8078,7 +8078,8 @@ interface <dfn>DOMStringList</dfn> {
       <span>agent cluster</span>.</p></li>

       <li>
-        <p>If <var>agentCluster</var>'s <span>cross-origin isolated</span> is false, then throw a
+        <p>If <var>agentCluster</var>'s <span>cross-origin isolated</span> is not <code
+        data-x="bcg-isolation-physic">isolation-physic</code>, then throw a


I'm surprised this isn't checking the capability. Wouldn't that mean that a cross-origin document can use SharedArrayBuffer?

cc @domenic @yutakahirano

Now you say it, I am surprised too. My understanding is that we should check the capability.

That's what we implemented on Chrome here:
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/execution_context/execution_context.cc;l=184;bpv=1;bpt=1?q=sharedarraybuffertran

However, this requires talking about the destination realms.

I had some questions about it previously: https://crbug.com/1144838
Here is a copy of my questions:

I discussed: https://chromium-review.googlesource.com/c/chromium/src/+/2343658 with sigurds@. It made me ask myself several questions, that I answered by adding tests: https://chromium-review.googlesource.com/c/chromium/src/+/2514211 I can now say the following: From - a COOP/COEP page, - an OS without SharedArrayBuffer enabled by default (e.g. Android), Then it is possible to share a SharedArrayBuffer from a non crossOriginIsolated document iframe. Specifically, we have: 1. (sender.crossOriginIsolated == false) + (receiver.crossOriginIsolated == false) => Blocked. 2. (sender.crossOriginIsolated == true ) + (receiver.crossOriginIsolated == true ) => Transfered 3. (sender.crossOriginIsolated == true ) + (receiver.crossOriginIsolated == false) => Blocked 4. (sender.crossOriginIsolated == false) + (receiver.crossOriginIsolated == true ) => Transfered This is not necessary bad, what matters is the receiver. I wanted to make sure you are okay with case 4. WDYT?

I made some tests here:
https://chromium-review.googlesource.com/c/chromium/src/+/2514211
Unfortunately, not WPT test, because this rely on flags not enabled yet.

In the spec, I don't know the destination realms.
I guess I should update:

StructuredSerializeInternal ( value, forStorage [ , memory ] )

into

StructuredSerializeInternal ( value, forStorage [ , memory ] [, destinationRealm] )

and plumb |destinationRealm| everywhere this function is called.

I ended up moving this part toward the deserialization, because targetRealm was already plumbed. I didn't wanted to plumb destinationRealm on the serialization side. Does this sound good to you?

I think we should split this part out into its own PR given it's quite separate from what this PR is doing. Having said that, I think we can also check this when serializing as there is a current Realm. The difference here is whether postMessage() throws or the target gets a messageerror event. I suspect we want postMessage() to throw, though I also don't care too strongly. I was hoping @domenic and @yutakahirano would chime in.

Yeah, woah, let's not make changes to structured serialization in this PR, especially one that changes the signature. That's a big change that needs more discussion in a dedicated issue, not a comment thread on a PR.

I moved it out.

source

annevk · 2020-12-01T10:11:12Z

source

-  <span>agent cluster</span> are automatically origin-isolated. The `<code
+  <p class="note">Similarly, <code>Document</code>s with <span>agent cluster</span>'s
+  <span>cross-origin isolated</span> <code data-x="bcg-isolation-physic">isolation-physic</code>
+  are automatically origin-isolated. The `<code


I think all the not-"none" values offer the same features as Origin Isolation in terms of what is observable to web developers.

They are close. The observable differences I have in mind are:

difference when opening a new window from a sandboxed iframe. The opener can't influence the openee with sandbox-flags. I think this result in error page.

difference, because we might swap browsing context group during a navigation, depending on the various headers.

Outside of navigations

source

domenic

In penance for the long delays in review, I'll help out by pushing some commits to fix the issues I mention in this review, plus some editorial touchups.

source

The [specification] currently requires [COOP] + [COEP] to give access to crossOriginIsolated capabilities like SharedArrayBuffer. Some platforms can't easily support multiple processes (like Android Webview). Therefore, they can't really support crossOriginIsolated. However the are no strong reasons for them not to enforce COEP (and maybe COOP) when their associated headers are present. It would be great enforcing COEP (and maybe COOP) on all platforms, desptie the lack of crossOriginIsolated capabilities. This patch makes the specification to allow (instead of requiring) platform to set the crossOriginIsolated flag when both COOP and COEP are used. Setting crossOriginIsolated becomes platform dependent. In exchange, we can enforce COEP (and COOP) in a non platform dependent way, without conflicting with the specification about crossOriginIsolated. [Bug]: whatwg#6060 [specification]: https://html.spec.whatwg.org/#cross-origin-opener-policies [COOP]: https://html.spec.whatwg.org/#cross-origin-opener-policy [COEP]: https://html.spec.whatwg.org/#coep

domenic · 2020-12-17T19:17:42Z

@annevk @yutakahirano @ArthurSonzogni PTAL. My changes are:

Editorial fixups (including things like "cross-origin-isolation" -> "cross-origin isolation mode")
Fixes to the issues @yutakahirano identified
Changed the structured serialization to check the capability of the current realm. (We can discuss whether it checks the destination realm in a separate issue; IMO the spec is correct that such checking is not necessary, but we can discuss.)
Since cross-origin isolated mode = logical/concrete => is origin-keyed = true (but not vice-versa), I updated two locations where it was more correct to talk about is origin-keyed. I.e. document.domain was checking both conditions, so I simplified it to only check is origin-keyed. And the non-normative note about window agent clusters was talking only about cross-origin isolated mode, but what it was saying was applicable to both, so I updated it to talk about origin-keying.

annevk

I was thinking that we would split out the structured serialization bug fix entirely, but I guess it's okay to include it here if we spell it out in the commit message. I found a couple nits, seems okay to me to land this modulo those, but I'd appreciate one more review since it's a bit harder to review on a small screen.

annevk · 2020-12-18T09:19:27Z

source

@@ -80423,9 +80462,6 @@ interface <dfn>BarProp</dfn> {
   a registrable domain suffix of and is not equal to</span> <var>effectiveDomain</var>, then throw
   a <span>"<code>SecurityError</code>"</span> <code>DOMException</code>.</p></li>

-   <li><p>If the <span>surrounding agent</span>'s <span>agent cluster</span>'s <span>cross-origin
-   isolated</span> is true, then return.</p></li>


Why is this removed? Is it redundant with is origin-keyed now?

Yes, exactly. Another thing to spell out in the commit message.

annevk · 2020-12-18T09:20:33Z

source

+    <p class="note">It is difficult on some platforms to provide the security properties required by
+    the <span data-x="concept-settings-object-cross-origin-isolated-capability">cross-origin
+    isolated capability</span>. Only "<code
+    data-x="cross-origin-isolation-concrete">concrete</code>" might grant access to it. "<code


s/might/will/

Using "might" was intentional. This also depends on the feature policy bit.

For instance: BCG cross-origin-isolation-concrete + document using Feature-Policy: cross-origin-isolated 'none' won't grant the window.crossOriginIsolated bit.

In my last patchset. I used can. It sounds less confusing than might, and more precise than will.

annevk · 2020-12-18T09:21:24Z

source

+    isolated capability</span>. Only "<code
+    data-x="cross-origin-isolation-concrete">concrete</code>" might grant access to it. "<code
+    data-x="cross-origin-isolation-logical">logical</code>" won't, and is used by implementations on
+    other platforms.</p>


This other is weird, since we already started with some platforms that might use "logical".

I agree. I removed ,and is used by implementations on other platforms.

ArthurSonzogni

Thanks @domenic for the big update!

ArthurSonzogni · 2020-12-19T18:20:00Z

source

+    <p class="note">It is difficult on some platforms to provide the security properties required by
+    the <span data-x="concept-settings-object-cross-origin-isolated-capability">cross-origin
+    isolated capability</span>. Only "<code
+    data-x="cross-origin-isolation-concrete">concrete</code>" might grant access to it. "<code


In my last patchset. I used can. It sounds less confusing than might, and more precise than will.

ArthurSonzogni · 2020-12-19T18:21:36Z

source

+    isolated capability</span>. Only "<code
+    data-x="cross-origin-isolation-concrete">concrete</code>" might grant access to it. "<code
+    data-x="cross-origin-isolation-logical">logical</code>" won't, and is used by implementations on
+    other platforms.</p>


I agree. I removed ,and is used by implementations on other platforms.

annevk · 2021-01-04T15:41:53Z

@ArthurSonzogni could you prepare a tentative commit message that also accounts for the additional changes as discussed above and post it as a comment? I think this is good to go. (I pushed one more nit.)

ArthurSonzogni · 2021-01-04T19:54:16Z

Thanks @annevk !

Tentative commit message:

The [specification] currently requires [COOP] + [COEP] to give access to
crossOriginIsolated capabilities like SharedArrayBuffer.

Some platforms can't easily support multiple processes (like Android
Webview). Therefore, they can't really support crossOriginIsolated.
However the are no strong reasons for them not to enforce COEP (and
maybe COOP) when their associated headers are present.

This patch makes the specification to allow (instead of requiring)
platform to grant the crossOriginIsolated capability when both COOP and
COEP are used.

The browsing context group's cross-origin-isolation mode becomes a
tri-state:
- none     (not COOP+COEP)
- logical  (COOP+COEP, without granting crossOriginIsolated)
- concrete (COOP+COEP, with granting crossOriginIsolated)

[Bug]: https://github.com/whatwg/html/issues/6060

[specification]:
https://html.spec.whatwg.org/#cross-origin-opener-policies

[COOP]:
https://html.spec.whatwg.org/#cross-origin-opener-policy

[COEP]:
https://html.spec.whatwg.org/#coep

---

Additional minor change:

When setting document.domain, both properties were previously checked:
1) agent-cluster's cross-origin-isolation mode.
2) agent-cluster's origin-keyed.
The first has been removed, since it already implies the second.

annevk · 2021-01-05T07:29:43Z

Thanks, we should also mention the change to StructuredSerializeInternal, but I can merge that in as well. If there are no further comments I'll merge this tomorrow.

ArthurSonzogni · 2021-01-05T10:48:07Z

Thanks, we should also mention the change to StructuredSerializeInternal, but I can merge that in as well. If there are no further comments I'll merge this tomorrow.

Did we change StructuredSerializeInternal? I see only some "data-x=" being now properly set. The content is the same.
We previously discussed updating StructuredSerializeInternal, but we said this was unrelated to this current patch, so the change was removed.

annevk · 2021-01-06T11:00:31Z

It went from checking cross-origin isolated to cross-origin isolated capability, right? That's a big change, even if one could consider it an oversight from when we introduced cross-origin isolated capability.

ArthurSonzogni · 2021-01-06T17:05:56Z

Indeed! Updated tentative commit message. (Feel free to improve it, if needed)

Make COOP+COEP do not imply crossOriginIsolated.

This contains 3 changes:
---

The [specification] currently requires [COOP] + [COEP] to give access to
crossOriginIsolated capabilities like SharedArrayBuffer.

Some platforms can't easily support multiple processes (like Android
Webview). Therefore, they can't really support crossOriginIsolated.
However the are no strong reasons for them not to enforce COEP (and
maybe COOP) when their associated headers are present.

This patch makes the specification to allow (instead of requiring)
platform to grant the crossOriginIsolated capability when both COOP and
COEP are used.

The browsing context group's cross-origin-isolation mode becomes a
tri-state:
- none     (not COOP+COEP)
- logical  (COOP+COEP, without granting crossOriginIsolated)
- concrete (COOP+COEP, with granting crossOriginIsolated)

[Bug]:  https://github.com/whatwg/html/issues/6060
[COOP]: https://html.spec.whatwg.org/#cross-origin-opener-policy
[COEP]: https://html.spec.whatwg.org/#coep
[specification]:
https://html.spec.whatwg.org/#cross-origin-opener-policies

---

When setting document.domain, both properties were previously checked:
1. agent-cluster's cross-origin-isolation mode.
2. agent-cluster's origin-keyed.
The first has been removed, since it already implies the second.

---

When serializing a sharedArrayBuffer, check the cross-origin isolated
capability instead of the agent-cluster cross-origin isolation mode.
This was an oversight from when the cross-origin isolated capability was
first introduced.

annevk · 2021-01-06T17:35:38Z

Thanks so much @ArthurSonzogni!

ArthurSonzogni · 2021-01-06T17:44:24Z

Thanks!

blindmanyo22 approved these changes Nov 2, 2020

View reviewed changes

ArthurSonzogni force-pushed the coop-coep-not-imply-cross-origin-isolated branch from 590a022 to c79e8f3 Compare November 18, 2020 17:56

annevk reviewed Nov 19, 2020

View reviewed changes

source Outdated Show resolved Hide resolved

annevk reviewed Dec 1, 2020

View reviewed changes

ArthurSonzogni force-pushed the coop-coep-not-imply-cross-origin-isolated branch 2 times, most recently from 68d940c to 9c0351e Compare December 15, 2020 01:15

yutakahirano reviewed Dec 17, 2020

View reviewed changes

source Show resolved Hide resolved

source Outdated Show resolved Hide resolved

domenic reviewed Dec 17, 2020

View reviewed changes

source Show resolved Hide resolved

source Outdated Show resolved Hide resolved

source Show resolved Hide resolved

ArthurSonzogni and others added 4 commits December 17, 2020 14:12

Revert checking targetRealm for transfert SAB.

075c677

Editorial fixes

b955b10

Consolidate a bit with "is origin-keyed"

f28344f

domenic force-pushed the coop-coep-not-imply-cross-origin-isolated branch from 485b55e to f28344f Compare December 17, 2020 19:14

annevk approved these changes Dec 18, 2020

View reviewed changes

Address annevk@ comments.

7f36cd8

ArthurSonzogni commented Dec 19, 2020

View reviewed changes

yutakahirano approved these changes Dec 21, 2020

View reviewed changes

wording nit

9c2fd1f

annevk merged commit cbcf6ac into whatwg:master Jan 6, 2021

ArthurSonzogni deleted the coop-coep-not-imply-cross-origin-isolated branch January 6, 2021 17:44

yutakahirano mentioned this pull request Jan 25, 2021

Set correct embedder policy and cross-origin isolation mode w3c/ServiceWorker#1545

Open

Make COOP+COEP do not imply crossOriginIsolated. #6098

Make COOP+COEP do not imply crossOriginIsolated. #6098

Conversation

ArthurSonzogni commented Oct 23, 2020 • edited by pr-preview bot Loading

yutakahirano commented Oct 23, 2020 • edited Loading

ArthurSonzogni commented Oct 23, 2020 • edited Loading

yutakahirano commented Oct 23, 2020

domenic commented Oct 23, 2020

ArthurSonzogni commented Oct 26, 2020

yutakahirano commented Nov 16, 2020

ArthurSonzogni commented Nov 16, 2020

yutakahirano commented Nov 18, 2020

ArthurSonzogni commented Nov 18, 2020 • edited Loading

domenic commented Nov 18, 2020

ArthurSonzogni commented Nov 18, 2020

domenic commented Nov 18, 2020

annevk left a comment

Choose a reason for hiding this comment

annevk commented Nov 19, 2020

ArthurSonzogni commented Nov 19, 2020

annevk commented Nov 19, 2020 • edited Loading

ArthurSonzogni commented Nov 26, 2020

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

domenic commented Dec 17, 2020

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ArthurSonzogni left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Jan 4, 2021

ArthurSonzogni commented Jan 4, 2021

annevk commented Jan 5, 2021

ArthurSonzogni commented Jan 5, 2021 • edited Loading

annevk commented Jan 6, 2021

ArthurSonzogni commented Jan 6, 2021

annevk commented Jan 6, 2021

ArthurSonzogni commented Jan 6, 2021

ArthurSonzogni commented Oct 23, 2020 •

edited by pr-preview bot

Loading

yutakahirano commented Oct 23, 2020 •

edited

Loading

ArthurSonzogni commented Oct 23, 2020 •

edited

Loading

ArthurSonzogni commented Nov 18, 2020 •

edited

Loading

annevk commented Nov 19, 2020 •

edited

Loading

ArthurSonzogni commented Jan 5, 2021 •

edited

Loading