Extension chrome.system.network.setOptions()

[Michael Morrison]

I sent a mail to apps-dev@ and securit...@chromium.org but haven't heard anything.  Should I have posted to this group instead?

Proposal for extending system.network with setOptions:

https://docs.google.com/document/d/1mec39gB5Lg8i4l69yetBGtYEH1nhqpEXJNdO28TwvpI/edit?usp=sharing

Thanks for reviewing.

[Mustafa Emre Acer]

+securit...@chromium.org

(I couldn't find an email searching with "setOptions" or your email, so maybe it bounced?)

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Michael Morrison]

Weird.  Ok, thanks.

[Michael Morrison]

What are the next steps? Thanks.

[Benjamin Kalman]

It would be good for the Chromecast team to have a look at this.

[Michael Morrison]

Hi guys.  I haven't seen anything that would indicate whether this was approved or not.

I still need to do some work, but don't want to start unless there is some consensus.

Thanks.

[Benjamin Kalman]

Ken, Renaud, are you familiar with the networking APIs or can you point to somebody else who is able to review this?

[Ken Rockot]

I'm a little surprised by any API that exposes network interfaces directly to the browser -- and especially one that can change the configuration of those interfaces in any way -- but I have very little context for the existing system.network API so this surprise might be unwarranted. Renaud can you comment on this?

[Renaud Paquay]

The chrome.system.network API was added when chrome.socket was split into chrome.sockets.tcp, udp and tcpServer: there was no obvious good location for migrating the chrome.socket.getNetworkList function to the new namespaces, so we created a new one.

It seems that chrome.system.network is the right location for this new API, but it sounds like the main question is about security. The new api sounds quite powerful, so it sound high risk to me. IIRC, the "chrome.system.network" permission does not even result in a prompt to the user (i'd have to double check),

So, in summary, I think the main obstacle for this API will be to get approval from a security perspective, and I don't think I have the expertise to give an informed opinion.

[Ken Rockot]

+net-dev who might be able to weigh in as well

[Matt Menke]

Erm...Weigh in on what?

On Thu, Jul 16, 2015 at 11:44 AM, Ken Rockot <roc...@chromium.org> wrote:

+net-dev who might be able to weigh in as well

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CA%2BapAgFTnxjut_3Y%3Di66x5KYMMUii_N7L64bcTGX_Oh089BfXg%40mail.gmail.com.

[Ken Rockot]

Exposing an API to extensions that would be able to toggle scanning on wireless network interfaces.

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Ken Rockot]

Sorry, I didn't realize the entire thread context was lost... Proposal here:

https://docs.google.com/document/d/1mec39gB5Lg8i4l69yetBGtYEH1nhqpEXJNdO28TwvpI/edit?usp=sharing

[Ryan Sleevi]

Preface: I'm fairly strongly opposed to exposing powerful system APIs via extensions - whether public or private - especially if there's no counterpart for exploring on the Web platform. There's a very high bar to be met.

In some sense, private extension APIs in Chrome exist to simplify development of Chrome features across disparate teams, not to necessarily expose new and powerful primitives. That is, it can be quicker to iterate code and retroactively address bugs via extension mechanisms - or at least, that's the argument as it's been presented.

Given that Chromecast itself is trying to work very hard towards moving to the Presentation API ( https://w3c.github.io/presentation-api/ ) as part of a long-term integration of these capabilities into the Platform, it seems unwise to expose the limited and necessary functionality that will, eventually, be subsumed into the browser implementation itself.

[Further caveat: I was strongly opposed to any / all of the private networking APIs as extensions, since I think they add a significant attack surface for compromised renderers and by definition don't and shouldn't have a rational explanation as part of the Web Platform]

[Further caveat: I know my default answer is "No" to a lot of things, but this one I think there should be a really high bar]

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CA%2BapAgHurdCq7wn3WE6ANQh5-4b-U8CPXQhasJXarYGkrWZTrA%40mail.gmail.com.

[Matt Menke]

Just wanted to chime in that I'm in strong agreement with Ryan here, both about private APIs being a bad idea, and not wanting to expose system APIs via extensions, either via private or public APIs.

[Ken Rockot]

Thanks for the feedback Ryan and Matt. I agree on both points. Michael, it would be nice if we could find a better way to address this problem.

[Michael Morrison]

I heard a lot of "no's" so I'm open to suggestions about how to address the issue of wireless scanning under Windows interfering with streaming performance in a chrome app.  Apparently the chromecast team thought it was important enough to add this API to their private implementation in order to solve a problem they were having.  As mentioned earlier, I suspect we are experiencing the same issues with our streaming application (disconnects, significantly reduced/halted rates, etc).  This is a fairly well known issue.  Can someone propose something acceptable that other apps could use to solve the problem?

Thanks.

[Ryan Sleevi]

On Mon, Aug 3, 2015 at 1:31 PM, Michael Morrison <codebyt...@gmail.com> wrote:

I heard a lot of "no's" so I'm open to suggestions about how to address the issue of wireless scanning under Windows interfering with streaming performance in a chrome app.  Apparently the chromecast team thought it was important enough to add this API to their private implementation in order to solve a problem they were having.  

Which is truly unfortunate, but such private APIs should be seen as if they're part of Chrome itself for the Chromium functionality, rather than as being suitable to expose to untrusted code (whether third-party extensions or arbitrary websites)

 

As mentioned earlier, I suspect we are experiencing the same issues with our streaming application (disconnects, significantly reduced/halted rates, etc).  This is a fairly well known issue.  Can someone propose something acceptable that other apps could use to solve the problem?

I don't think there's going to be a good solution that allows 'other apps' to solve the problem, because that's the core crux of things. Other apps shouldn't be trying to solve the problem. 

[Mark Scott]

Hey Everyone,

Apologies that I missed this thread and didn't comment earlier.  +hubbe@, who is currently on vacation, but is most familiar with the Cast-related work (and I believe the original author of it).

My understanding is that this work was exploratory, as statistics were indeed showing that during media streaming there were bursts of latency (not loss; packets were ultimately delivered, but got delayed) that we didn't have a running explanation for.  This behavior was also notably worse on Windows than on Mac.  We speculated that ongoing Wi-Fi scans might lead to this sort of performance impact, and that it was causing issues during streaming.

This private API was intended to enable experimentation to determine if this was the case.  Specifically, the data collection around Cast Streaming was built at the extension level, so to do our flavor of A/B testing on whether or not Wi-Fi scans were to blame, we generally have the extension run two sessions (with + without) and then compare the results.  I don't know, but hubbe@ might, whether we ultimately ran and concluded anything from the experiment.  We de-focused this because we did positively identify the primary cause of Windows queuing behavior, and fixed it.  It's not to say that this doesn't contribute - and it is interesting that Michael may have more concrete evidence that we did.

Also, to be clear, the intent was never to provide extensions (even the Cast extension) with low level control; it was to collect data in order to make a permanent decision about whether it was viable to turn off background Wi-Fi scanning during Cast streaming (or more generally, any real-time media streaming e.g. WebRTC).  Things were implemented this way only because the fairly robust framework for getting experimental data on streaming performance needed to be extension-driven (vs. Finch driven).

Michael, what we saw seemed to be more on the level of a few 100ms, which wouldn't affect non-realtime media streaming (which typically has a ~20s buffer).  If you've got data (and we can use our experiments) to show a real impact, we could consider whether this should be always on during known real-time streaming cases (WebRTC, Cast) without exposing any APIs, or even exposing the fact that this is happening?

Mark.

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Ryan Sleevi]

On Mon, Aug 3, 2015 at 1:35 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

Which is truly unfortunate,

Just to clarify this comment - the unfortunate bit was wifi affecting media streaming, not the Chromecast teams' exploration :)

[Michael Morrison]

Michael, what we saw seemed to be more on the level of a few 100ms, which wouldn't affect non-realtime media streaming (which typically has a ~20s buffer).  If you've got data (and we can use our experiments) to show a real impact, we could consider whether this should be always on during known real-time streaming cases (WebRTC, Cast) without exposing any APIs, or even exposing the fact that this is happening?

Hi Mark.  Our application IS a real-time streaming app, so periodic bursts of a few 100ms latency are a disaster.  That is why we are asking for a way to expose this functionality to turn it off.

Our app is a combination of NaCl and JS so we would be happy with a flag or an API in NaCl as well. 

Thanks.

[Mark Scott]

Indeed, there's many scenarios in which 100ms is a lot - though we did not observe an impact on that level which we were able to attribute back to Wi-Fi scanning.  If you have data on this (and the impact of turning it off), that would be super helpful.

However the main point I was trying to make is that it seemed preferable to expose real-time streaming APIs (e.g. WebRTC, Cast Streaming) which do the right things at the platform level, vs. directly exposing low level networking capabilities and expecting each app to figure out how to use these optimally.  Are you using TCP/UDP socket APIs in your app?

 

Thanks.

[Michael Morrison]

Hi Mark.  Our application IS a real-time streaming app, so periodic bursts of a few 100ms latency are a disaster.  That is why we are asking for a way to expose this functionality to turn it off.

Our app is a combination of NaCl and JS so we would be happy with a flag or an API in NaCl as well. 

Indeed, there's many scenarios in which 100ms is a lot - though we did not observe an impact on that level which we were able to attribute back to Wi-Fi scanning.  If you have data on this (and the impact of turning it off), that would be super helpful.

 

Thanks Mark.

We are coming up with some data we can share regarding WIFI scan.

 

However the main point I was trying to make is that it seemed preferable to expose real-time streaming APIs (e.g. WebRTC, Cast Streaming) which do the right things at the platform level, vs. directly exposing low level networking capabilities and expecting each app to figure out how to use these optimally.  Are you using TCP/UDP socket APIs in your app?

We have a custom server that uses TCP/UDP sockets for communications and are unable to use something like WebRTC at this time.

[Michael Morrison]

Is the end result here going to be that Google will not approve an extension/mechanism to (turn off WIFI scanning, set media streaming mode and power settings), on Windows, for non-Google Chrome apps that can't use other streaming APIs?  Even if the user has agreed to some new permissions for those apps during installation?

[Mark Scott]

If the question is directed at me, our teams have more been users of the app/extension system than owners of what we'd generally permit there, so others on the list would be better to answer this question.

That we'd likely not expose low level platform specific networking APIs directly (from reading earlier comments in the thread) doesn't mean that we'd be adverse to finding a way to do this, though.  For instance, perhaps it's reasonable to propose that the sockets API allows requesting real-time treatment, resulting in the same behavior that a Cast Streaming socket or WebRTC media session would have.  I can't say if this is feasible, as I don't know anything about the current status of the socket API.  However, I just wanted to note that even the Cast-related APIs you came across weren't intended as a lasting way to do this, just as a way to collect data.

Mark.

On Wed, Aug 5, 2015 at 9:20 AM, Michael Morrison <codebyt...@gmail.com> wrote:

Is the end result here going to be that Google will not approve an extension/mechanism to (turn off WIFI scanning, set media streaming mode and power settings), on Windows, for non-Google Chrome apps that can't use other streaming APIs?  Even if the user has agreed to some new permissions for those apps during installation?

[Ryan Sleevi]

On Wed, Aug 5, 2015 at 9:20 AM, Michael Morrison <codebyt...@gmail.com> wrote:

Is the end result here going to be that Google will not approve an extension/mechanism to (turn off WIFI scanning, set media streaming mode and power settings), on Windows, for non-Google Chrome apps that can't use other streaming APIs?  Even if the user has agreed to some new permissions for those apps during installation?

If the question is about writing a CL to add that new extension API, yes, I think there'd be strong push back (as you see on that thread) about introducing such an API. 

https://www.chromium.org/developers/design-documents/extensions/proposed-changes/apis-under-development provides a lot more context and color about the reasoning, but I think the specific bits you're proposing run counter to a lot of the goals and concerns enumerated, both on a design and on a security level.

Mark's response is the right sort of balance of leaving the user agent in control of deciding what and how to control those things, and in a way that it can do so and protect the user.