Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Security aspects of remote captioning content and alternate formats #24

Open
RealJoshue108 opened this issue Nov 30, 2020 · 6 comments
Open

Security aspects of remote captioning content and alternate formats #24

RealJoshue108 opened this issue Nov 30, 2020 · 6 comments
Assignees
@RealJoshue108
Labels
enhancement New feature or request RAUR requirement

Comments

@RealJoshue108
Copy link
Contributor

RealJoshue108 commented Nov 30, 2020 •
edited

Filed on behalf of ITU-T - after comment made by Lidia Best and Masahito Kawamori (ITU) to myself and Shadi Abou-Zahra on a call.

Remotely captioned or transcribed or content in alternate formats may contain user sensitive and/or confidential information. Remote captioners and creators of alternate content should follow codes of best practice so this is not unintentionally divulged to third parties. and the storage of this data in various alternate formats is secure.

The initial use case is outlined well in this document by ITU - 'FSTP-ACC-RCS Overview of remote captioning services' [1]

We aim to refer to this use case in the RAUR and expand on it (we are currently awaiting feedback from ITU on the RAUR.)

[1] https://www.itu.int/pub/T-TUT-FSTP-2019-ACC.RCS
@RealJoshue108 RealJoshue108 self-assigned this Nov 30, 2020
@RealJoshue108 RealJoshue108 changed the title Security aspects of remote captioning content in alternate formats Security aspects of remote captioning content and alternate formats Nov 30, 2020
@nitedog
Copy link

nitedog commented Nov 30, 2020

For RAUR, I suggest something more oriented towards what applications can do rather than what captioners, audio describers, sign-language interpreters, and other service providers need to do.

For example: communication channels used to provide accessibility services, such as captioning, audio descriptions, re-speaking, and sign-language interpretation can be set to follow the same privacy and security policies as other communication channels. For example, in a teleconferencing application, the same encryption applied to the main voice channel can be applied to the channels for accessibility services.

@jasonjgw
Copy link
Contributor

Similarly for "at rest" encryption and access control of recorded content (e.g., if the application is recording a teleconference). The same protections apply to everything, including the various media alternatives that are provided.

@RealJoshue108
Copy link
Contributor Author

Sounds good and +1 to @nitedog and @jasonjgw

@JWJPaton
Copy link

JWJPaton commented Dec 1, 2020

I was trying to think if there are any new use cases from this. If a user who relies on relay services joins a confidential meeting which is encrypted then is it worth suggesting that the user should be able to authenticate a single third party (ie the relay service) to join the call?
Potential real-world example is a confidential work meeting with a deaf participant (who requires a relay service). We could leave it to the human element and expect the meeting organiser to authenticate the relay service but if the meeting organiser is less caring than they should be (or less organised) then the deaf user might be left without access. If the organiser can enable a user to authenticate one other party then the user can organise their own relay service.
It is however adding technical complexity when a simpler solution exists.

@jasonjgw
Copy link
Contributor

jasonjgw commented Dec 1, 2020

End-to-end encryption of telecommunications is controversial at the moment. I don't know whether the W3C has any active work in this area or a position, but I agree that if this technology is used, authorizing a relay service to enter a meeting could be a complicated matter.

@RealJoshue108 RealJoshue108 added requirement enhancement New feature or request labels Dec 2, 2020
@RealJoshue108
Copy link
Contributor Author

Discussed by RQTF on 9th Dec https://www.w3.org/2020/12/09-rqtf-minutes.html - Josh to draft some suggestions.

@ruoxiran ruoxiran transferred this issue from w3c/apa Mar 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@RealJoshue108 RealJoshue108

Labels
enhancement New feature or request RAUR requirement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@nitedog @jasonjgw @JWJPaton @RealJoshue108