audio API in kiosk

[Toni Barzic]

Hello again,

I have yet another proposal to enable a private API to apps running in kiosk session.

This time, it is chrome.audio  (even though the name does not suggest it , the API is actually private).

Please take a look at the proposal here:

https://docs.google.com/document/d/1RbyjsKZIb9a5D5q821XfjUb8ZSdaN9MRAl4ugNqQxQA/edit#

Thank you,

Toni

[Adrienne Porter Felt]

Out of curiosity, what's behind the sudden surge of kiosk-related APIs and changes? Is there a big push for kiosk mode going on right now? (The answer has nothing to do with the review, but I am wondering what kind of API review workload to expect moving forwards / how to distribute the review workload among the security team.)

[Rahul Chaturvedi]

We've enabled a kiosk session type, which allows us to move APIs that have no security/privacy concerns when running in Kiosk mode, to run without restrictions (while in Kiosk mode).

There are about 7-8 APIs we've identified to potentially move but we're only moving them as and when requirements come up. As of now, this is the last API we have a requirement for, so no more are in the pipeline (for the moment).

I am not sure if that answers your question, but feel free to ping me if you'd like to me to give more context :)

[Jenny Zhang(章瑛)]

I looked the the proposal, looks fine to me. We didn't implement getDevice API since in hotrod case, we always wait for cras to fire the device changed event and respond to the event. During the cras server initialization, the device list won't be ready until the system stabilized. Just be aware of that.

Thanks,

Jenny

On Fri, Oct 21, 2016 at 1:46 PM, Raj Duraisamy <sdura...@google.com> wrote:

Hi Adrienne, we have been getting requests from kiosk partners/customers to have access to networking, audio, logs, USB APIs etc. for quite sometime now. As Rahul mentioned, we have identified a few of them that will meet the Kiosk needs (the ones with less security/privacy implications in kiosk mode). Happy to give you more context.

Thanks.

Raj Duraisamy | PM, Chrome OS Enterprise/EDU | sduraisamy@google.com | 770-906-3611

[Albert Bodenhamer]

A bit more context:

The ones we've done have long standing feature requests from partners/customers but we've held off because we didn't have a good solution short of whitelisting individual apps.

The kiosk session type gives us that good solution.

--
You received this message because you are subscribed to the Google Groups "apps-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Jackson Haenchen]

Hey All,

I'm currently hoping to use one of these API's, the chrome.audio API. However, this API is only exposed in kiosk mode. However, the only way to put an app in kiosk mode appears to be by publishing to the web store. Am I to understand that in order to develop for these kiosk-only API's you're exposing I must deploy to the web store each time I want to debug a new version?

Your advice is greatly appreciated!

Thanks,

Jackson

[Jackson Haenchen]

The only way I’ve gotten this working is to deploy the unfinished app unlisted to the Chrome Store and then load it onto the Chromebox in kiosk mode. I then use a Chrome flag to redirect the debugger to a port, then use ssh to forward that port to my personal computer, where I can debug and interact with the chrome.audio API from the debugger console. 

All the same, this does not seem particularly sustainable for casual users.

Thanks,

Jackson