Use case 1 presumes tight integration

[jan-ivar]

This is too narrowly scoped. We should define the problem without preemptively limiting solutions.

[eladalon1983]

I don't follow you. Both README and spec contain, before the "use case 1", a generic problem description:

2.1 Generic Problem Description
Consider a web-application, running in one tab, which we’ll name “main_app.” Assume main_app calls getDisplayMedia and the user chooses to share another tab, where an application is running which we’ll call “captured_app.”

Note that:

main_app does not know what it is capturing.
captured_app does not know that it is being captured; let alone by whom.
Both these traits are desirable for the general case, but there exist legitimate use cases where the browser would want to allow applications to opt-in to bridging that gap and enable a connection.

We wish to enable the legitimate use cases while keeping the general case as it was before.

Then there are examples of use cases, which are narrowly scoped by definition.

[eladalon1983]

The attached PR clarified this issue for me.

I think we need to decide first what the right level of genericness/specificity is. Do we want to discuss any two applications that want to collaborate, or just video conferencing? What about recording services like Loom and Tella? These aren't VC applications, but the use case is close enough, that I'd like to capture it with the same use-case-N if possible.

[alvestrand]

I don't agree that this is a problem that needs fixing.
Use cases are cases, not attempts to describe every possible use.
Suggest closing with no change.

[jan-ivar]

The current use case prescribes a solution. This is not how use cases are described.

[eladalon1983]

In the PR, you suggest adding "standardized API for rudimentary control" as a third example, the other two being workers and shared cloud infrastructure. These other two examples are non-theoretical means. They exist today and are widely used for cross-app collaboration. On the other hand, a hypothetical "standardized API" does not clarify much for me. It seems like shoehorning Actions into the Identity document - and nobody else has expressed a desire for these two APIs to cohabitate in a document.

[jan-ivar]

... workers and shared cloud infrastructure ... exist today and are widely used for cross-app collaboration.

How are workers used for cross-app collaboration?

[eladalon1983]

... workers and shared cloud infrastructure ... exist today and are widely used for cross-app collaboration.

How are workers used for cross-app collaboration?

The same way you use a BroadcastChannel, namely:

• Assume origins X and Y.
• X embeds Y1, and communicates with it directly.
• Y1 uses worker or BroadcastChannel to communicate with Y2.
• It is now possible to send messages from X to Y2, even if they are in different browsing contexts.

So we have three existing mechanisms (shared cloud infrastructure, BroadcastChannel and workers). It's clear enough. Adding "some possible future API" diminishes clarity. Let's close this issue.

[jan-ivar]

• X embeds Y1, and communicates with it directly.
• Y1 uses worker or BroadcastChannel to communicate with Y2.

I worry this might break once browsers implement storage partitioning. cc @annevk

[eladalon1983]

• X embeds Y1, and communicates with it directly.
• Y1 uses worker or BroadcastChannel to communicate with Y2.

I worry this might break once browsers implement storage partitioning. cc @annevk

This is an example. If the example ceases to be relevant, we can remove it. The example of shared cloud infrastructure will still be relevant then.

[annevk]

Shared cloud infrastructure only works when the user is logged in, right? And yeah, what @jan-ivar says above is correct and already true in Safari.

[eladalon1983]

Shared cloud infrastructure only works when the user is logged in, right?

Typically yes. (What subtext am I missing, though? The example use-case is relevant regardless.)

And yeah, what @jan-ivar says above is correct and already true in Safari.

Are you saying that posting a message to a cross-origin embedded frame would not work? Because it works here.

Or are you saying that the BroadcastChannel will not work between tabs? In Chrome, it works here: receiver, sender. I don't know what Safari's plans are with respect to implementation of BroadcastChannel, but I've not heard of plans to deprecate.

How will Storage Partitioning impact this? (Also - if it does, we can always revise the list of example. Is this issue important?)

[annevk]

In a scenario where A and B are top-level tabs and they both embed C, C cannot communicate across its A and B instances. See https://privacycg.github.io/storage-partitioning/. It's relevant because new features need to be designed with that in mind.

[eladalon1983]

In a scenario where A and B are top-level tabs and they both embed C, C cannot communicate across its A and B instances. See https://privacycg.github.io/storage-partitioning/. It's relevant because new features need to be designed with that in mind.

Thanks for the reference.

1. Do you know Chrome's official position on this work item? BroadcastChannel and workers are existing APIs that violate this partitioning. I am not aware of plans to deprecate either of these APIs.
2. I'll keep this in mind we can update the clarifying text for potential use-cases when+if necessary.

[annevk]

@eladalon1983 Chrome is supportive and is working on it. The APIs won't be deprecated, but they'll work differently. Ask your colleagues on the storage and worker teams.

[eladalon1983]

Now that the decision has been made to adopt Identity and Actions as separate documents, the presumption of tight integration is appropriate for Identity. Nevertheless, so that we may progress to more productive issues, I have edited the text (document and README) to mention:

1. The possibility of future APIs addressing loosely-coupled cooperation.
2. That communication over a worker might be disrupted by Storage Partitioning.

Let's iterate when it becomes necessary.

[eladalon1983]

@annevk @jan-ivar, AFAICT, Chrome uses the top-level document's eTLD+1 for partitioning, so BroadcastChannel using the "mailman iframe pattern" would still work for many collaborations. That includes docs.google.com talking to meet.google.com. So I think the use-case is still fine.