- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Tue, 30 Mar 2021 14:58:55 +0000
- To: public-webrtc-logs@w3.org
> 'Elad's Air Pods' or 'Air Pod de youenn' IIUC, this applies to tracks received with `getUserMedia`. The proposal for `preferredLabel` would only affected captured documents, so only `getDisplayMedia`. For that case, I think the captured document's locale is probably good enough. That's what Firefox's current implementation does for windows. > > But Chrome Security was hesitant about following suit and exposing either the title or the URL.host > > Can you share more about the potential issues here? I think it was the usual concern over sharing anything new; no specific potential issues were cited. If I were to try to argue Chrome Privacy's case myself¹, I'd say that (for **tab capture**, where these are not currently captured): * The title could expose the user's real name or username, and the user might not have noticed that. * URL.host could expose location by way of being, for instance, www.some-very-local-business.se. (Maybe the user is sharing their X-ray, but not their address.) > A dedicated field seems cleaner and there would be no backward compatibility issues as well. If a dedicated field can be used, that works for me as well. But what would it be? Would it not be a renamed `label` field? > If the capturing web application knows that the label is the window title This was rejected by Chrome Privacy, so we'd not be able to support such standardization. Is there a different example we could think of where having definite knowledge that the label was set by the browser is important? > There is no reason to trust that this piece of information is meaningful to the user. It is not necessary to share that with an end-user. At the moment, the value Chrome/Edge use is definitely not meaningful to the user. With this proposal, it might be. > Maybe it was defined by the captured page to help other capturing pages it has tight coupling with. That is a legitimate use-case. For example, a VC application could use this for gathering analytics over what users tend to share. (Note that the capturing page must know this is spoof-able.) This is possible today, too, using magic pixels, QR codes, etc. We'd be making it more ergonomic, though; since it's a legitimate use-case, I think that's good. --- 1) My previous reference to Chrome _Security_ was an error. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/159#issuecomment-810332381 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 30 March 2021 14:58:56 UTC